32 ms·

> 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

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

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.