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

121–130 of 278 posts

Re: Elm in Production: 25K Lines Later

#121

Post by willtim »

endgame wrote: post #87
willtim wrote: post #33

Earlier quoted context omitted.

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.

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.

Re: Elm in Production: 25K Lines Later

#122

Post by mrkgnao »

dmitriid wrote: post #118
mrkgnao wrote: post #113

Earlier quoted context omitted.

It's code reuse for concepts. Wouldn't you agree that reusing intuition about things is good? It's the same as knowing what big-O is instead of just memorizing "bubble sort is slower than insertion sort, insertion sort is sometimes faster than quicksort but usually not", or knowing what concurrency is instead of memorizing the API of a library in your favorite language.

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.

Re: Elm in Production: 25K Lines Later

#123

Post by dmitriid »

willtim wrote: post #119
dmitriid wrote: post #67

Earlier quoted context omitted.

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…

Only Haskell strictly conforms to that definition. None of your other examples do.

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 programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data."

All of the languages I listed support this style. The moment you write an IO monad inside a function in Haskell, you break the illusion of Haskell's strict conformation to the definition.

Re: Elm in Production: 25K Lines Later

#124

Post by mrkgnao »

dmitriid wrote: post #117
mrkgnao wrote: post #101

Earlier quoted context omitted.

Type classes are basically interfaces from Java. I'm guessing from your other comments that you know Java (and have read LYAH), so this is actually trolling. The majority of people writing the goddamned Haskell compiler don't have PhDs, they're people using it in industry.

"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. Monad transformers aren't even categorical abstractions; they evolved from the needs of Haskell users.

> Haskell has always been and remains a language not opposed to testing multiple theories of language and types design

There, fixed that for you. Seriously, 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) before lambasting the things that make it a joy to work with?

Re: Elm in Production: 25K Lines Later

#125

Post by StreamBright »

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 Haskell programmers and frontend developers are pretty small.

Re: Elm in Production: 25K Lines Later

#126

Post by [deleted] »

quchen wrote: post #12
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…

> writing a fresh map function for each data type You have to do that in Haskell as well (where »you« can be you or the compiler via DeriveFunctor); the key difference is at the use site: there is one map function (called fmap) that does the mapping, whereas in Elm (and pretty much all other languages that don’t have higher kinds while we’re at it) you have to use the specific map function for that type.

[deleted]

Re: Elm in Production: 25K Lines Later

#127

Post by dragonwriter »

dmitriid wrote: post #82
tome wrote: post #76

Earlier quoted context omitted.

At this point you just sound like a troll.

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.

Re: Elm in Production: 25K Lines Later

#128

Post by ch4s3 »

dmitriid wrote: post #110
enalicho wrote: post #102

Earlier quoted context omitted.

It is no different from using a code generator for anything. Json2elm is designed to _help you_ write decoders, not replace decoders. Once you know how to write them, json2elm is mostly useful for generating boilerplate.

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.

Re: Elm in Production: 25K Lines Later

#129

Post by willtim »

dmitriid wrote: post #123
willtim wrote: post #119

Earlier quoted context omitted.

Only Haskell strictly conforms to that definition. None of your other examples do.

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 pragmas and/or compiler switches.

It is much harder to stay true to that definition using the other languages, multi-paradigm or not. That is why Haskell is so often mentioned in the context of FP.

Re: Elm in Production: 25K Lines Later

#130

Post by dmitriid »

mrkgnao wrote: post #114
dmitriid wrote: post #112

Earlier quoted context omitted.

The docs are nice, but they complement the code :) Basically to actually understand what's going on, I'll need to learn DataKinds (at the very least). And just to implement something as simple as BasicAuth, this is what I have to start with ( https://haskell-servant.readthedocs.io/en/stable/tutorial/Au... ): {-# LANGUAGE DataKinds #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE Flexi…

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 actually understand what's going in the "simplest way to do BasicAuth" I need a whole lot more than just look at the code.

I need to understand why I need no less than ten (!) language extensions before I even begin to implement BasicAuth. And five of them just to workaround some Haskell limitation based on some report from 1998 (I'm guessing)? What happens when I move on to OAuth? What will I need then?

Also, "oh, you don't really need PhDs in type theory to use Servant" slowly descends to "oh, here are two things regarding types that you'll have to learn". On of them has no useable documentation except some comment on StackOverflow. The other one requires you to be well-versed in type theory.

Hence my complaint about "you need a PhD in type theory to work with Haskell".

Post reply on HN