Elm in Production: 25K Lines Later • Hacker News Board

Re: Elm in Production: 25K Lines Later

#161

Post by tel » Mon, Jul 31, 2017, 2:10 PM UTC

Kiro wrote: post #152

ykler wrote: post #61

Earlier quoted context omitted.

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…

I don't know Haskell but how is laziness related to FP?

The only way I can think to relate them is (a) FP tends to highlight the importance of value-semantics over all others, (b) non-termination is an effect, (c) FP also, subsequent to a, tends to emphasize control of side effects, (d) in a terminating lambda calculus all evaluation strategies are confluent/equal under the value-semantics, thus (e) laziness is particularly _available_ in a FP language.

Re: Elm in Production: 25K Lines Later

#162

Post by runeks » Mon, Jul 31, 2017, 2:15 PM UTC

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.

This example with the absence of an Eq class is not related to just equality, it’s a symptom of a lack of generics. You’ll end up with a lot of special, built-in classes (e.g. Ord), while just adding simple type classes to Elm would make all of this solvable in a library (e.g. Elm’s Prelude).

Surely, if we agree that Eq, Ord, and Foldable are useful, they’re probably not the only useful type classes in existence.

Re: Elm in Production: 25K Lines Later

#163

Post by Ar-Curunir » Mon, Jul 31, 2017, 2:15 PM UTC

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.

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

Re: Elm in Production: 25K Lines Later

#164

Post by Ar-Curunir » Mon, Jul 31, 2017, 2:16 PM UTC

dmitriid wrote: post #70

mrkgnao wrote: post #69

Earlier quoted context omitted.

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

99% of Rust programmers don't have PhDs, I'm sure, and yet they use typeclasses (called traits in Rust) just fine...

Re: Elm in Production: 25K Lines Later

#165

Post by tel » Mon, Jul 31, 2017, 2:16 PM UTC

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…

Is it fair to say that your argument here is that "this resource was extremely valuable to me for understanding certain concepts in ways that Haskell-oriented resources in the past have not been"?

I think that's a totally fair criticism. I also believe that the Haskell resources can provide further value to you (and others in your position) over time if you choose to study them. Similarly, studying category theory or type theory or logic could.

Are these practical things to do? It depends upon your goals.

Re: Elm in Production: 25K Lines Later

#166

Post by enalicho » Mon, Jul 31, 2017, 2:16 PM UTC

desireco42 wrote: post #116

enalicho wrote: post #44

Earlier quoted context omitted.

You don't need to switch a whole language because of JSON decoding. There are many tools that exist to aid you write JSON decoders in Elm. The language is not just about the architecture -- you can implement the architecture in any language, as Redux has proven. What people like about Elm is the compiler and design philosophy that radiates through the entire community. Switching to Haskell won't give you that, as the…

Oh, this is awesome, json2elm really helps :) thanks, didn't know about it.

No problem! Glad you found it useful :) It's not perfect by any means, but it's not meant to be.

Re: Elm in Production: 25K Lines Later

#167

Post by Ar-Curunir » Mon, Jul 31, 2017, 2:17 PM UTC

askAwayMan wrote: post #159

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

Purescript's Argonaut lib has major performance issues that are incurred for the "powerful type system." When you only have thousands of items in an array, you end up with performance discrepancies between older browsers like IE 11 and Chrome that are unacceptable outside of a toy application.

On the other hand, something like Rust has similar typeclasses, and runs blazingly fast. Serde JSON is super quick and efficient.

Re: Elm in Production: 25K Lines Later

#168

Post by KirinDave » Mon, Jul 31, 2017, 2:19 PM UTC

askAwayMan wrote: post #159

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

Purescript's Argonaut lib has major performance issues that are incurred for the "powerful type system." When you only have thousands of items in an array, you end up with performance discrepancies between older browsers like IE 11 and Chrome that are unacceptable outside of a toy application.

> Purescript's Argonaut lib has major performance issues that are incurred for the "powerful type system."

Can you explain what you mean here? Your explanation below suggests a runtime cost for the type system, which just isn't true.

I'm aware Argonaut's approach generates slower code. The nice part of any such happenstance in PureScript is that if you do find an issue it's easy to bang out some Javascript in a foreign call to do what you need.

I find outside of Slamdata, folks are keen to do this. PureScript is a very new language and is still finding ways to generate code efficiently in it's target environment.

Re: Elm in Production: 25K Lines Later

#169

Post by KirinDave » Mon, Jul 31, 2017, 2:19 PM UTC

kahnpro wrote: post #83

masklinn wrote: post #23

Earlier quoted context omitted.

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.

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

Re: Elm in Production: 25K Lines Later

#170

Post by runeks » Mon, Jul 31, 2017, 2:20 PM UTC

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…

You’re mixing up laziness and purity. Purity makes side effects impossible, so to speak, not laziness.

Haskell is the most functional language because a Haskell function is a mathematical function, which can only transform its arguments into a value. Everything is a constant in Haskell, and functions transform one or more constants into a single, new constant.