Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A nice app on Elm street

madewithlove.be

Post reply on HN
Print view View original

51–60 of 84 posts

Re: A nice app on Elm street

#51

Post by zellyn »

a-saleh wrote: post #29
fortran77 wrote: post #26

I love Elm, but this tutorial is based on Elm 0.18, and 0.19 is out. There are some straighforwared but significant changes with how an application is set up. If you're just starting out, find a 0.19 tutorial.

T.b.h. this is the reason why I will probably stay messing around with either PureScript or ReasonML but stay away from Elm.

I've been lurking Elm for a while, and with Elm 18 came to the conclusion that I should avoid it, because there was a single creator who simply could not keep up, and was uninterested in fostering a healthy community of contributors.

With Elm 19, I changed my mind. A closer following of the community shows that Evan is (a) nice, and (b) interested in contributions, but mostly in a researchy way. More importantly, Elm 19 seemed (to me) to tip the balance in usefulness and cleanliness.

And with the idea of taking Elm straight to WASM (and with WASI around), things are looking interesting in the (eventual… gosh but it moves slowly) future.

tl;dr: It's absolutely worth taking a new look at Elm 19.

Re: A nice app on Elm street

#52

Post by Touche »

al2o3cr wrote: post #48
jlengrand wrote: post #19

I am a back-end developer, and I don't know front-end. I also know very little of functional programming. Elm is the only language that I like writing, and where I don't feel in a state of frustration when I write. It might have a lot of limitations, bu tit makes me happy. Given that our job is basically to be in a constant state of half broken code, this makes me a huge fan of the language.

our job is basically to be in a constant state of half broken code In my experience, Elm code is only ever in a state of "horribly broken, won't compile" or "works". Whether that's a bug or a feature depends on what I'm trying to do...

That's interesting. How does Elm statically know if the logic of your app is correct? Since I don't know Elm I'll use some pseudocode:

  if condition
    pourCoffee()
  else
    pourTea()
Is Elm able to determine that this condition is flipped the wrong way?

Re: A nice app on Elm street

#53

Post by jlengrand »

Touche wrote: post #52
al2o3cr wrote: post #48

Earlier quoted context omitted.

our job is basically to be in a constant state of half broken code In my experience, Elm code is only ever in a state of "horribly broken, won't compile" or "works". Whether that's a bug or a feature depends on what I'm trying to do...

That's interesting. How does Elm statically know if the logic of your app is correct? Since I don't know Elm I'll use some pseudocode: if condition pourCoffee() else pourTea() Is Elm able to determine that this condition is flipped the wrong way?

Yes, because in elm everything is pure. At least in the code you write. Elm will force you to declare all possible cases that can happen, all branches in every function you write. That leaves literally nothing to break.

Not saying you can't break an elm program. But you won't run into runtime exceptions in elm, by design:)

Re: A nice app on Elm street

#54

Post by fortran77 »

sacado2 wrote: post #42
k_bx wrote: post #31

Earlier quoted context omitted.

Why exactly? Elm 0.19 is out on August 2018, and the only thing that's expected is 0.19.1 which barely changes anything (doesn't break any api). Seems like 0.19 is quite settled at this point.

Will my Elm code written today still be maintainable with an up-to-date elm environment in 3 years? It certainly isn't the case with code written 3 years ago.

I agree this is a problem, but what "JavaScript" compiler/language technology isn't changing rapidly? 3 years ago we were using JQuery.

Re: A nice app on Elm street

#55

Post by jweir »

Touche wrote: post #52
al2o3cr wrote: post #48

Earlier quoted context omitted.

our job is basically to be in a constant state of half broken code In my experience, Elm code is only ever in a state of "horribly broken, won't compile" or "works". Whether that's a bug or a feature depends on what I'm trying to do...

That's interesting. How does Elm statically know if the logic of your app is correct? Since I don't know Elm I'll use some pseudocode: if condition pourCoffee() else pourTea() Is Elm able to determine that this condition is flipped the wrong way?

Elm makes no claims to correct your logic. Logical errors are not caught by the compiler. You might still decode a JSON field to the wrong field on a Record (if the fields are the same type), you might invert a BOOL and use True were you meant False, you might incorrectly calculate some value, etc.

But, state errors are caught – your application can not get into an impossible state and therefore should never have any runtime errors.

Getting back to logical errors – Elm can provide some additional safeguards. For example you could have a record

``` type alias Point = { x: Int, y: Int } ```

and then decode it with

``` decode.map2 Point (field "y" int) (field "x" int) ```

Whoops you got the wrong order.

So you could make X and Y explicit types:

