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

Elm in Production: 25K Lines Later

charukiewi.cz

Post reply on HN
Print view View original

181–190 of 278 posts

Re: Elm in Production: 25K Lines Later

#181

Post by BoiledCabbage »

Rotareti wrote: post #140
ToJans wrote: post #8

First: > Elm has an incredibly powerful type system Near the end of the article: >Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application. IMHO the lack of typeclasses/traits is really hurting Elm. Take haskell f.e. {-# LANGUAGE DeriveGeneric #-} import GHC.Generics data Person = Person { name :: Text , age :: Int } deriving (Generic,…

Whenever something about elm pops up, I see people complaining about this. Reminds me of people complaining about Golang missing feature X. Still both languages raising in popularity. I haven't used Elm or Golang, but I'm almost convinced that simplicity is a driving factor for their success.

This is exactly it. I can't speak for Golang, but why Elm wins is its simplicity.

You can go through the tutorial and know the language in two days. Seriously if you ever want a weekend project, try learning elm.

Even if you don't want to use it, but just to be exposed to the ideas.

You csn be writing productive code in a week. If anyone tell you Haskell (or Purescript) is less than months to be productive is not being honest about what production level productivity entails. You can learn the fundamentals in less time, but the prized significantly more complex abstractions makes ramping up significantly slower. And this is coming from someone who likes haskell and is enjoying learning the language.

As someone who has used a lot of languages over the years, I really do say spend a weekend trying it out. The language has great ideas and a great philosophy.

https://www.elm-tutorial.org/en/

Re: Elm in Production: 25K Lines Later

#182

Post by steveklabnik »

mrkgnao wrote: post #179
Ar-Curunir wrote: post #163

Earlier quoted context omitted.

It's the same with `rust` and `serde`; it's a great feeling!

I can imagine :) I think over in Rust-land it's something like #[derive(FromJSON)] isn't it?

  #[derive(Serialize, Deserialize)]
but yeah, same difference.

Re: Elm in Production: 25K Lines Later

#183

Post by runeks »

dmitriid wrote: post #134
willtim wrote: post #129

Earlier quoted context omitted.

Now you have the condescending tone! However, it appears you don't understand the IO monad. Programming using the IO monad is pure functional programming with full referential transparency. Please read Phil Wadler's paper, you will not understand this from that JavaScript snippet. The only backdoors are escape hatches like unsafePerformIO which are used for low-level libraries and FFI, they can be disabled with pragm…

As soon as you have side-effects (an IO is a side-effect) you can through your assumptions about "strict conformation to definition" out of the window: --- treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. --- > It is much harder to stay true to that definition using the other languages, multi-paradigm or not. I doesn't matter if it's "hard". Your argument was…

> As soon as you have side-effects (an IO is a side-effect) you can through your assumptions about "strict conformation to definition" out of the window

You misunderstand what an IO action is. An IO action in Haskell is a value which describes a side effect. For example, an IO Int is a value that describes a side effect which, at runtime will produce a value of type Int inside the IO monad.

The difference is that the IO Int is a value, it’s a constant which describes how to perform something at runtime (also called promises in some languages). It’s like a callback function, which takes a value as an argument that will be available when it’s called (at runtime).

Re: Elm in Production: 25K Lines Later

#184

Post by reitanqild »

KirinDave wrote: post #169
kahnpro wrote: post #83

Earlier quoted context omitted.

I tried out Purescript for a project and didn't think it's ready for production... Generic encoding/decoding was painful, the lack of good dependency management was painful, too many things were either missing or immature. I hope in a year or two the story will be better.

PureScript is a rapidly moving target. When did you try?

Eh, I don't know PureScript but IMO you just added another reason why it isn't production ready.

Unless they are really really good at keeping backwards compability in both language and build tools.

Re: Elm in Production: 25K Lines Later

#185

Post by unabst »

Quick question.

> Want to measure the height of an element on the page at the moment a user clicks on it? Hard, in order to do this we had to make heavy use of event bubbling and writing JSON decoders for the native event.target object that is produced by an onclick event.

What would be considered best practice?

Is it best practice to re-implement this sort of thing? Seems one could easily find vanilla JS code and encapsulate it, or add a helper lib?

Re: Elm in Production: 25K Lines Later

#186

Post by empath75 »

_gi12 wrote: post #180
ToJans wrote: post #8

First: > Elm has an incredibly powerful type system Near the end of the article: >Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application. IMHO the lack of typeclasses/traits is really hurting Elm. Take haskell f.e. {-# LANGUAGE DeriveGeneric #-} import GHC.Generics data Person = Person { name :: Text , age :: Int } deriving (Generic,…

I really wish people would stop spreading the meme that decoding JSON in Elm is "hard". Yes, Haskell allows you to automatically decode/encode datatypes, but this only works in the simplest of cases. For example, if your backend returns a JSON object with snake-cased fields, but your model has camel-cased fields, `instance ToJSON Person` won't work; you'll have to write a custom decoder. The automatic decoders/encode…

> Writing decoders in Elm is not hard.

At some point, after enough people tell you that they can't figure out how to do something, one should admit that it is difficult.

Re: Elm in Production: 25K Lines Later

#187

Post by mavelikara »

Existenceblinks wrote: post #149
Albert_Camus wrote: post #40

Earlier quoted context omitted.

Author here. JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object. In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just decoding to primitive values or t…

> JSON decoding is hard relative to what it is like in JavaScript I'm not making a joke but this is a valid point. And if it had ELMON (Elm object notation), things would be more straight forward.

No, that is not a joke. If one tried to convert an Applet to HTML5 and came across a server backend that returned serialized Java objects, parsing that into JS would have been significantly harder than the two lines with ObjectInputStream it would take in Java.

Re: Elm in Production: 25K Lines Later

#188

Post by mrkgnao »

steveklabnik wrote: post #182
mrkgnao wrote: post #179

Earlier quoted context omitted.

I can imagine :) I think over in Rust-land it's something like #[derive(FromJSON)] isn't it?

#[derive(Serialize, Deserialize)] but yeah, same difference.

Ah. That derives both "ToJSON" and "FromJSON", as Aeson calls them. Cool!

Re: Elm in Production: 25K Lines Later

#189

Post by gcanti »

jnbiche wrote: post #133
BoiledCabbage wrote: post #95

Earlier quoted context omitted.

> I cannot emphasize enough how much better working with Elm is. >In every single aspect. I just wish that it will get mainstream as soon as possible. I completely agree - I will be a huge benefit to the industry when elm is as common as js. The concepts it introduces, the benefits it shows are all huge. I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her comp…

> I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler. I love Elm as much as the next guy, but be aware that you can get many, if not most, of these same benefits while working in JS if you use Flow.js or Typescript. I prefer Flow because the community is more oriented toward functional programming vs OOP in Typescript, but they're both capable static…

working on a fp library for TypeScript if you want to take a look https://github.com/gcanti/fp-ts

Re: Elm in Production: 25K Lines Later

#190

Post by Nelkins »

dmjio wrote: post #21

If decoding json in Elm is considered hard, I'd recommend checking out miso ( https://github.com/dmjio/miso ), a Haskell re-implementation of the Elm arch. It has access to mature json libraries like aeson for that sort of thing, along with mature lens libraries for updating your model. Here's an example of decoding json with GHC.Generics using typeclasses. https://github.com/dmjio/miso/blob/master/examples/xhr/Main.…

There's also Fable-Elmish[1], which can be used with Fable[2], which is an F#-to-JS compiler.

[1] https://fable-elmish.github.io/elmish/

[2] http://fable.io/

Post reply on HN