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

61–70 of 278 posts

Re: Elm in Production: 25K Lines Later

#61

Post by ykler »

dmitriid wrote: post #37
endgame wrote: post #4

I'm really looking forward to the day when all these new-to-Elm people start hitting the complexity ceiling of their language and convince the maintainers to add just a little more power. Example: Haskell's typeclasses have a high power-to-weight ratio, and Elm has to work around their absence (e.g., writing a fresh map function for each data type). Once there's a critical mass of frontend types who understand the po…

Can't for the life of me figure out why people equate FP with the abomination that Haskell is. Erlang is FP. Javascript is FP. Ocaml is FP. Type classes, or anything else that has "types" in them such as dependent, or liquid, are not FP, they are types. Types that found their way into a couple of FP languages.

I don't think many people (and not the parent) "equate" FP with Haskell, but Haskell is in a way the most functional mainstream language because it is the only lazy one. You can have a purely functional language without laziness in principle, but, as Simon Peyton-Jones points has said, laziness, despite having serious costs, keeps a language designer honest by making it impossible to add side effects. The non-lazy languages all have side effects. A language like OCaml can still be relatively functional because of the way it is typically used. While JavaScript is not traditionally used in a functional way but can be.

http://www.cs.nott.ac.uk/~gmh/appsem-slides/peytonjones.ppt

Re: Elm in Production: 25K Lines Later

#62

Post by hellofunk »

niels wrote: post #36

When I last tried Elm, I didn't find any really good UI libraries. Also there weren't any good solutions for i18n. Has the situation changed?

Depends on your needs. If you are targeting desktop, there are a couple of UI libraries for Elm. However, they are buggy when you try to test them out on a mobile tablet. I have found that most Elm developers create their own UIs since wider access to JS UI toolkits is not easy. That does mean that you need to enjoy general web design or work with a designer, or be willing to put in extra time when working in Elm.

Re: Elm in Production: 25K Lines Later

#63

Post by dmitriid »

farresito wrote: post #55
dmitriid wrote: post #37

Earlier quoted context omitted.

Can't for the life of me figure out why people equate FP with the abomination that Haskell is. Erlang is FP. Javascript is FP. Ocaml is FP. Type classes, or anything else that has "types" in them such as dependent, or liquid, are not FP, they are types. Types that found their way into a couple of FP languages.

What makes you say Haskell is an abomination?

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-jargon#mon...

- Timeline (sic!) of monad tutorials for Haskell: https://wiki.haskell.org/Monad_tutorials_timeline

The worst crime against humanity though is Haskell crap seeping into other languages (such as ramda, for instance: http://ramdajs.com)

Re: Elm in Production: 25K Lines Later

#64

Post by willtim »

dmitriid wrote: post #37
endgame wrote: post #4

I'm really looking forward to the day when all these new-to-Elm people start hitting the complexity ceiling of their language and convince the maintainers to add just a little more power. Example: Haskell's typeclasses have a high power-to-weight ratio, and Elm has to work around their absence (e.g., writing a fresh map function for each data type). Once there's a critical mass of frontend types who understand the po…

Can't for the life of me figure out why people equate FP with the abomination that Haskell is. Erlang is FP. Javascript is FP. Ocaml is FP. Type classes, or anything else that has "types" in them such as dependent, or liquid, are not FP, they are types. Types that found their way into a couple of FP languages.

What definition of FP are you using? Because if it's just first-class functions, even Visual Basic has this now.

Re: Elm in Production: 25K Lines Later

#65

Post by nnq »

> One simple example is that of a three-way state

What follows after this line is the most artificially complicated description of a problem I've ever seen... basically an excuse for the solution OP then goes on to suggest!

Actually the more functional way to think of the artificially complicated problem OP describes here would be to have 2 data holders, a `myTagsData` and `myEditedTagsData` data, and when the user edits around `myEditedTags` is updated/synced, and when "Save" is clicked `myTagsData` gets replaced with `myEditedTagsData`... and we simply re-render based on new data in the context of a simple one way flow (hint: use React or something similar to not re-invent the wheel).

Yea, sure, you can avoid state at all costs but you can also learn to properly manage state!

There are places where one or the other is a good fit... but doing the former in order to avoid the latter is just "mental masturbation" imho... and the kind of things that disgusts some smart people and keeps them away from functional programming actually :(

Re: Elm in Production: 25K Lines Later

#67

Post by dmitriid »

willtim wrote: post #64
dmitriid wrote: post #37

Earlier quoted context omitted.

Can't for the life of me figure out why people equate FP with the abomination that Haskell is. Erlang is FP. Javascript is FP. Ocaml is FP. Type classes, or anything else that has "types" in them such as dependent, or liquid, are not FP, they are types. Types that found their way into a couple of FP languages.

What definition of FP are you using? Because if it's just first-class functions, even Visual Basic has this now.

Exactly.

Let's take Wikipedia:

-- start quote --

In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions[1] or declarations[2] instead of statements. In functional code, the output value of a function depends only on the arguments that are passed to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) each time

-- end quote --

Re: Elm in Production: 25K Lines Later

#68

Post by dmitriid »

ykler wrote: post #61
dmitriid wrote: post #37

Earlier quoted context omitted.

Can't for the life of me figure out why people equate FP with the abomination that Haskell is. Erlang is FP. Javascript is FP. Ocaml is FP. Type classes, or anything else that has "types" in them such as dependent, or liquid, are not FP, they are types. Types that found their way into a couple of FP languages.

I don't think many people (and not the parent) "equate" FP with Haskell, but Haskell is in a way the most functional mainstream language because it is the only lazy one. You can have a purely functional language without laziness in principle, but, as Simon Peyton-Jones points has said, laziness, despite having serious costs, keeps a language designer honest by making it impossible to add side effects. The non-lazy la…

> Haskell is in a way the most functional mainstream language

1. Is it the most functional language because it's lazy? No

2. Is it the most mainstream language because it's lazy? No

3. Is it the most functional mainstream language because it's lazy? No + no = no

Laziness does not a functional language make.

> You can have a purely functional language

What would be the purpose of a pure FP? Oh. There would be no purpose.

> laziness ... keeps a language designer honest by making it impossible to add side effects

wat

Laziness is delayed execution. That's it. There's _nothing_ stopping you from delaying a side effect.

Re: Elm in Production: 25K Lines Later

#69

Post by mrkgnao »

dmitriid wrote: post #38

> making very heavy use of Ajax calls to a JSON-based RESTful API and then > 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. Doing this will require an understanding of how JSON decoding works in Elm and will usually result in quite a bit of code (our application contains over 900 lines of JSON decoders alone). What a great p…

The solution isn't more "pragmatism", it's an actual "incredibly powerful type system" like Haskell's. In my projects JSON decoding is just

    instance FromJSON Foo
and that's it.

Re: Elm in Production: 25K Lines Later

#70

Post by dmitriid »

mrkgnao wrote: post #69
dmitriid wrote: post #38

> making very heavy use of Ajax calls to a JSON-based RESTful API and then > 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. Doing this will require an understanding of how JSON decoding works in Elm and will usually result in quite a bit of code (our application contains over 900 lines of JSON decoders alone). What a great p…

The solution isn't more "pragmatism", it's an actual "incredibly powerful type system" like Haskell's. In my projects JSON decoding is just instance FromJSON Foo and that's it.

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