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

Re: Elm in Production: 25K Lines Later

#131

Post by dmitriid » Mon, Jul 31, 2017, 12:40 PM UTC

ch4s3 wrote: post #128

dmitriid wrote: post #110

Earlier quoted context omitted.

If you need a code generator to generate boilerplate... something's wrong with your language

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 application in a language that is meant for client-side web programming

Re: Elm in Production: 25K Lines Later

#132

Post by dmitriid » Mon, Jul 31, 2017, 12:41 PM UTC

mrkgnao wrote: post #124

dmitriid wrote: post #117

Earlier quoted context omitted.

"People using something in industry" is rarely an indicator of anything, really. Industry uses everything and anything. Heck, Javascript is (arguably) world's most popular programming language, used everywhere . Haskell is used by Chase Bank. J and K are used by banks (J is used by SAP AFAIK). There are stories of Smalltalk running entire factories. There's Active Oberon in a nuclear plant in France. Excel is the wor…

> Haskell is used by Chase Bank. Also a ton of other financial services companies: Morgan Stanley, Standard Chartered, and so on. Facebook has, in the recent past, hired a lot of well-known Haskellers. Bunch of hedge fund-ish things do too. Jane Street uses OCaml and does a lot of AdWords targeting at Haskell users :P I don't know a shred of "type theory" (although I'm interested): you probably mean something else. M…

> why don't you make a good-faith effort to dive into Haskell (as opposed to learning just enough of the jargon to be able to troll with apparent seriousness)

Why don't you make a good-faith effort to assume that your opponent has actually done some good-faith efforts?

Re: Elm in Production: 25K Lines Later

#133

Post by jnbiche » Mon, Jul 31, 2017, 12:43 PM UTC

BoiledCabbage wrote: post #95

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 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. I completely agree - I will be a huge benefit to the industry when elm is as common as js. The concepts it introduces, the benefits it shows are all huge. I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her comp…

> I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler.

I love Elm as much as the next guy, but be aware that you can get many, if not most, of these same benefits while working in JS if you use Flow.js or Typescript. I prefer Flow because the community is more oriented toward functional programming vs OOP in Typescript, but they're both capable static analyzers for JS.

Re: Elm in Production: 25K Lines Later

#134

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

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 that "Only Haskell strictly conforms to that definition."

No. Haskell conforms stricter. It doesn't mean that none of the other languages are not FP, or cannot be used to program in functional style.

> That is why Haskell is so often mentioned in the context of FP.

Yes. And the problem is that people treat the features that Haskell has as requirements to be considered a functional programming language.

- Typeclasses/Liquid types/Dependent types are not FP

- Pattern matching is not FP

- Laziness is not FP

- A whole bunch of anything else is not FP

Re: Elm in Production: 25K Lines Later

#135

Post by dmitriid » Mon, Jul 31, 2017, 12:53 PM UTC

mrkgnao wrote: post #122

dmitriid wrote: post #118

Earlier quoted context omitted.

The entire "concept" of a monad fits in that description I linked to. It can be easily reused (which I've done numerous times with it, and with other concepts on that page). Haskell for some reasons insists that I should only go for "The concept of a monad, which arises from category theory, has been applied by Moggi to structure the denotational semantics of programming languages" and A monad is a triple (M,unit,⋆)…

Yes, you should care about the laws! They allow you to edit code without the aforementioned released-last-week test runner having to check all your code after a big refactor. I mean, you can't call something with a "flatMap" method and a "return" method a monad! There are tons of nonsensical definitions that fit that which are going to become very unpleasant to use quickly.

> They allow you to edit code without the aforementioned released-last-week test runner having to check all your code after a big refactor.

Oh wow. How did I ever live with big refactorings before?

> There are tons of nonsensical definitions that fit that which are going to become very unpleasant to use quickly.

I recently learned that, apparently, I've been using "monads" and "monadic composition" for years now, never knowing what it is. Can't remember any unpleasantness that would "quickly arise".

There are other things than blind following after a Platonic ideal.

Re: Elm in Production: 25K Lines Later

#136

Post by mjaniczek » Mon, Jul 31, 2017, 12:56 PM UTC

hellofunk wrote: post #120

mjaniczek wrote: post #115

Earlier quoted context omitted.

I believe you can use Google Closure Compiler on Elm JS files with great effect the same as Leiningen uses it on ClojureScript JS files. (Although most people probably use uglifyjs instead.) But of course ClojureScript's JS is generated carefully so as to be better optimizable by Google Closure Compiler, and that's not the case with Elm. IIRC, in version 0.19 Elm will change it's JS so that it's better optimizable by…

> I believe you can use Google Closure Compiler on Elm JS files with great effect No, you can't use the advanced optimizations from Closure compiler in Elm. This is unlikely to change any time soon because Elm's compiler emits JS that directly violates one of the restrictions that Closure requires for advanced optimizations, namely the referencing of field names as a string.

Good to know, thanks!

Re: Elm in Production: 25K Lines Later

#137

Post by bandrami » Mon, Jul 31, 2017, 12:58 PM UTC

I wonder if its successor framework will be called pine.

Re: Elm in Production: 25K Lines Later

#138

Post by eastWestMath » Mon, Jul 31, 2017, 12:59 PM UTC

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

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.

Re: Elm in Production: 25K Lines Later

#139

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

dmitriid wrote: post #134

willtim wrote: post #129

Earlier quoted context omitted.

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…

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 forum. Perhaps then it might not all seem rather pointless.

Re: Elm in Production: 25K Lines Later

#140

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

Whenever something about elm pops up, I see people complaining about this. Reminds me of people complaining about Golang missing feature X. Still both languages raising in popularity. I haven't used Elm or Golang, but I'm almost convinced that simplicity is a driving factor for their success.