4 ms·

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 r

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.

sotojuan 10y ago
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).
- dkarapetyan 10y ago
  Yes, that is my point. I don't think Elm is "too academic". I think it strives for pragmatism in real world engineering scenarios and that is why it gets flak from a certain segment of the programming community. Similar to how golang does.
- busterarm 10y ago
  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.
vvanders 10y ago
Yup, and that's been one of Evan's core principals in Elm, pull out the good stuff from academia but in a way that's accessible to the lay-developer.
projektfu 10y ago
I agree, sometimes you just compound the cleverness too much. There's lots of software that could be written in J in about 150 characters that might take much more in other languages. But I can come back to a line of J and wonder, "what was I doing there?" for a long time. Similarly, I have to stay current in Haskell for it to continue making sense. If I put it down for a few months, I come back and have to re-learn a lot of concepts each time, especially to understand other people's libraries as they adopt the next cool thing.
rifung 10y ago
> 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.
- dkarapetyan 10y ago
  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.
chrisdone 10y ago
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.
- dkarapetyan 10y ago
  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.

sotojuan 10y ago

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

dkarapetyan 10y ago
Yes, that is my point. I don't think Elm is "too academic". I think it strives for pragmatism in real world engineering scenarios and that is why it gets flak from a certain segment of the programming community. Similar to how golang does.
busterarm 10y ago
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.

vvanders 10y ago

Yup, and that's been one of Evan's core principals in Elm, pull out the good stuff from academia but in a way that's accessible to the lay-developer.

projektfu 10y ago

I agree, sometimes you just compound the cleverness too much. There's lots of software that could be written in J in about 150 characters that might take much more in other languages. But I can come back to a line of J and wonder, "what was I doing there?" for a long time. Similarly, I have to stay current in Haskell for it to continue making sense. If I put it down for a few months, I come back and have to re-learn a lot of concepts each time, especially to understand other people's libraries as they adopt the next cool thing.

rifung 10y ago

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

dkarapetyan 10y ago
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.

chrisdone 10y ago

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.

dkarapetyan 10y ago
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.