3 ms·

> I think what we really need is a new language that picks all the good parts from Haskell, but has a very small syntactical core. Something like Go, but purely

> I think what we really need is a new language that picks all the good parts from Haskell, but has a very small syntactical core. Something like Go, but purely functional. I'll wait patiently until people start asking for more language features, like the ten thousand last times... every widely used language ends up converging towards at least C++-levels of expressiveness (Java, TypeScript, Go, Python with static types, Caml, etc... you name it) because it turns out that those features are actually needed.

marcus_holmes 5y ago
I agree that they all converge on a standard set of features, but I disagree that the features are needed. You could get everything done with Javascript's prototype system that you wanted done with classes. You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics. The problem is that people come to this language from other languages, and have expectations that this language is basically the same as the other language they already know (and if not, why not?). There's a constant pressure on languages to conform to a single set of "known good" conventions [0] The unusual languages are needed because we need that diversity, but they are never going to be "mainstream" until/unless a Java dev can learn them inside 3 months without challenging any of their assumptions about programming. [0] the classic is Erlang vs Elixir - Erlang is "weird", Elixir is "awesome"
- jcelerier 5y ago
  > You could get everything done with Javascript's prototype system that you wanted done with classes. > You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics. by that logic why don't you just use lisp for everything ? it's been there since 1958 and you can also get everything done with it, including reimplementing yourself a Go- or Js-like DSL if you allow yourself a Racket. The truth is, your "get everything done" actually does not include everything, because "writing less boilerplate" is not only a feature, but one of the most important ones. Boilerplate is unambiguously bad and a place where terrible bugs hide - any time you can replace it by something with much less chances of bugs, such as a language feature, you should (and I'd argue it's professional malpractice to chose not to when you have the option).
  - pjmlp 5y ago
    On that note, I remember when Borland released BIDS 1.0 and was doing with the preprocessor what Go, reinvented almost 20 years later. Or using Eclipse EMF to read UML interchange files generated from Rational Rose and generate the boilerplate for Java applications, before generics and compiler plugins were a standard Java feature. When languages aren't feature rich, someone will eventually start writing that boilerplate, hence why //go:generate exists, despite the fact that Go people telling writing boilerplate is not a problem.
  - everforward 5y ago
    Boilerplate isn't necessarily evil. Imo, repetitive boilerplate is where the problem comes in. I.e. it's not a bad thing that every HTTP app has an almost-the-same way to start the HTTP server. It is a bad thing when you're writing almost the same code but with different types 37 times. There's a seemingly inevitable tradeoff between complexity and bugs. Low complexity tends to lead to repetitive, simple, avoidable bugs. High complexity leads to unique, hard to reason about bugs. I find the preference for simple vs complex code has to do with what kind of bugs programmers want to troubleshoot. Some prefer simple and repetitive bugs, others prefer fewer, more difficult bugs.
- ParetoOptimal 5y ago
  > You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics. As a heads up to anyone reading, you may not consider it only 'a bit of boilerplate'.

marcus_holmes 5y ago

I agree that they all converge on a standard set of features, but I disagree that the features are needed. You could get everything done with Javascript's prototype system that you wanted done with classes. You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics. The problem is that people come to this language from other languages, and have expectations that this language is basically the same as the other language they already know (and if not, why not?). There's a constant pressure on languages to conform to a single set of "known good" conventions [0] The unusual languages are needed because we need that diversity, but they are never going to be "mainstream" until/unless a Java dev can learn them inside 3 months without challenging any of their assumptions about programming. [0] the classic is Erlang vs Elixir - Erlang is "weird", Elixir is "awesome"

jcelerier 5y ago
> You could get everything done with Javascript's prototype system that you wanted done with classes. > You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics. by that logic why don't you just use lisp for everything ? it's been there since 1958 and you can also get everything done with it, including reimplementing yourself a Go- or Js-like DSL if you allow yourself a Racket. The truth is, your "get everything done" actually does not include everything, because "writing less boilerplate" is not only a feature, but one of the most important ones. Boilerplate is unambiguously bad and a place where terrible bugs hide - any time you can replace it by something with much less chances of bugs, such as a language feature, you should (and I'd argue it's professional malpractice to chose not to when you have the option).
- pjmlp 5y ago
  On that note, I remember when Borland released BIDS 1.0 and was doing with the preprocessor what Go, reinvented almost 20 years later. Or using Eclipse EMF to read UML interchange files generated from Rational Rose and generate the boilerplate for Java applications, before generics and compiler plugins were a standard Java feature. When languages aren't feature rich, someone will eventually start writing that boilerplate, hence why //go:generate exists, despite the fact that Go people telling writing boilerplate is not a problem.
- everforward 5y ago
  Boilerplate isn't necessarily evil. Imo, repetitive boilerplate is where the problem comes in. I.e. it's not a bad thing that every HTTP app has an almost-the-same way to start the HTTP server. It is a bad thing when you're writing almost the same code but with different types 37 times. There's a seemingly inevitable tradeoff between complexity and bugs. Low complexity tends to lead to repetitive, simple, avoidable bugs. High complexity leads to unique, hard to reason about bugs. I find the preference for simple vs complex code has to do with what kind of bugs programmers want to troubleshoot. Some prefer simple and repetitive bugs, others prefer fewer, more difficult bugs.
ParetoOptimal 5y ago
> You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics. As a heads up to anyone reading, you may not consider it only 'a bit of boilerplate'.