Another way of putting it is to point out that removing goto from a language isn't going to reduce the occurrence of spaghetti code. The average skill and care of the developers who happen to be using that language is what does that.
Another way of putting it is to point out that removing goto from a language isn't going to reduce the occurrence of spaghetti code. The average skill and care of the developers who happen to be using that language is what does that.
Yes, you can write spaghetti code in any language. But a good language design can help (a) reduce errors and (b) nudge the developer towards writing better code.
Obviously how exactly you structure a particular end result is going to involve lots of fuzzy tradeoffs. My point wasn't about such nuance but rather the sort of reasoning that leads the the dismissal of an entire feature (in this case proper macros) on the basis of saving developers from themselves.
There should be (at least IMO) a clear delineation between a language design that makes it possible to do things in a sensible manner versus the realm of style guides, linters, and pre-commit hooks that enforce restrictions intended to maintain sanity on large projects. I shouldn't feel compelled due to deficiencies in the design of the language to reach for constructs like goto but those constructs should still be there if I have a need for them. People shouldn't feel compelled to waste time patching their tools to work around the opinions of the designers being forced on them. [1][2]
That said, it would be nice if compilers themselves universally provided native linting facilities, possibly even enabled by default.
I primarily write JVM applications these days, and my go-to is Kotlin.
Not because I think it's the "best" JVM language -- quite the opposite, I think Scala 3 is potentially the best-designed pragmatically useable language at the moment.
But Scala 3 gives you "too much rope to hang yourself with".
If you're the only person touching a codebase that's fine, but if you have to work with others I don't want to introduce the possibility of a bunch of implicit type classes, macros, and insane type definitions.
I'll take the reduced expressiveness of Kotlin for it's working-class philosophy and simpler mental model.
No, you use it wrong way. It gives you capability to write cleanest code possible. As with any expressive language you have to select a subset of features and a specific style and maintain it.
Unmaintainable code can be written in any language, expressive ones provide you with tools to keep code maintainable.
HKTs and macros make possible things which are completely impossible in most other languages without a preprocessor/compiler plugin.
Maybe in my younger years, but not after the first decade...
This is why Rob Pike designed Go the way he did, I think.
You don't have to. Just your process is broken.
> first decade
I've been using Scala since 2008. I'm not a smart guy, so made some smart tools which do the enforcement job for me.
also, no working on other people projects.
which is fine. i do clojure, i stay in my niche!
> no libraries.
We made the cats->zio adapters and BIO, we do use libraries, in a sense more extensively than other teams out there do.