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

31–40 of 79 posts

Re: Elm from a Business Perspective

#31

Post by chrisdone »

dkarapetyan wrote: post #3

The academics always miss this part. They assume the most elegant and concise form of expression for an idea or a concept is equivalent to pragmatism. When in reality pragmatism in software engineering is mostly about making things obvious enough at a cheap enough price point. This is why golang is so popular even though all the academics on r/programming hate it.

There are many points to respond to here.

1. Evan (the Elm author) has pledged to support type-classes, it's on the issue tracker, and because he believes that they are useful.

2. "The academics" is a mischaracterization. I use Haskell and PureScript professionally and share the same problem of the "Elm is Wrong" author, which is that it's impossible to do any generic programming.

3. Generic programming is important for something as simple as inserting my own data types as keys into a dictionary. So is being able to write "show x" and just have the thing showed if it has the instance of a showable class. Or to parse a nested data structure of various types from JSON.

4. Being able to use my own types as keys in a dictionary is pretty pragmatic, I think. A typical pattern in ML-style languages is to wrap types like Int in a UserId type that just wraps it and protects it from being mistakenly used with other Ints. Now try to make a dictionary of users via the UserId type. Nope.

5. "They" in this case aren't concerned with elegance or concision for the sake of it, but because the features under discussion help them do their job better, avoid mistakes, reduce maintenance cost, and that's good for business.

6. Go has non-academic, purely pragmatic problems that are orthogonal to its popularity, as does PHP or nodejs.

None of the things under discussion are difficult to implement, novel or exotic. Given that other languages like PureScript exist under the same domain and from the same family of languages, we have the luxury of holding other languages up to the same standard. In this particular point, Elm is a -1.

Re: Elm from a Business Perspective

#32

Post by dkarapetyan »

rifung wrote: post #13
dkarapetyan wrote: post #3

The academics always miss this part. They assume the most elegant and concise form of expression for an idea or a concept is equivalent to pragmatism. When in reality pragmatism in software engineering is mostly about making things obvious enough at a cheap enough price point. This is why golang is so popular even though all the academics on r/programming hate it.

> They assume the most elegant and concise form of expression for an idea or a concept is equivalent to pragmatism. Alternatively, perhaps many academics don't care about pragmatism and appreciate elegance and conciseness for their beauty. Admittedly I might be projecting, but part of the reason I have considered getting a PhD is to stop having to concern myself with the interests of the industry and money.

That's not what I've observed. The discussions actually turn out to be quite inflammatory when these matters are involved. Even folks that claim to have PhDs in language design consistently confuse these concepts. That's the only way I can explain all the condescending remarks when it comes to things like type systems, monads, curry-howard correspondence, etc. In fact the above article is a response to one such inflammatory and condescending blog post by a programmer who clearly values theoretical beauty and specific patterns that typeclasses enable above software engineering pragmatism. Although I can see how typeclasses help in cutting down boilerplate in this case his tone does not help make that point.

I'm no stranger to abstract and theoretical beauty. My undergrad and grad training is in pure math but I also understand that theorems and proofs don't necessarily lead to good software engineering in the large. So valuing the abstractions is great and all but using it as the ultimate arbiter of good language design is not.

Re: Elm from a Business Perspective

#33

Post by dkarapetyan »

chrisdone wrote: post #31
dkarapetyan wrote: post #3

The academics always miss this part. They assume the most elegant and concise form of expression for an idea or a concept is equivalent to pragmatism. When in reality pragmatism in software engineering is mostly about making things obvious enough at a cheap enough price point. This is why golang is so popular even though all the academics on r/programming hate it.

There are many points to respond to here. 1. Evan (the Elm author) has pledged to support type-classes, it's on the issue tracker, and because he believes that they are useful. 2. "The academics" is a mischaracterization. I use Haskell and PureScript professionally and share the same problem of the "Elm is Wrong" author, which is that it's impossible to do any generic programming. 3. Generic programming is important…

And yet plenty of programmers somehow manage to ship perfectly good solutions to everyday problems without "generic programming" capabilities as you define them. The author of "Elm is Wrong" might have good intentions but the tone of that post is so condescending and inflammatory that all the points being made are lost. The title alone already starts everything on the wrong foot.

Instead of sitting on such a high horse the more constructive approach is to outline the shortcomings, implement the solution, and contribute it upstream. That's not what I see though. Most of these "critical" posts end up just being that. Comparing a language that programmers use every day to ship working solutions to another one that has considerably smaller mindshare and community and then calling the more popular solution a failure because it doesn't have the feature from the more "pure and elegant" language. There is clearly a disconnect in tone and intent across all such posts.

I don't have any horses in these races. Programming languages are just tools and the religious zealotry around them does not appeal to me.

Re: Elm from a Business Perspective

#34

Post by iopq »

rtfeldman wrote: post #30
leshow wrote: post #23

Earlier quoted context omitted.

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

Yes, that's true, but I bet you some of the functionality that you wrote can be factored out into a more generic library that applies to everyone's use case. So it could be that half of your code is "library" code that could be open sourced - if it could be written generically with typeclasses.

