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

141–150 of 278 posts

Re: Elm in Production: 25K Lines Later

#141

Post by dmitriid »

willtim wrote: post #139
dmitriid wrote: post #134

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: --- treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. --- > It is much harder to stay true to that definition using the other languages, multi-paradigm or not. I doesn't matter if it's "hard". Your argument was…

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

So, you're telling me that Haskell never does any output and never reads any input.

In this case (an only in this case) would it strictly conform to FP definition.

Re: Elm in Production: 25K Lines Later

#142

Post by dmitriid »

eastWestMath wrote: post #138
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".

Wadler's paper is an excellent piece of exposition that's us at the level of an upper-year undergraduate textbook. There's nothing condescending about referring a professional to a relevant paper in their discipline, but it is troubling when a professional won't even read over a paper.

It's troubling when people assume there's only one paper that a professional should read. Or that a professional cannot choose between papers to read. etc.

Re: Elm in Production: 25K Lines Later

#143

Post by mrkgnao »

dmitriid wrote: post #130
mrkgnao wrote: post #114

Earlier quoted context omitted.

Servant isn't the "simplest" way to get BasicAuth: you get what you pay for. You can just use one of the raw HTTP servers, like wai or something. They expose an interface not unlike the ones you'll find in, say, Go or C++ or Node or something. Also: {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstanc…

> Servant isn't the "simplest" way to get BasicAuth: you get what you pay for. But that's not what I complained about ;) It's funny how in a separate thread someone insists that I have to understand the whole concept of a monad, its three laws, read Wadler's paper etc. In his thread however, it boils down to: oh, just memorise these lines of code, and just blindly copy-paste them wherever. So, my complaint is: to act…

> "simplest way to do BasicAuth"

The simplest way to do BasicAuth in Haskell isn't Servant. I feel like you're intentionally misinterpreting what I'm saying.

As for resources, here's a great intro to type-level Haskell:

http://www.parsonsmatt.org/2017/04/26/basic_type_level_progr...

> For some reason, functions that operate on types are called type families.

That's the kind of thing you need to know.

I doubt the average JS user knows how V8 optimizes execution of code, or whatever. That's what your insistent complaints about type theory amounts to: none of the articles I'm linking to mention inference rules or type judgments or what-have-you. That's what all the research papers about Haskell are for, which you do not need to read to use this language. Even advanced Haskellers don't do type theory (category theory, maybe, not type theory). Only a couple of people working on the compiler do.

More DataKinds:

https://stackoverflow.com/questions/20558648/what-is-the-dat...

http://ponies.io/posts/2014-07-30-typelits.html

https://www.schoolofhaskell.com/user/k_bx/playing-with-datak...

Re: Elm in Production: 25K Lines Later

#144

Post by dmitriid »

willtim wrote: post #139
dmitriid wrote: post #134

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: --- treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. --- > It is much harder to stay true to that definition using the other languages, multi-paradigm or not. I doesn't matter if it's "hard". Your argument was…

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

Re: Elm in Production: 25K Lines Later

#145

Post by dmitriid »

mrkgnao wrote: post #143
dmitriid wrote: post #130

Earlier quoted context omitted.

> Servant isn't the "simplest" way to get BasicAuth: you get what you pay for. But that's not what I complained about ;) It's funny how in a separate thread someone insists that I have to understand the whole concept of a monad, its three laws, read Wadler's paper etc. In his thread however, it boils down to: oh, just memorise these lines of code, and just blindly copy-paste them wherever. So, my complaint is: to act…

> "simplest way to do BasicAuth" The simplest way to do BasicAuth in Haskell isn't Servant. I feel like you're intentionally misinterpreting what I'm saying. As for resources, here's a great intro to type-level Haskell: http://www.parsonsmatt.org/2017/04/26/basic_type_level_progr... > For some reason, functions that operate on types are called type families. That's the kind of thing you need to know. I doubt the aver…

> The simplest way to do BasicAuth in Haskell isn't Servant. I feel like you're intentionally misinterpreting what I'm saying.

True, I re-read what you wrote, and argh. I need to learn to read.

> As for resources, here's a great intro to type-level Haskell: > That's the kind of thing you need to know.

So, we're basically returning to the root of my complaints

> I doubt the average JS user knows how V8 optimizes execution of code

Wait. Are you telling me now is that writing a BasicAuth implementation in a "simple library that doesn't require you to have a PhD in type theory" is on the same level of complexity as knowing the inner workings of an advanced Javascript VM?

> That's what your insistent complaints about type theory amounts to: none of the articles I'm linking to mention inference rules or type judgments or what-have-you.

No, they don't.

I'm looking at Servant and its examples. In order to write an extremely simple and basic piece of code, I, as a programmer:

