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

Re: Elm in Production: 25K Lines Later

#151

Post by willtim » Mon, Jul 31, 2017, 1:43 PM UTC

dmitriid wrote: post #144

willtim wrote: post #139

Earlier quoted context omitted.

> 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 Again, you are unfortunately quite wrong. You do not understand the IO Monad. No IO is ever performed in any code written inside the IO monad (unless using unsafePerformIO). Please take some time to fully understand Haskell before criticising it so openly on a public…

Basically, the moment you have readFile :: FilePath -> IO String writeFile :: FilePath -> String -> IO () and any function invoking those two (and any functions invoking these function etc. etc.) your "haskell strictly conforms to FP definition" flies out of the window. And yes: I used the term "IO monad" incorrectly.

These functions do not perform IO, they return IO actions that can be further composed. They are invoked from other functions that also return IO actions, again no IO is actually performed until the top-level final composite action is run by the runtime.

All composition of IO actions is performed with full referential transparency and adherence to the Wikipedia definition.

Re: Elm in Production: 25K Lines Later

#152

Post by Kiro » Mon, Jul 31, 2017, 1:47 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…

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

Re: Elm in Production: 25K Lines Later

#153

Post by [deleted] » Mon, Jul 31, 2017, 1:49 PM UTC

willtim wrote: post #129

dmitriid wrote: post #123

Earlier quoted context omitted.

No. It only means that other languages support multiple paradigms. Haskell doesn't strictly conform either, because it allows side effects (event though it's "only through escape hatches"). There's no such thing as a "pure functional programming language". Let's take it from the top: "In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer progr…

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…

[deleted]

Re: Elm in Production: 25K Lines Later

#154

Post by dmitriid » Mon, Jul 31, 2017, 1:57 PM UTC

willtim wrote: post #151

dmitriid wrote: post #144

Earlier quoted context omitted.

Basically, the moment you have readFile :: FilePath -> IO String writeFile :: FilePath -> String -> IO () and any function invoking those two (and any functions invoking these function etc. etc.) your "haskell strictly conforms to FP definition" flies out of the window. And yes: I used the term "IO monad" incorrectly.

These functions do not perform IO, they return IO actions that can be further composed. They are invoked from other functions that also return IO actions, again no IO is actually performed until the top-level final composite action is run by the runtime. All composition of IO actions is performed with full referential transparency and adherence to the Wikipedia definition.

Potato potato. In the end, when the program is run, functions will be run, and side-effects will be executed.

Moreover, if you invoke these functions multiple times they will produce different results.

Hence, no strict adherence to FP principles.

Re: Elm in Production: 25K Lines Later

#155

Post by dmitriid » Mon, Jul 31, 2017, 1:58 PM UTC

dragonwriter wrote: post #127

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

> 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". Souunds like one of the many strong dynamic languages with optional static typing/typechecking.

Yeah. I like approaches taken by OCaml/ReasonML and Typescript. But they are not without their warts :)

Re: Elm in Production: 25K Lines Later

#156

Post by ch4s3 » Mon, Jul 31, 2017, 1:58 PM UTC

dmitriid wrote: post #131

ch4s3 wrote: post #128

Earlier quoted context omitted.

I suppose you start every new project with mkdir and a few touch commands? In all seriousness, ever language has boilerplate. In js it might be error handling and state management. In Elm, its decoding json.

> I suppose you start every new project with mkdir and a few touch commands? This is not a valid analogy (and no analogy is ever valid). > In js it might be error handling and state management. In Elm, its decoding json. Yeah, and Go has trouble with generics. It doesn't mean it's a feature that has to be vigorously defended. Especially if it's basically the very first thing anyone will have to do in any web applicat…

> It doesn't mean it's a feature that has to be vigorously defended.

I'm not sure anyone is defending it. At least, I'm not. Basically Elm's compromise is safety, and less runtime complexity then Haskell. The trade off there is boilerplate. As with most things, there is no free lunch. I've stopped using Elm precisely because of these issues, but I understand why Evan made the choices he did.

Re: Elm in Production: 25K Lines Later

#157

Post by dmitriid » Mon, Jul 31, 2017, 1:59 PM UTC

chriswarbo wrote: post #147

dmitriid wrote: post #68

Earlier quoted context omitted.

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

> Laziness is delayed execution. That's it. There's _nothing_ stopping you from delaying a side effect. Laziness is about more than just side effects. I think "evaluation" or "reduction" would be better words than "execution" here. Laziness (call by need) is an evaluation strategy for (beta-)reducing expressions, which has two nice properties: - If an expression can be reduced without diverging by some evaluation str…

Thank you! I clean forgot about call-by-need vs. call-by-value

Re: Elm in Production: 25K Lines Later

#158

Post by jlouis » Mon, Jul 31, 2017, 2:02 PM UTC

ToJans wrote: post #15

kccqzy wrote: post #13

Earlier quoted context omitted.

That doesn't handle custom JSON schemas at all. I don't know much about Elm but at work in Haskell we mostly write FromJSON instances manually. It's probably the same amount of code as the data type definition.

For custom JSON schemas nothing tops F#'s type providers [0] IMO. [0] https://github.com/jet/JsonSchemaProvider

This is the way to go, if you are tied to JSON for some reason. A far better solution is to get rid of JSON if most of your stack is a typed stack and then convert to JSON as late as possible.

Custom JSON which people invent as they go along is just going to present your system with pain over time.

Re: Elm in Production: 25K Lines Later

#159

Post by askAwayMan » Mon, Jul 31, 2017, 2:05 PM UTC

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.

Re: Elm in Production: 25K Lines Later

#160

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

willtim wrote: post #121

endgame wrote: post #87

Earlier quoted context omitted.

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

Agreed in general, but equality is so fundamental that I could forgive any built-in support. Even Haskell has "deriving Eq" built-in for example.

That said the deriving mechanisms have been mostly exposed to the end used now in at least a few different ways.

Even more importantly, deriving doesn't change the semantics of the language. You could in principle do exactly the same things without deriving as you can with.