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

81–90 of 278 posts

Re: Elm in Production: 25K Lines Later

#81

Post by dmitriid »

mrkgnao wrote: post #75
dmitriid wrote: post #63

Earlier quoted context omitted.

Short version: You need a PhD in type theory to get anywhere. Basically every obscure overly complicated concept that Haskell throws at you (all the while pretending to be the only true FP language out there) can be explained in 5 to 10 lines of Javascript: https://github.com/hemanth/functional-programming-jargon Compare and contrast. - Monad explained in Javascript: https://github.com/hemanth/functional-programming-…

> 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…

> 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.?

Re: Elm in Production: 25K Lines Later

#82

Post by dmitriid »

tome wrote: post #76
dmitriid wrote: post #70

Earlier quoted context omitted.

Nope. The solution is actually "more pragmatism", not "here's a thing that requires a PhD in type theory to understand".

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 :)

Re: Elm in Production: 25K Lines Later

#83

Post by kahnpro »

masklinn wrote: post #23
dmjio wrote: post #17

Earlier quoted context omitted.

If you want a powerful type system (i.e. Haskell), but the benefits of Elm, Miso is a project that implements the Elm Architecture in Haskell. It obviously has typeclasses, and can encode / decode JSON on the frontend using GHC.Generics quite well. https://github.com/dmjio/miso

There's also Purescript, which is built for the web but has many of the goodies you'd expect from Haskell.

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.

Re: Elm in Production: 25K Lines Later

#84

Post by mrkgnao »

dmitriid wrote: post #80
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…

> This is extremely false [referring to "You need a PhD in type theory to get anywhere."] almost immediately followed by > And I'd really like to see type class constraint resolution, or Hindley-Milner type checking You don't even see the irony in that, do you? > they don't take much more code in Haskell: riiight. I won't even go into the number of things that need to be explained there before you even start explaini…

I hadn't really finished editing my comment then. (I was eating at the time, haha.) I just saw your reply now.

Re: Elm in Production: 25K Lines Later

#85

Post by willtim »

dmitriid wrote: post #78
willtim wrote: post #72

Earlier quoted context omitted.

You certainly would need a PhD to fully understand Monads from that small JavaScript snippet. The Haskell link you gave gives Phil Wadler's original paper as the first link. It is easy to read, explains everything beautifully and full of many examples. Learn some basic Haskell for no other reason than to read seminal papers such as these. To favour some random JavaScript hacker on the internet and steer others away f…

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.

Re: Elm in Production: 25K Lines Later

#86

Post by dmitriid »

mrkgnao wrote: post #84
dmitriid wrote: post #80

Earlier quoted context omitted.

> This is extremely false [referring to "You need a PhD in type theory to get anywhere."] almost immediately followed by > And I'd really like to see type class constraint resolution, or Hindley-Milner type checking You don't even see the irony in that, do you? > they don't take much more code in Haskell: riiight. I won't even go into the number of things that need to be explained there before you even start explaini…

I hadn't really finished editing my comment then. (I was eating at the time, haha.) I just saw your reply now.

So, you could say your comment was ... lazy?

(huehuehue, lame joke, I know :) )

Re: Elm in Production: 25K Lines Later

#87

Post by endgame »

willtim wrote: post #33
endgame wrote: post #20

Earlier quoted context omitted.

That's exactly what I mean: A type like a -> a -> Bool says that it will work for _any_ a, but we can easily find counter examples. We could pass in functions (say) and write something like (\x -> x * 2) == (\x -> x + 1). The type signature for (==) as written says it _should_ work, but it doesn't because there's no general way to compute function equality. Instead, there's this temporary hack[0]: > Note: Equality (i…

It we would be easy to add simple built-in constraints for things like equality, without jumping all the way to full-blown type classes. This would be a very minimal change to the type checker and should not require a rewrite.

I'm not thrilled by languages the do "rules for thee, not for me". (Another example: old Java had a two-valued enum type (bool) but you weren't allowed to make your own.)

Re: Elm in Production: 25K Lines Later

#88

Post by dmitriid »

mrkgnao wrote: post #75
dmitriid wrote: post #63

Earlier quoted context omitted.

Short version: You need a PhD in type theory to get anywhere. Basically every obscure overly complicated concept that Haskell throws at you (all the while pretending to be the only true FP language out there) can be explained in 5 to 10 lines of Javascript: https://github.com/hemanth/functional-programming-jargon Compare and contrast. - Monad explained in Javascript: https://github.com/hemanth/functional-programming-…

> 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 demystify monads and show that: hey, you've probably been writing monads all along (and re-implemented them yourself countless of times, no doubt)

- they (by necessity) dumb down the jargon-heavy lingo for easy consumption by average Joes like me :)

Edit: that page in particular has also shown me that I have used easily half of Haskell's things (functors of all flavors, monads, comonads, etc. etc. etc.) countless times over the years in Javascript and Erlang. I didn't even know I did, because no one scared me off with the theory, and strange explanations and names :)

Re: Elm in Production: 25K Lines Later

#89

Post by mrkgnao »

dmitriid wrote: post #81
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…

> 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"                                           :> Get  '[JSON] [Poll]
          : "polls" :> Capture "question_id" Int              :> Get  '[JSON]  Poll
          : "polls" :> Capture "question_id" Int :> "results" :> Get  '[JSON]  PollResults
The :> operator separates parts of a path, and the : separates different URL patterns. This is the equivalent of this API from the Django documentation:

    urlpatterns = [
        # ex: /polls/
        url(r'^$', views.index, name='index'),
        # ex: /polls/5/
        url(r'^(?P[0-9]+)/$', views.detail, name='detail'),
        # ex: /polls/5/results/
        url(r'^(?P[0-9]+)/results/$', views.results, name='results')
    ]
The only difference is it has less regexes in it, is capable of being checked for nonsense by a compiler much smarter than me, and gives you the aforementioned "server for free". I have had URL pattern-match errors with Django in the past, and having your compiler check that there aren't any is excellent.

Easier to maintain? Check.

Easier to read? Check. (If nothing, because of the lack of regexes.)

Defines the response type too? Check.

Easy to refactor? Check! Tired of typing "polls" at the beginning? Just lift it out: turn

    type API = "polls"                                           :> Get  '[JSON] [Poll]
          : "polls" :> Capture "question_id" Int              :> Get  '[JSON]  Poll
          : "polls" :> Capture "question_id" Int :> "results" :> Get  '[JSON]  PollResults
into

    type API = "polls" :> 
             (                                            Get  '[JSON] [Poll]
          :  Capture "question_id" Int              :> Get  '[JSON]  Poll
          :  Capture "question_id" Int :> "results" :> Get  '[JSON]  PollResults
             )
Types are first-class :)

> How many PhDs does one require to understand/correct/debug all the :> and : etc.?

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?

Re: Elm in Production: 25K Lines Later

#90

Post by tome »

dmitriid wrote: post #79
tome wrote: post #73

Earlier quoted context omitted.

> Basically every obscure overly complicated concept that Haskell throws at you (all the while pretending to be the only true FP language out there) can be explained in 5 to 10 lines of JavaScript So presumably the same concepts can be explained in 5 to 10 lines of Haskell too. I think you're confusing the refinement and polishing of ideas that's taken place in Haskell over the last two decades with the succinct pres…

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?
Post reply on HN