- have to pull in no less than 10 language extensions

- five of those extensions are just workarounds some obscure Haskell rules (?)

- in order to understand just the basics of what's going on in there I need to know why when and where these extensions are used, how they work etc.

What happens the moment I step outside the bare necessities of the extremely simple BasicAuth implementation, for instance?

> More DataKinds:

This exactly what I wrote: as soon as you step outside into a real world of Haskell, oh "here's a list of increasingly obscure things you need to know. Maybe two people on StackOverflow know about them. For the rest, please proceed to your nearest university to obtain a PhD or two".

Re: Elm in Production: 25K Lines Later

#146

Post by willtim »

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

So, you're telling me that Haskell never does any output and never reads any input. In this case (an only in this case) would it strictly conform to FP definition.

Haskell is used to wire-up the IO actions, they are then delivered to the runtime via the main definition. The runtime performs the IO actions.

Re: Elm in Production: 25K Lines Later

#147

Post by chriswarbo »

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

> 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 strategy, then it can be reduced without diverging using call by need.

- Efficiency, in the sense that no duplicated work is performed.

The other common evaluation strategies are call by name and call by value. Call by name has the first property, but not the second; so there are cases when it's exponentially slower than call by need. Call by value has the second property, but not the first, so there are cases when it diverges unnecessarily.

This 'unnecessary divergence' is a major reason why most programming languages end up overly complicated to understand (at least, mathematically). For example, consider something like a pair `(cons x y)`, and its projection functions `car` and `cdr`. We might want to describe their behaviour like this:

    ∀x. ∀y. (car (cons x y)) = x
    ∀x. ∀y. (cdr (cons x y)) = y
This is perfectly correct if we're using call by name or call by need, but it's wrong if we're using call by value. Why? Because under call by value `(car (cons x y))` and `(cdr (cons x y))` will diverge if either `x` or `y` diverges. Since the right-hand-sides only contain one variable each, they don't care whether or not the other diverges.

This is why Haskell programs can focus on constructing and destructing data, whilst most other languages must concern themselves with control flow at every point (branching, looping, divergence, delaying, forcing, etc.).

Re: Elm in Production: 25K Lines Later

#148

Post by maxiepoo »

Albert_Camus wrote: post #42
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…

Author here. As I posted in a different reply: JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object. In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just…

Can you not do the same thing as JSON.parse() in Elm by parsing into an unstructured JSON type?

Re: Elm in Production: 25K Lines Later

#149

Post by Existenceblinks »

Albert_Camus wrote: post #40
therealmarv wrote: post #35

When JSON decoding is hard this is not a minor thing when looking at my RESTful APIs. This is a major trade off. How to deal with it ideally?

Author here. JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object. In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just decoding to primitive values or t…

> JSON decoding is hard relative to what it is like in JavaScript

I'm not making a joke but this is a valid point. And if it had ELMON (Elm object notation), things would be more straight forward.

Re: Elm in Production: 25K Lines Later

#150

Post by antouank »

StreamBright wrote: post #125
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 am more interested in the details that just this blank statement that everything is better. After trying Elm several times we failed to implement even basic things in it that we could do in React/Redux easily. For an average JS developer Elm is totally alien tech compare to React or Angular. For Haskell programmers Elm is pretty appealing because of the familiar syntax and type system, but the intersection of Haske…

     For an average JS developer Elm is totally alien tech compare to React or Angular
To turn your argument the other way. The JS landscape, where "trendy" libraries change every few months, is also alien to anyone that doesn't keep with the latest libraries every few months. Is that not worse? I don't have to explain "JS fatigue", it's a fact.

For example, I just got into a new team, and I have to now use what they use. I've been doing JS for 4+ years, and that stack I'm facing now, is alien and confusing to me. I have to invest time and learn what the hell those redux-sagas are, or what "magic" create-react-app tools hide, and in general, it's very confusing so far.

With Elm, I spent a few weeks 1 year ago to learn the language, and that was it. All the libraries are very simple to use because of the language. I doubt that learning "redux-sagas" will help me a year from now.

Also, Elm, gives a very coherent package. You don't have to transpile or add a linter, or a type checker, or stitch new libraries every few months because the trend changed. No webpack or babel or eslint or immutable.js or typescript or flow or any of those.

Not to go into the part of the safety and confidence the compiler gives you. Typescript or flow are not even close to that quality and guarantee level. Note that again you have to learn their syntax and configure them, so that's again a cost on top of learning JS. And they are as much alien as Elm.

FWIW, I start now side-projects in Elm, and I get things done way faster than with JS. And that's also what I see from other people as well, regardless of whether they come from JS or another language.

Post reply on HN