[fc417fc802]

The reality is that careless programmers will do bad things with any tool they happen to pick up. Using that as an excuse to reduce the power of a tool is poor form.

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.

[jorkadeen]

Not sure I agree. A simple example: If your language has null as a subtype of every type then you will have null ptr exceptions everywhere. If your language does not have a null value then you won't. The situation is not as clear cut as you suggest.

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.

[fc417fc802]

I feel like that example doesn't fit except in the specific case that the language designer restricts the usage of null in a way that reduces the overall expressiveness and power of the language. Whereas (but one example) the operators provided by Kotlin don't do that.

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.

[1] https://github.com/kstenerud/go

[2] https://github.com/tpope/heroku-fucking-console

[gavinray]

I fully agree with you here.

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.

[pshirshov]

> But Scala 3 gives you "too much rope to hang yourself with".

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.

[gavinray]

I don't have the mental energy to review every line of code and argue with co-workers that they're "using it the wrong way" unfortunately.

Maybe in my younger years, but not after the first decade...

This is why Rob Pike designed Go the way he did, I think.

[pshirshov]

> I don't have the mental energy to review every line of code and argue

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.

[lucyjojo]

that's a cool story for 1 person projects that use no libraries.

also, no working on other people projects.

which is fine. i do clojure, i stay in my niche!

[pshirshov]

Not true, we successfully maintain more than 1 MLoC of Scala code. But our framework is completely homegrown.

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