For example, Rust has typeclasses (called traits) and Rust has a lot of libraries that do the right thing for you.

    fn accumulate(tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> Option
            where T: From {

        tuples.iter()
            .filter(apply(second, i))
            .map(first)
            .cloned()
            .map(::into)
            .fold1(T::op)

        //op just concatenates, but Cow does not satisfy Add
    }
Here, the functions first and second are taken from tool.rs, fold1 is from itertools, the type Monoid and the function op is taken from monoid.

I did have to write the delayed apply function myself, though. It's definition is:

    fn apply(mut f: F, a: A) 
    -> impl FnMut(&B) -> C // must still be `for impl FnMut(&'r B) -> C`, because that’s what filter requires
             where F: FnMut(B) -> G, // must not be `for FnMut(&'r B) -> G`, because regular functions do not implement it
                   G: FnMut(A) -> C,
                   B: Copy, // for dereferencing
                   A: Clone {

        move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements
    }
I think that could also be in a library somewhere

Re: Elm from a Business Perspective

#35

Post by kod »

the_duke wrote: post #25
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…

My major question is: how do you write reusable code without type classes? It's not really possible, as far as I can tell.

Are you trying to say that in the 30 years of time between the discovery of Lisp and the discovery of typeclasses, no one wrote reusable code?

Re: Elm from a Business Perspective

#36

Post by busterarm »

sotojuan wrote: post #6
dkarapetyan wrote: post #3

The academics always miss this part. They assume the most elegant and concise form of expression for an idea or a concept is equivalent to pragmatism. When in reality pragmatism in software engineering is mostly about making things obvious enough at a cheap enough price point. This is why golang is so popular even though all the academics on r/programming hate it.

This is interesting because Elm has been removing features that Evan considers "too hard" and confusing for the average developer. I'd argue it's not "academic" any more (though it might be interesting for an academic who wants to do UI).

Is it truly because they are "too hard" or is it because their current implementation in the language falls short? I was pretty sure in at least one of the cases Evan mentioned the possibility of revisiting it later.

Other languages don't make these choices and end up with things like Python's async/await.

Re: Elm from a Business Perspective

#37

Post by bbcbasic »

sotojuan wrote: post #7

I'm guessing pragmatism and practicality is why they went with Elm over PureScript? If their backend is in Haskell then it seems like they have devs who know it well enough to use PS.

From my limited experience, I would say PureScript sounds more practical. You can choose your own UI engine, and has additional language features that are useful like typeclasses. It also compiles without needing a runtime baked in to the output.

When you hit a wall you can probably work around it in Purescript whereas I feel you are too sandboxed in with Elm and you'd have to start patching your Elm source to get around it.

Re: Elm from a Business Perspective

#38

Post by kornish »

rtfeldman wrote: post #30
leshow wrote: post #23

Earlier quoted context omitted.

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

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

That's a straw man which isn't directly analogous to the question of typeclasses. The reason is because parens are a syntax concern, which is understood at this point to be largely a matter of personal preference. Typeclasses are a language semantics matter. They could add new levels of reuse for identical operations over different types, and they've done exactly that for other languages.

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

Well, the burden of proof should be on the proposer: that the feature is useful. A good next step would be for someone who's interested in persuading you of the importance of typeclasses to pick concrete examples from NoRedInk's open source Elm and show you how they could be improved, disproving your hypothesis that typeclasses wouldn't really help.

(edit: removed redundancy around "burden of proof")

Re: Elm from a Business Perspective

#39

Post by bcheung »

petetnt wrote: post #10

> But than again, Elm is not too easy. This means that almost every developer I see that is already involved in Elm is a seasoned developer. Getting experienced developers on board means that they are immediately productive, which means we gain more per hour. Not really seeing this as a strong point. It feels like the same mindset that drove me away from Scala (and many others [0]!). Sure, it might be good for the co…

I looked around at Elm a little bit recently. I use React/Redux daily at work and have been learning Haskell on the side. When I took another pass at Elm it was extremely easy to pick up. I was able to skim through the docs super fast and start writing real code in about 15 minutes.

I noticed myself typing Haskell code a bunch of the time and wondering why it didn't work though. For me, the hardest part in Elm, and Haskell as well, is figuring out how to structure data that is composition in nature or that involve Union types that are records. I can never quite seem to get the dereferencing right.

Re: Elm from a Business Perspective

#40

Post by kritzcreek »

dkarapetyan wrote: post #33
chrisdone wrote: post #31

Earlier quoted context omitted.

There are many points to respond to here. 1. Evan (the Elm author) has pledged to support type-classes, it's on the issue tracker, and because he believes that they are useful. 2. "The academics" is a mischaracterization. I use Haskell and PureScript professionally and share the same problem of the "Elm is Wrong" author, which is that it's impossible to do any generic programming. 3. Generic programming is important…

And yet plenty of programmers somehow manage to ship perfectly good solutions to everyday problems without "generic programming" capabilities as you define them. The author of "Elm is Wrong" might have good intentions but the tone of that post is so condescending and inflammatory that all the points being made are lost. The title alone already starts everything on the wrong foot. Instead of sitting on such a high hor…

I don't think you get to call people condescending when you just generalised "the academics" to be ignorant of the "real world".

> Instead of sitting on such a high horse the more constructive approach is to outline the shortcomings, implement the solution, and contribute it upstream. That's not what I see though.

That's what the "Elm is wrong" post did though. It outlined the shortcomings and showed how it was impossible to implement the solution because of somewhat arbitrary limitations to the extensible record system. The tone was way off and made it an unpleasant read, but valid points were made.

Post reply on HN