Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elm from a Business Perspective

gizra.com

Post reply on HN
Print view View original

21–30 of 79 posts

Re: Elm from a Business Perspective

#21

Post by wyager »

rtfeldman wrote: post #9
tomtheelder wrote: post #5

Earlier quoted context omitted.

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. Elm certainly has a lot of boilerplate compared to Haskell, but that might not be a fair comparison as they don't really have a shared use case. Elm ends up with considerably less, in my opinion, than something like React/Redux.

> Elm certainly has a lot of boilerplate compared to Haskell This is not true based on my experiences with Elm and my knowledge of Haskell. Could you elaborate on why you are certain of this?

Haskell has much more powerful polymorphism as provided by typeclasses and various extensions like Multi-parameter typeclasses. Haskell, more than any other production-ready language, is able to encapsulate the essence of "doing the same thing in a different context", which means you can easily write code that is reusable to a degree not imaginable in most languages.

For example, the expression "fold", from Data.Foldable, is capable of doing anything from concatenating all the strings in a set to adding up all the probability distributions in a sequence. This is a contrived example, but it's super useful in practice. It's hard to imagine all the code reuse you can get, especially as a library author, without using Haskell for a while.

The most obvious cases are Ord and Eq, where things like maps and sets can contain any orderable type, rather than just a few types like String and Int.

Re: Elm from a Business Perspective

#22

Post by vvanders »

renlo wrote: post #17
rtfeldman wrote: post #8

Earlier quoted context omitted.

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…

The creator of Elm works for your company though [1]. Seems like your experience is going to be a lot different from the average developer because you can probably walk 20 steps to the designer of Elm to ask a question. I haven't used Elm just raising the point. [1] https://twitter.com/czaplic

That's only been a recent development, rtfeldman has been using Elm for noredink for a long while before that.

Re: Elm from a Business Perspective

#23

Post by leshow »

rtfeldman wrote: post #8
the_duke wrote: post #2

Well. Summary: "I have no idea about the technical criticism or type classes, but we use Elm and it works for us. It's easy, you are productive quickly (quicker than with React/Angular), it prevents bugs, devs like it, and so it saves us money." It's nice to hear that a company is able to utilize Elm effectively. It would be nice to know how big their 5 Elm projects "in various stages and different scale" are to judg…

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…

Your response to all the criticisms about boilerplate is basically sticking your fingers in your ears and going "nananana".

Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple. That's okay, but don't pretend like you didn't make the trade off.

Re: Elm from a Business Perspective

#24

Post by the_gipsy »

wyager wrote: post #18
rtfeldman wrote: post #8

Earlier quoted context omitted.

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…

> Our Elm code is about as DRY as our JavaScript code Not to be flippant, but that's not saying much.

JavaScript code is or can be extremely DRY. I have noticed this especially on a redux (inspired by Elm's architecture) codebase. The pitfall is that JavaScript is very unsafe and hard to read.

I've worked with TypeScript too, and there I started to notice more repitition and boilerplate, although IMO It is very well worth the safety.

Re: Elm from a Business Perspective

#25

Post by the_duke »

rtfeldman wrote: post #8
the_duke wrote: post #2

Well. Summary: "I have no idea about the technical criticism or type classes, but we use Elm and it works for us. It's easy, you are productive quickly (quicker than with React/Angular), it prevents bugs, devs like it, and so it saves us money." It's nice to hear that a company is able to utilize Elm effectively. It would be nice to know how big their 5 Elm projects "in various stages and different scale" are to judg…

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…

My major question is: how do you write reusable code without type classes?

It's not really possible, as far as I can tell.

Re: Elm from a Business Perspective

#27

Post by the_duke »

the_gipsy wrote: post #24
wyager wrote: post #18

Earlier quoted context omitted.

> Our Elm code is about as DRY as our JavaScript code Not to be flippant, but that's not saying much.

JavaScript code is or can be extremely DRY. I have noticed this especially on a redux (inspired by Elm's architecture) codebase. The pitfall is that JavaScript is very unsafe and hard to read. I've worked with TypeScript too, and there I started to notice more repitition and boilerplate, although IMO It is very well worth the safety.

Javascript is dynamically typed though.

And Typescript has generics or circumventing the type system with :any to enable reusability.

Re: Elm from a Business Perspective

#28

Post by rtfeldman »

renlo wrote: post #17
rtfeldman wrote: post #8

Earlier quoted context omitted.

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…

The creator of Elm works for your company though [1]. Seems like your experience is going to be a lot different from the average developer because you can probably walk 20 steps to the designer of Elm to ask a question. I haven't used Elm just raising the point. [1] https://twitter.com/czaplic

We hired him because we'd already been using Elm for awhile and were so happy with it we wanted to contribute financially in addition to contributing with the libraries we open-source. :)

My boss wrote more about it here: http://tech.noredink.com/post/136615783598/welcome-evan

Re: Elm from a Business Perspective

#29

Post by rtfeldman »

sotojuan wrote: post #20
renlo wrote: post #17

Earlier quoted context omitted.

The creator of Elm works for your company though [1]. Seems like your experience is going to be a lot different from the average developer because you can probably walk 20 steps to the designer of Elm to ask a question. I haven't used Elm just raising the point. [1] https://twitter.com/czaplic

Not only does the creator of Elm work there but so do the people who know Elm more than anyone else in the world. Literally. While it's proof Elm can work it's not really a fair comparison for teams wanting to adopt it.

That's true for me, yes, but the author of this article works at a totally different company halfway around the world. :)

Re: Elm from a Business Perspective

#30

Post by rtfeldman »

leshow wrote: post #23
rtfeldman wrote: post #8

Earlier quoted context omitted.

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…

Your response to all the criticisms about boilerplate is basically sticking your fingers in your ears and going "nananana". Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple. That's okay, but don't pretend like you didn't make the trade off.

> Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple.

I just straight-up disagree with this. If Elm added Haskell-style typeclasses today, and we refactored our whole code base at work to use them, I bet it would save us less than 1% LoC.

This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the parentheses, and accusing JavaScript developers of sticking their fingers in their ears about the most obviously glaring weakness in the language.

What reasonable response can anyone make to that claim, except "I really don't think that's what the language should focus on improving?"

Post reply on HN