> But after writing some real programs with other people I realized the idea that every codebase has its own DSL and languages is actually stupid, doesn't scale and hard to maintain.
Code bases can use DSLs. DSLs should used judiciously. For example, if you need an LALR parser, you'd probably wouldn't code it all by hand, and you'd probably use a DSL.
Just like we use libraries judiciously in many languages. (Well, we should, but casually pulling in a hundred libraries is more a Python/JS/Rust convention, than a Lisp family one.)
> Came to hate Haskell for the very same reason. Every Haskell programmer think he's more clever than others so he decides on 30/40 language extensions and you have something that simply isn't Haskell.
Is this a problem when Haskell is used professionally by software engineering teams? Or are you speaking of code by academics/students, who don't have a lot of experience on professional software engineering teams? Or by hobbyists, who are (rightly) indulging, and writing code however they want (more power to them), not writing how they have to at their day job?
Yes but: u/epolanski is referring to the abuse of metaprogramming, such that every org, every project creates its own bespoke mutant creole which remains C++ (or Haskell, Forth, LISP) in name only.
Java's founders wisely omitted metaprogramming. But memories are short. And chaos always finds a way. So now Java has its own medley of obfuscation strategies. Annotations, aspects, inversion of control, dependency injection, logging frameworks, etc.
> Is this a problem when Haskell is used professionally by software engineering teams?
Yes, large segments of Haskell culture love complex language features and wild abstractions. Unfortunately that mindset seeps into everyday code because key libraries depend on the complex features.
The Simple Haskell movement (https://www.simplehaskell.org/) tried to develop a pragmatic culture but it fizzled. Back when Simple Haskell was active, it was fun watching advocates of complex, abstract Haskell argue against straightforward programming that normal developers can understand.
> it was fun watching advocates of complex, abstract Haskell argue against straightforward programming that normal developers can understand
I don't think that's what they were arguing against. I think they were arguing against equating straightforward programming with basic language features.
That's true, much of the technical discourse haggled over favorite language features. But that missed the much bigger point: If we use complex, abstract Haskell for practical apps, what are the consequences of alienating the vast majority of professional developers?
Unfortunately the answer is clear: Haskell's arcane reputation has solidified.
Well, it's a good question. I'm in favour of using simple[+], abstract Haskell for practical apps, welcoming the vast majority of professional developers!
[+] "simple" in that the solution to a problem is expressed in a simple way, not that it restricts itself to a particular subset of the language.
Code bases can use DSLs. DSLs should used judiciously. For example, if you need an LALR parser, you'd probably wouldn't code it all by hand, and you'd probably use a DSL.
Just like we use libraries judiciously in many languages. (Well, we should, but casually pulling in a hundred libraries is more a Python/JS/Rust convention, than a Lisp family one.)
> Came to hate Haskell for the very same reason. Every Haskell programmer think he's more clever than others so he decides on 30/40 language extensions and you have something that simply isn't Haskell.
Is this a problem when Haskell is used professionally by software engineering teams? Or are you speaking of code by academics/students, who don't have a lot of experience on professional software engineering teams? Or by hobbyists, who are (rightly) indulging, and writing code however they want (more power to them), not writing how they have to at their day job?