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

91–100 of 278 posts

Re: Elm in Production: 25K Lines Later

#91

Post by dmitriid »

willtim wrote: post #85
dmitriid wrote: post #78

Earlier quoted context omitted.

Ah, here comes the condescending tone I've so come to appreciate from the Haskell programmers. "Go and read", "anti-intellectualism".

You are misquoting me. I said steering others away from the original source of work to an interior source (incomplete at best) is anti-intellectualism. I do not mean to be condescending, but I feel very strongly about this.

In order not to copy-paste, I'll link to my reply in another thread: https://news.ycombinator.com/item?id=14890766

Re: Elm in Production: 25K Lines Later

#92

Post by tome »

dmitriid wrote: post #82
tome wrote: post #76

Earlier quoted context omitted.

At this point you just sound like a troll.

Nope. It's a genuine feeling. Basically, in an ideal world we would have a "pragmatically typed" programming language. Basically something in between "weak dynamic typing of Javascript" and "strong static typing of Haskell". No such language currently exists, and this makes me sad. It's also hard to come up with a proper definition for such a language :)

> Nope. It's a genuine feeling.

That's not exclusive with being a troll.

> Basically, in an ideal world we would have a "pragmatically typed" programming language.

Yes, it's called Haskell. Or, if you don't like purity, either OCaml or F#.

Re: Elm in Production: 25K Lines Later

#93

Post by Nekorosu »

hellofunk wrote: post #56
delegate wrote: post #32

Anyone familiar with both Elm and Clojurescript ? Clojurescript's 're-frame' lib implements something similar to the Elm architecture and is quite pleasant to work with. How does the Elm experience compare to the Clojurescript experience ?

Similarities: 1) Re-frame and Elm are both backed by a virtual dom (Re-frame leverages React behind the scenes, Elm uses virtual-dom) 2) Both impose a single app state 3) Both require user events and outgoing state mutation to be explicitly defined somewhere outside of the context of a view 4) Both operate on a sort of "game loop" style of processing events and calling view functions 5) All data is immutable in both…

Worth mentioning that Clojure(Script) comes from a different school of thought (Lisps) and has its own approach to development called REPL driven development. It allows you to experiment a lot and fail fast.

Large projects are absolutely doable but require more discipline and experience with the language from developer. For example you can start with a crude prototype and introduce clojure.spec later. When you do this is entirely your choice while in Elm you just have to write function signatures and types/structures definitions from the beginning.

ClojureScript has a very easy interop with JavaScript. Actually this is one of design goals. Consuming JavaScript library is super easy. For example most of virtual DOM libraries are built upon React. This is good because writing performant virtual DOM with older browsers support isn't an easy task.

The toolchain has code splitting and dead code elimination. It had it long before Webpack and can even optimize imported JS libraries code. As far as I know Elm still can't do it.

Another good thing is you can use Clojure(Script) both on the client and the server. This allows you to nearly skip data serialization/deserialization using powerful "transit" library. Actually you can use transit on server with several other languages. So it's not a lock in but it's much smoother with Clojure.

The libraries ecosystem is rich. For example Clojure(Script) has a mature WebSockets library (it's both server-side and front-end) with any kind of fallback you can imagine.

Re: Elm in Production: 25K Lines Later

#94

Post by dmitriid »

mrkgnao wrote: post #89
dmitriid wrote: post #81

Earlier quoted context omitted.

> Does this strike you as idle theoretical self-enjoyment? It does. How many PhDs does one require to understand/correct/debug all the :> and : etc.?

Speaking from experience, zero. > debug But the whole point of a good compiler is that it tells you when you're wrong ! (Instead of having to write hundreds of tests (and thousands of Node test runners).) > :> and : You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later. Observe: type API = "polls…

> Speaking from experience, zero. You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later.

So, basically, "learn this thing without understanding what it does" :-\

Reminds me of teaching Java to newbies: "oh, just type this syntax, you have to memorize it, don't worry about it".

> Definitely less than it takes to become comfortable with the quirks of literally everything in JS: perhaps you should give something an honest shot before telling people who have derived real-world benefits from using it in production that it's useless?

A real app is not just "hey, memorize this DSL and type it". I've found Haskell unapproachable on multiple occasions. And yes, I've completed my obligatory "Haskell from first principles" and "Learn You a Haskell for Great Good!" :)

Re: Elm in Production: 25K Lines Later

#95

Post by BoiledCabbage »

antouank wrote: post #24

After doing a couple of contracts on Elm projects for several months, and returning now back to a React-Redux stack project, 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. His article is spot on, and agrees with what I've seen, and most others that used Elm. Just look it up.

> 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 compiler. It went from being that thing you have to "pass" to see your code work, to instead a faithful companion. Like having a trusted dog with you in the woods - an extra set of senses to help you out on your way.

Elm is not perfect (no language is) -but being perfect isn't the goal. A practical transition story, huge productivity gains and extremely maintainable code.

Re: Elm in Production: 25K Lines Later

#96

Post by dmitriid »

tome wrote: post #92
dmitriid wrote: post #82

Earlier quoted context omitted.

