[elm-discuss] Elm Runtime Exceptions
One of Elm’s most interesting features is "No Runtime Exceptions". But I would argue that Elm does in fact have Runtime Exceptions, even if you don't call it that. I explain my reasoning in this blog post: https://medium.com/@daveford/my-take-on-elm-runtime-exceptions-b3c5156887c9#.p1mrtcr2m I may very well be misunderstanding something. So please correct me if I am missing the point. Thanks. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Re: Elm Runtime Exceptions
On Wednesday, September 7, 2016 at 12:49:23 PM UTC-7, Charlie Koster wrote: > > Your description of Maybe isn't correct. When a function returns a Maybe > it's not throwing an exception. Maybe is a separate type (like String) so > when a function returns a Maybe String that is the type of the returned > value. It's saying the returned value is one of two things. It's a Nothing, > or it's an actual String that you can use. > I understand that. That's why I used the phrase "But I would argue that Elm does in fact have Runtime Exceptions, even if you don't call it that.". I get how Elm works and that Maybe and Result are types. What I mean is that Maybe and Result, in some ways, represent the same purpose as an Exception. Really more like checked exceptions than runtime exceptions. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Elm Runtime Exceptions
The analogous part is the fact you end with "exception handling" code interspersed throughout your main logic flow. That part seems very much like C to me. On Wednesday, September 7, 2016 at 1:23:24 PM UTC-7, Nick H wrote: > > I don't think the comparison to C is accurate at all. Error codes in C are > a programming convention. As far as the compiler is concerned, all ints are > created equal. Nothing is reminding the programmer to check for error codes. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Elm Runtime Exceptions
On Wednesday, September 7, 2016 at 6:26:58 PM UTC-7, Max Goldstein wrote: > > Maybe is not an exception, as has been pointed out. *Maybe is a data > structure.* It just so happens that it's a data structure that can hold > at most one element. > Again, I completely understand that Maybe is a data structure and not *literally* an exception (like a java exception). And I also get that there are many use cases where maybe should really be checked. But their also many case where the Nothing case represents the *exception *(not the norm). The net result is that exception handling code ends up interleaved within my main logic flow. > OP seems to think that bubbled exceptions are a good thing. > I think interleaving exception handling throughout the main business logic flow makes code hard to read and is generally an anti-pattern. Not everyone likes every programming language and you're entitled to your > opinion. > I love Elm. I just noticed that I seem to have a lot of exception handling interleaved with my primary business logic and am trying to learn how Elm addresses this. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Elm Runtime Exceptions
Joey. Yours was the best answer. And you already stated it. Sorry for making you repeat yourself. Thank you. I will need to checkout Maybe.andThen, Result.andThen, Maybe.map and Result.map. And then see if I still have anything to complain about :) On Thursday, September 8, 2016 at 10:24:12 AM UTC-7, Joey Eremondi wrote: > > @Dave Ford: that's literally what Maybe.andThen and Result.andThen are > for. See also Maybe.map, and Result.map. > > They let you chain together several computations that may throw an > exception. You can take a computation which throws an exception, and a > computation which expects a non-exception argument, and compose them into a > new computation that throws an exception. Use map when the computation > taking the argument throws no exception, and use andThen when it can itself > throw an exception. > > Using these, you can handle your exceptions as high or as low in the > program logic as you'd like. You can let the exceptions bubble up using > andThen and map. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] No Runtime Exceptions - Still not computing
I have listened to a number of podcasts where Richard Feldman boasts about
never getting a runtime exception.
I am having a hard time grasping the concept. I think I look at runtime
exceptions a bit differently. I look at them as a *positive*. A programmers
tool. A debugging tool. A way to communicate up the call stack. A way to
separate the error stream from the standard stream.
For example, a java newbie might do this:
void myFunction(int x){
if(x < 1){
* log("error: x must be >= 1"); *
* return 0*
}
return x * x * x;
}
A more experienced developer might do this:
void myFunction(int x){
if(x < 1){
*throw new IllegalArgumentException("error: x must be >= 1"); *
}
return x * x * x;
}
I look at runtime exceptions as a good thing. It's kind of like having two
returns. One return for the normal answer (return). And another for error
conditions (throw). Just like unix has two output streams: one for normal
messages and one for error messages. This allows the caller to handle the
normal return value and the *top-level* caller to handle (i.e. catch) the
errors (usually by logging a stack trace).
So I don't get it. If I don't have runtime exceptions, what do I do when
someone passes an invalid argument? What do I do if some pre-condition is
not as I expected? Some JSON returned from the server is not in the correct
format? Are we back to just *one* return value for both error conditions
and normal conditions?
Technically speaking, in java, if I wanted to create an app with no
runtime exceptions it would be real easy. I could just swallow invalid
arguments and let the program fail in a super mysterious way, farther
upstream (the opposite of fail-fast). But I wouldn't boast about that. Or I
could just have a try/catch in my main method that caught every exception
and swallowed it or logged it.
If Richard said he wrote apps with no *bugs*. That would be impressive. But
an app with no runtime exceptions seems like a silly thing to boast about.
I see 3 kinds of bugs in my java apps:
1. *Compile errors.* These are the easiest to deal with. These are
preferred. But I don't see the compiler catching the above mentioned
IllegalArgumentException*. *Or a piece of bad JSON from the server.
2. *Runtime Exception. *Like a NullPointerException or an
IllegalArgumentException. I *love* these kind of bugs. Super easy to find.
Super easy to fix. A stack trace tells me exactly where to look. These kind
of exceptions have never been a thorn in my spine.
3. *The mystery bug. *Program is just not producing the correct output. No
idea why. No idea where to start looking. No error message. No stack trace.
These are the worst kind of errors.
In my opinion one of the key differences between an experienced developer
and a beginner developer is that an experienced developer fails-fast with
compile errors (#1) or runtime exceptions (#2). Beginner developers fail
mysteriously with (#3).
So, based on my understanding, the whole "no runtime exceptions" concept is
just not computing.
But I am new to Elm. Surely I am misunderstanding something. Please tell me
what I am missing.
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] No Runtime Exceptions - Still not computing
Thanks Joey. > you will handle the error case, and either come up with a sensible > default, or tell your program to display some error message, or do > something else to properly handle the error. > You mean, do exactly like I showed in the java newbie example? What would be considered an anti-pattern in java? How is this a good thing? It seems like a step backwards. Often there is no way to "handle" the error. There is no sensible default. It's a programmer error and throwing an exception is the most logical thing to do. Unless I am missing some key concept, this will make your programs less reliable. True, there will be no runtime exception. But there will be bugs. And more noise. Again, I will admit that I am new to Elm. And may be missing something. I totally get the whole "maybe" thing. And I see the advantage of that. But, if I am not mistaken, we are back to C in the sense of "no throw"? C#, Java, JavaScript, and Scala have the keyword throw. VisualBasic, Python, Ruby, F# and Clojure have raise. Is there no throw/raise in Elm? We must use "return" for both standard return and error return. Is that correct? I'm not trying to be a troll. There are lots of things I love about Elm. I'm just trying to understand the language. Thanks. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] No Runtime Exceptions - Still not computing
Duane. Don't get me wrong. I prefer compile errors over runtime errors. And if Elm can catch more errors at compile time without adding a bunch of noise to my code that is a good thing obviously. But runtime errors are unavoidable. It's not possible for the compiler to catch every possible error condition. The question is, does the language have an elegant mechanism to deal with runtime exceptions? Especially in a separate flow from the normal return value. And from what I am hearing the answer is either no or no one is telling me what it is. So my question is: does Elm have something similar to throw/raise? On Oct 6, 2016 8:07 PM, "Duane Johnson" wrote: > > On Thu, Oct 6, 2016 at 8:13 PM, Dave Ford wrote: > >> 2. *Runtime Exception. *Like a NullPointerException or an >> IllegalArgumentException. I *love* these kind of bugs. Super easy to >> find. Super easy to fix. A stack trace tells me exactly where to look. >> These kind of exceptions have never been a thorn in my spine. > > > I'm genuinely surprised by your experience / reaction to runtime > exceptions. My experience has been the exact opposite. Runtime exceptions > can only be found through tedious exercise of every branch of code through > all possible states, which creates a horrible burden on the developer who > wishes to not have to worry about how old code might break as new code is > added and the size of the project (and possible states) increases. > > When you say you love these kind of bugs, are you saying you like to go > through your program and try this or that input and see if you can get it > to throw an exception? What if you change the code somewhere else, but in a > section of code that *might* affect other parts of your codebase--do you > then go back to each of the other parts of your program and try to think of > new ways that exceptions might have be able to be raised? > > I wrote part of a large (very large--possibly the largest open source Ruby > app, called Canvas) and at some point, the complexity becomes mindboggling. > It slows down project development when you can't check (at compile-time) > whether a change here affects the code *there* (and *there*, and *there*, > and, does it affect *this* code?) The motivation of Elm, as I see it, is to > push as many classes of errors as possible into the compile-time error > space. Not all can be pushed into that domain, but many can--and that's > considered an advantage because as project size increases, you can still > move with confidence. > > Possibly related--I found it instructive to listen to Richard's "Making > Impossible States Impossible" presentation at ElmConf. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/elm-discuss/00CgYDiMvBI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > elm-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] No Runtime Exceptions - Still not computing
> > This means that there is no exception that will bubble up unhandled at > runtime and crash your app. > Peter, I think you may be misunderstanding the intent of exception bubbling. The idea is not to have the exception bubble up to the top and crash your app. The idea is this. Suppose you have function1 call function2 and function2 call function3 and function3 call function4. And suppose function4 throws an exception. An unrecoverable exception. And suppose that the sole purpose of the exception is to indicate a programming error or a system problem. There is nothing to be "handled". No possible "recovery". The only reasonable way to handle the exception is with a "generic exception handler": 1. log a message 2. print a stack trace 3. update the ui with a generic "system error: please see log" message. For this situation, the established best practice (as far as I know) has always been to allow that exception to bubble up to main and have *one* top-level "generic exception handler" in main. Runtime exceptions are inevitable. An awesome compiler can certainly move certain categories of exceptions from runtime to compile time. Form what I am hearing, Elm is pretty good at that. But exception bubbling is a *feature*. An extremely useful feature. Language level support for exceptions has been a staple of every programming language since C. I do not consider Maybe and Result to be a useful substitute for language level exception support. I could do Maybe and Result in C. Even unix has separate streams for standard versus error. If every function in between main and function4 has to explicitly propagate the exception up the call stack, I see that as adding no value and a bunch of noise to the app. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] No Runtime Exceptions - Still not computing
On Fri, Oct 7, 2016 at 10:14 AM, Joey Eremondi wrote: > Runtime exceptions are inevitable > > You can keep saying it, but it doesn't make it true. > Sorry. I was using the term "runtime exception" in the more general sense: exceptional conditions that occur at runtime (not caught by the compiler) like: - Invalid function args - Malformed JSON - Server down -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] No Runtime Exceptions - Still not computing
On Fri, Oct 7, 2016 at 11:10 AM, Peter Damoc wrote:
>
> If you can come up with a practical scenario where you would have an
> exception, I or someone else around here could tell you what would happen
> in Elm in that context.
>
Yes. The example I gave when I started the thread (sorry for the java
syntax - i'm new):
function foo(int x) throws IllegalArgumentException{
if(x > 10) throw new IllegalArgumentException("Bad x");
return x * x * x;
}
Finally, you do have the option of crashing the entire program with
> Debug.crash
>
This sounds pretty similar to throw.
I'll have to play around with Debug.crash and Result.andThen a bit before
continuing my complaining.
Thank you everyone for your patience and thoughtful responses.
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: No Runtime Exceptions - Still not computing
On Fri, Oct 7, 2016 at 11:33 AM, Kasey Speakman wrote: > > Then at the edge of the application, I can deal with the errors > Yes. This is what I am trying to figure out. How to deal with that class of errors at the "edge". Thanks. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] View: Model -> Html Msg
I understand this function signature: update: Msg -> Model -> Model to mean the function takes two inputs, a Msg and a Model and returns a Model. Correct? But I don't understand this function signature: view: Model -> Html Msg It seems that the view function takes a Model and returns an Html. What exactly does the Msg mean in this context? Is it a type parameter to Html? Like Html in Java? Thanks. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] In
What does the in keyword do? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Creating an API to be consumed by JS developers
My experience with compile-to-js languages include: GWT, Dart and TypeScript. GWT was very good at *calling* JS libraries. Almost zero friction. But not so, in the other direction. Creating API's to be consumed by JS was so ugly that I can confidently say that it was not worth it. Unless you are creating an API that has a very small surface area to functionality ration (like maybe a spell checker). Dart has a similar story to GWT. By far the best inter-op story is TypeScript. If you write a lib in TypeScript it can be consumed by JS as-is. No special anything is needed. So my question is, where does Elm fall in this spectrum. Is it advisable to create an api in Elm to be consumed by JS developers? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Creating an API to be consumed by JS developers
That's pretty much how GWT was.
On Sat, Oct 8, 2016 at 1:34 PM, OvermindDL1 wrote:
> The 'official' interaction between Elm and javascript is via ports, which
> involves marshelling any JSON-compatible type across the interface. From
> the Javascript side it involves just 'send'ing something to somewhere (like
> via `Elm.MyApp.ports.someport.send("something");`) or to get data from
> Elm you 'subscribe' to it (such as in `Elm.MyApp.ports.someport.
> subscribe(function(msg){console.log(msg);})`). It defines a specific
> interface for data to transfer over so everything on the Elm side can be
> 'safe' and any unsafe access happens only through know access points.
>
>
> On Saturday, October 8, 2016 at 12:22:12 PM UTC-6, Dave Ford wrote:
>>
>> My experience with compile-to-js languages include: GWT, Dart and
>> TypeScript.
>>
>> GWT was very good at *calling* JS libraries. Almost zero friction. But
>> not so, in the other direction. Creating API's to be consumed by JS was so
>> ugly that I can confidently say that it was not worth it. Unless you are
>> creating an API that has a very small surface area to functionality ration
>> (like maybe a spell checker).
>>
>> Dart has a similar story to GWT.
>>
>> By far the best inter-op story is TypeScript. If you write a lib
>> in TypeScript it can be consumed by JS as-is. No special anything is
>> needed.
>>
>> So my question is, where does Elm fall in this spectrum. Is it advisable
>> to create an api in Elm to be consumed by JS developers?
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/Rw3dPPgaRRI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Systemic problem in Object Oriented languages
There is a line from the docs that I am trying to understand: "Elm encourages a strict separation of data and logic, and the ability to say this is primarily used to break this separation. This is a systemic problem in Object Oriented languages that Elm is purposely avoiding." What is the systemic problem being reference? Is it the [lack of] "separation of data and logic" or "the ability to say this"? I have been programming in Java (an OO language) for a long time. I can name dozens of systemic problems in the language. But the ability to say "this" is not one of them. Nor is it the commingling of data and logic. Please help me to understand what the author is talking about. Thanks. Side note: "this" *is* a problem in JavaScript. But not in OO generally. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Systemic problem in Object Oriented languages
On Thu, Jul 20, 2017 at 4:14 AM, Peter Damoc wrote: > "this" is associated with mutation. Elm is an immutable language. > I don't think that's true. I might be wrong, but I'm pretty sure that "this" has nothing specifically to do with mutation. I write immutable objects all day long in java and kotlin making use of "this" and mixing data and logic. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Systemic problem in Object Oriented languages
On Thu, Jul 20, 2017 at 4:24 AM, John Orford wrote: > It's ambiguous > It's not. In Java it's very clearly and deterministically defined. this.x = 123 > Immutability is a different issue. "this" has nothing specifically to do with mutability. The use of "this" is orthogonal to mutability. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Systemic problem in Object Oriented languages
> > Now, is it actually a systemic problem ? My intuition is that it is the > root of many difficulties OO languages can have, even though it does not > seem like a problem at first. Can you give an example? Specifically, without confusing the unrelated issue of immutability? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Systemic problem in Object Oriented languages
First of all, I apologize in advance if I sound argumentative. It's just
how main brain learns.
Alex, thanks for your thoughtful reply. Below is how I would do your Square
example in Java and Kotlin. Both examples combine data and logic and both
examples are fully *immutable*.
*Java*
public class Square {
private final float size;
public Square(float size) {
this.size = size;
}
public float getSize() {
return size;
}
public float getPerimeter() {
return size * 4;
}
public float getArea() {
return size * size;
}
}
*Kotlin:*
class Square(val side: Float) {
val perimeter: Float get() = side * 4
val area: Float get() = side * side
}
In an object oriented language, what would be the point be of having
> immutable data?
>
Same as in a functional language. I do it all day and every day. I have
written huge and useful components in Java and Kotlin and Scala without a
single mutation.
> It's not that OOP is bad, but it encourages mutation
>
OOP does not encourage nor discourage mutation. Java, Kotlin, Scala and
OCAML all *allow* mutation. Kotlin, an OO language that I use a lot,
actually *discourages* mutation. But regardless, my question was not about
immutability. It was about combining data and logic.
*Conclusions*
Here is the original assertion from the Elm docs: "Elm encourages a strict
separation of data and logic, and the ability to say 'this' is primarily
used to break this separation. This is a systemic problem in Object
Oriented languages that Elm is purposely avoiding."
I have read the responses in this thread carefully and thoughtfully. None
of the answers addressed the question in my original question in a way that
satisfies my sense of logic.
So here are my conclusions:
*1. Immutability is a separate issue. *I only bring this up because many of
the replies in this thread brought up immutability*.* Immutability is not
really related to the issue we are discussing. But regardless, OO is
perfectly happy being immutable. I do it all the time. Immutability *is* a
problem with JavaScript. But not with Java, Scala or Kotlin or C# or most
OO languages. As demonstrated by the examples above.
*2. Combining data and logic is not a systemic problem in object oriented
programming.* I would argue that it is an advantage for some use-cases. I
have, for many years, been happily and successfully writing code that is
both immutable *and* combines data and logic.
*3. "this" is not a systemic problem with OO languages*. It *is* a systemic
problem with JavaScript, but that is another topic. Java and Scala all deal
with "this" quite nicely and predictably.
Checkout this example of a Card class (as in a Card game). It combines data
and logic. And uses "this" (implicitly, as is usually the case). And it is
completely immutable:
https://github.com/StokeMasterJack/bj1/blob/master/src/main/kotlin/bj1/Card.kt
Please look at this code and explain to me the systemic problem I am
missing.
This may sound like bikeshedding. But before I delve into a solution (in
this case, Elm forcing the separation of data and logic) I like to
understand the problem. And it appears that in this case, unless I am
missing something, the problem statement seems based on an incomplete
understanding of object-oriented programming languages (other than
JavaScript).
I may be wrong. I am open to changing my opinion if someone posts new
information I haven't considered.
Side note: here is more logical reason for forcing the separation of data
and logic: it lowers the surface area of the language, thus making it
easier to learn for beginners
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Systemic problem in Object Oriented languages
> > A lot of my early work was centered around UIs which made heavy use of > inheritance and mutation. > I really don't think this is related to the original question. The original question was not about inheritance or mutation or even about OO. It was about "this" and "combining data with logic". Which were described as a "systemic problem". No one (yet) has convinced me that they are even remotely a problem. No one has provided an example. Or any logic to support the claim. They have mentioned all sorts of other things that *are* problematic, like inheritance and mutation. But I already knew those were problematic. I also already knew that most OO languages also support mutation (although mutation is discouraged in Kotlin). But this is not what the question was. Sure, you could start naming off a dozen other things that are problematic (like inheritance and mutation). But that has nothing to do with the question. > In OO, mutation is very easy to do because of `this`. > No. As mentioned earlier, "this" has nothing to do with immutability. "this" is just an object variable like any other object variable. | Perhaps your experience with OO programming is atypical? The fact that "this" has nothing to do with immutability is unrelated to my experience. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] 80% of my coding is doing this (or why templates are dead)
I have given this spiel in recent meetups and no one tried to kill me, so I thought I would make blog post. It mentions Elm as one of the communities happily generating HTML without templates. Sorry for the overly click bait-ish title. https://medium.com/@daveford/80-of-my-coding-is-doing-this-or-why-templates-are-dead-b640fc149e22 -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
