4 ms·

> nothing else to do than to write concrete code to solve the problem And by that you mean "invent ad-hoc code generators instead of using built-in language fe

> nothing else to do than to write concrete code to solve the problem And by that you mean "invent ad-hoc code generators instead of using built-in language features from the 21st century", right?

mjaniczek 3y ago
Not to diss on Haskell, but to illustrate the difference: There's an entire HaskellX 2022 talk about "language extensions we use, extensions we are cautious about, extensions we never use". There are many ways to solve problems in Haskell; and mostly only one or two ways to do things in Elm. The most choice I can think of is in context of parent-child communication (Config pattern, OutMsg, flat Msg type). Most everything else has a single obvious solution. Yes, sometimes the simplicity of the language leaves you wanting a bit more power (typeclasses, macros) but the code quality seems (to me) better with the constrained language than with the unconstrained one.
- kaba0 3y ago
  Well, one is a research language with the explicit goal of trying out new language features, so the comparison falls flat imo. Also, doing only GUIs is quite a bit more restrictive than general purpose programming and not every fancy feature may make sense there.
Cthulhu_ 3y ago
That's an unfortunate problem that Go has, admittedly; it's far from a perfect language. I'm just glad they resist adding language features for isolated use cases. One example of code generators is enums, I'd love for Go to add that as a feature, I frequently use them in other languages. Go's equivalent is a list of consts with a shared prefix, e.g. StatusOK, StatusBadRequest etc for HTTP error codes [0], then functions to do anything with them (like getting a status text for the aforementioned HTTP status codes; see [0] and scroll down a bit). I mean it's not difficult code; nobody has to learn any new syntax or methodologies to understand enums if they already know consts / variables, functions and switch/case statements. It's just inelegant and it feels unsafe - you need a linter [1] to check for exhaustiveness of the aforementioned switch/case, on top of a ton of other linters [2] that IMO should be language features or compiler checks. My personal gripe is struct tags that are just strings that no tooling or compile-time checks will check, they're left up to a library (or the standard library) to interpret at runtime. In other languages like e.g. Java they introduced annotations to add metadata to properties. [0] https://go.dev/src/net/http/status.go https://go.dev/src/net/http/status.go [1] https://pkg.go.dev/github.com/nishanths/exhaustive https://pkg.go.dev/github.com/nishanths/exhaustive [2] https://github.com/golangci/awesome-go-linters https://github.com/golangci/awesome-go-linters

> nothing else to do than to write concrete code to solve the problem And by that you mean "invent ad-hoc code generators instead of using built-in language features from the 21st century", right?

mjaniczek 3y ago

Not to diss on Haskell, but to illustrate the difference: There's an entire HaskellX 2022 talk about "language extensions we use, extensions we are cautious about, extensions we never use". There are many ways to solve problems in Haskell; and mostly only one or two ways to do things in Elm. The most choice I can think of is in context of parent-child communication (Config pattern, OutMsg, flat Msg type). Most everything else has a single obvious solution. Yes, sometimes the simplicity of the language leaves you wanting a bit more power (typeclasses, macros) but the code quality seems (to me) better with the constrained language than with the unconstrained one.

kaba0 3y ago
Well, one is a research language with the explicit goal of trying out new language features, so the comparison falls flat imo. Also, doing only GUIs is quite a bit more restrictive than general purpose programming and not every fancy feature may make sense there.

Cthulhu_ 3y ago

That's an unfortunate problem that Go has, admittedly; it's far from a perfect language. I'm just glad they resist adding language features for isolated use cases. One example of code generators is enums, I'd love for Go to add that as a feature, I frequently use them in other languages. Go's equivalent is a list of consts with a shared prefix, e.g. StatusOK, StatusBadRequest etc for HTTP error codes [0], then functions to do anything with them (like getting a status text for the aforementioned HTTP status codes; see [0] and scroll down a bit). I mean it's not difficult code; nobody has to learn any new syntax or methodologies to understand enums if they already know consts / variables, functions and switch/case statements. It's just inelegant and it feels unsafe - you need a linter [1] to check for exhaustiveness of the aforementioned switch/case, on top of a ton of other linters [2] that IMO should be language features or compiler checks. My personal gripe is struct tags that are just strings that no tooling or compile-time checks will check, they're left up to a library (or the standard library) to interpret at runtime. In other languages like e.g. Java they introduced annotations to add metadata to properties. [0] https://go.dev/src/net/http/status.go https://go.dev/src/net/http/status.go [1] https://pkg.go.dev/github.com/nishanths/exhaustive https://pkg.go.dev/github.com/nishanths/exhaustive [2] https://github.com/golangci/awesome-go-linters https://github.com/golangci/awesome-go-linters