Nope. It's a genuine feeling. Basically, in an ideal world we would have a "pragmatically typed" programming language. Basically something in between "weak dynamic typing of Javascript" and "strong static typing of Haskell". No such language currently exists, and this makes me sad. It's also hard to come up with a proper definition for such a language :)

> Nope. It's a genuine feeling. That's not exclusive with being a troll. > Basically, in an ideal world we would have a "pragmatically typed" programming language. Yes, it's called Haskell. Or, if you don't like purity, either OCaml or F#.

I strongly believe Haskell is very very far from being a "pragmatically typed" language.

This reminds me, I need to write a blog post (which is tangentially about Haskell, but mostly about statically typed languages)

Re: Elm in Production: 25K Lines Later

#97

Post by mrkgnao »

dmitriid wrote: post #88
mrkgnao wrote: post #75

Earlier quoted context omitted.

> You need a PhD in type theory to get anywhere. That is extremely false. Haskell isn't even a good playground for academic type theory -- you'd want Agda etc. for that. The development of the language over the last few years has been characterized by pragmatism and a focus on backwards-compatibility, which is why you can take code from something like ten years ago and have it run without issues on modern versions of…

Commenting on the edited comment :) > Notice that your 5 - 10 lines of JS don't let you write code that works in any monad, whereas I can easily write Maybe, maybe not. Depends on your requirements, really. The core language might never get this, but these 5-10 lines of code do some very important things: - they explain monads faster and clearer than any of the countless monad tutorials that exist for Haskell - they…

Sure! I don't disagree: Haskell learning materials are a far cry from adequate, and we definitely need to learn from, e.g. the Rust/Elixir/Elm communities here. For now, this is worth trying:

http://haskellbook.com/

Also, #haskell on IRC has been, without a doubt, one of the friendliest learning environments I've ever seen. Drop by sometime if the mood strikes you. :)

Re: Elm in Production: 25K Lines Later

#98

Post by mrkgnao »

dmitriid wrote: post #94
mrkgnao wrote: post #89

Earlier quoted context omitted.

Speaking from experience, zero. > debug But the whole point of a good compiler is that it tells you when you're wrong ! (Instead of having to write hundreds of tests (and thousands of Node test runners).) > :> and : You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later. Observe: type API = "polls…

> Speaking from experience, zero. You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later. So, basically, "learn this thing without understanding what it does" :-\ Reminds me of teaching Java to newbies: "oh, just type this syntax, you have to memorize it, don't worry about it". > Definitely less t…

Well, Servant isn't introductory Haskell material. My point was to show that the advanced type system features of modern Haskell are useful in the real world, for, e.g. building webapps that real people use and ship to production.

If you've picked up the stuff in LYAH, you're ready to learn what type operators are (that's where :> and friends come from, they're just things like Maybe but written infix, so they're probably defined as

data a :> b = ColonPointyThing a b

or something like that.) Servant then pattern-matches on these types, essentially. For instance, if I can handle an API that serves endpoint A, and one that serves endpoint B, I can handle an API that serves both:

    instance (Handler A, Handler B) => Handler (A : B) where

       handle req = ...
That's the idea.

You'd hardly expect a beginner to pick up, I dunno, using React and Redux on a Webpack hot-reloadable setup on day 1 of "Javascript 101", but React is one of the best ways to sell modern web development (at least when I've been buying).

Re: Elm in Production: 25K Lines Later

#99

Post by dmitriid »

tome wrote: post #90
dmitriid wrote: post #79

Earlier quoted context omitted.

But they can't, can they. Or we wouldn't have the bazillion monad tutorials. The funny thing, this is the trouble that plagues other Haskell-inspired work (such as Purescript)

It's obvious that the concept of monad can either be explained in 5-10 lines in both JavaScript and Haskell, or neither. Which are you claiming?

It's not obvious.

I'm claiming that:

- the concept of monad can be explained in 5-10 lines in Javascript (demonstrable)

- the concept of a monad requires multiple years and tens of tutorials in Haskell (also demonstrable)

Re: Elm in Production: 25K Lines Later

#100

Post by willtim »

dmitriid wrote: post #88
mrkgnao wrote: post #75

Earlier quoted context omitted.

> You need a PhD in type theory to get anywhere. That is extremely false. Haskell isn't even a good playground for academic type theory -- you'd want Agda etc. for that. The development of the language over the last few years has been characterized by pragmatism and a focus on backwards-compatibility, which is why you can take code from something like ten years ago and have it run without issues on modern versions of…

Commenting on the edited comment :) > Notice that your 5 - 10 lines of JS don't let you write code that works in any monad, whereas I can easily write Maybe, maybe not. Depends on your requirements, really. The core language might never get this, but these 5-10 lines of code do some very important things: - they explain monads faster and clearer than any of the countless monad tutorials that exist for Haskell - they…

This is not really a definition of a Monad. For example, there's no mention of the Monad laws.

Monads are a very general and powerful abstraction that are not adequately described by your example. My advice to anyone is to read Phil Wadler's seminal paper, it is very easy to read.

Post reply on HN