``` type alias Point = { x: PointX, y: PointY } type PointX = PointX Int type PointY = PointY Int decode.map2 Point (field "x" decodeX) (field "y" decodeY) ```

Now your decoder won't compile unless the types line up correctly. But this adds a bit of extra overhead in unwrapping the values, but not much.

Re: A nice app on Elm street

#56

Post by jweir »

a-saleh wrote: post #29
fortran77 wrote: post #26

I love Elm, but this tutorial is based on Elm 0.18, and 0.19 is out. There are some straighforwared but significant changes with how an application is set up. If you're just starting out, find a 0.19 tutorial.

T.b.h. this is the reason why I will probably stay messing around with either PureScript or ReasonML but stay away from Elm.

In my experience this has not been a problem. First upgrades are very infrequent. Second, they occur for very good reasons. Third there is tooling to handle a lot of the code migration. Fourthly, the compiler will help you fix the rest. Lastly, each new version has been a real improvement on the previous.

Re: A nice app on Elm street

#57

Post by jasim »

Touche wrote: post #52
al2o3cr wrote: post #48

Earlier quoted context omitted.

our job is basically to be in a constant state of half broken code In my experience, Elm code is only ever in a state of "horribly broken, won't compile" or "works". Whether that's a bug or a feature depends on what I'm trying to do...

That's interesting. How does Elm statically know if the logic of your app is correct? Since I don't know Elm I'll use some pseudocode: if condition pourCoffee() else pourTea() Is Elm able to determine that this condition is flipped the wrong way?

Neither Elm, nor any language in the Typed FP family, can do that. What it can do is to prevent us from making clerical mistakes. That's the surprising thing I learned programming in Typed FP: we very rarely make logical mistakes. Our programs are all broken, make no mistake, but they are broken not because we accidentally swapped a conditional (logical mistake), but rather because we passed in data of the wrong shape (clerical mistake).

A common clerical mistake which Elm, Reason etc. prevents, is when we grab something from a list and pass it to another function. What if in a rare case it is possible that the element doesn't exist? A function deeper in the stack might crash, or if defensively built, substitute it with an empty value. Both could be wrong.

By providing more information about our data and our functions to the compiler, the compiler can ensure our code always follow those constraints. These constraints are often in our head when using dynamically typed languages, or even statically typed OO languages. Typed FP helps us make them explicit in code so the compiler can track it instead of we tiring ourselves mentally and making a mess of it.

Re: A nice app on Elm street

#58

Post by santoriv »

jasim wrote: post #57
Touche wrote: post #52

Earlier quoted context omitted.

That's interesting. How does Elm statically know if the logic of your app is correct? Since I don't know Elm I'll use some pseudocode: if condition pourCoffee() else pourTea() Is Elm able to determine that this condition is flipped the wrong way?

Neither Elm, nor any language in the Typed FP family, can do that. What it can do is to prevent us from making clerical mistakes. That's the surprising thing I learned programming in Typed FP: we very rarely make logical mistakes. Our programs are all broken, make no mistake, but they are broken not because we accidentally swapped a conditional (logical mistake), but rather because we passed in data of the wrong shap…

Just want to give props. This is the clearest explanation of the value of typed FP I've ever seen.

Re: A nice app on Elm street

#59

Post by zinclozenge »

crtlaltdel wrote: post #46
sacado2 wrote: post #44

I like Elm as a language, but the community is extremely toxic, and it's not production-ready yet (version < 1.0, one-person project). Too bad, because it's a great project.

can you site some sources for the “extremely toxic” community? genuinely curious

richard feldman, evan's colleague, is not exactly a nice person on the internet. There are several times where he's ranted or had a temper tantrum for no particularly good reason.

now he alone does not make up the "community", but he's certainly a prominent member of it.

Re: A nice app on Elm street

#60

Post by wtetzner »

nilkn wrote: post #36
thepratt wrote: post #11

For anyone new trying to get into Elm (as a language/tool), I would look elsewhere. ReasonML, PureScript, TypeScipt, etc are all better featured solutions. Having said that, the article is well written and thorough for anyone wanting to take a look into Elm. But there are massive problems with Elm itself which make it impossible to consider seriously. I have and still do use Elm in production, and went through the ni…

For what it's worth, PureScript is much more complex than Elm. I see people recommend it, but I don't see people actually use it nearly as much as Elm (not that Elm is super widely used, of course). I do agree that the biggest thing Elm needs is to open up development, break down the "dictatorship" as you put it, and accelerate the pace rapidly.

I think OCaml/ReasonML seems like the nicest choice, even if you're using the Elm architecture. Functors make it really easy to combine components, which actually makes it nicer than Elm for the same tasks.
Post reply on HN