Re:Green vs. Brown Programming Languages
by amscanne on Thursday April 22, 2021 @09:48PM
(#26910207)
Ultimately you’re expressing an anti-simplicity sentiment, which is well aligned with the parent post. Clever abstractions may appear to reduce the “burden”, but they are often fashionable and add cognitive overhead. Go does indeed often force you to do things the “dumb” way (see your own examples) but the thesis is that this is easier to understand and maintain over time.
Re:Green vs. Brown Programming Languages
by wtetzner on Saturday April 24, 2021 @12:52PM
(#26926325)
> Ultimately you’re expressing an anti-simplicity sentiment
I disagree. First, making a language simple doesn’t make programs simpler, and often does the opposite.
I’m also not sure I buy the idea that Go is actually simple. It lacks a lot of features, but that’s not the same as being simple. I mean, it supports runtime reflection, which seems more complicated than features like traits or generics. And code using reflection is never simple.
Re:Green vs. Brown Programming Languages
by BiteCode_dev on Friday April 23, 2021 @02:49AM
(#26911738)
I'm sure somebody said something like that when all those kids started to the clever abstractions that were functions instead of doing things manually in assembly.
Simplicity!
Re:Green vs. Brown Programming Languages
by throwaway894345 on Friday April 23, 2021 @09:32AM
(#26914570)
This is just vapid snark. Of course some abstraction is helpful, but there's also a point at which abstraction impedes understanding. Ergo, we're debating where the "sweet spot" is. Note also that we can say "Go is the sweet spot for most applications" while also acknowledging that it makes certain kinds of programming difficult (e.g., writing a compiler). It's okay to recognize tradeoffs; there's no need to oversimplify or otherwise engage dogmatically.
Re:Green vs. Brown Programming Languages
by carlhjerpe on Friday April 23, 2021 @07:06AM
(#26913422)
Some developers don't want to use the ternary operator because it's "too complex".
I believe there's a middle ground to be found where further abstractions add complexity rather than reduce it. Where that middle ground is, I don't know.
Re:Green vs. Brown Programming Languages
by wtetzner on Saturday April 24, 2021 @12:54PM
(#26926344)
That’s a strange definition of complexity. I can see people avoiding the ternary operator because the syntax is hard to read, but it’s no more complex than `if`.
Exactly, people advocate that there are those shipping stuff in Go, naturally there is the case.
Anyone that had to work with Assembly in production was happy to have any kind of high level language to start with.
Side note, Go gives you less tools - but not often less choice. Eg if you need to iterate and map, you still need to iterate and map. Go didn't change your application needs simply because it inhibited your ability to execute. Instead, you do what you need despite Go. Which often amounts to repeated functions, loops of loops, functions in loops to use defers, etcetc - you reinvent wheels. Go didn't reduce the application complexity, it just gave you less tools to solve it.
While some argue less tools is easier. I argue less tools often results in poor, messy abstractions. Those are traits that fight maintenance more than ease it, in my mind.
By the end of my Go tour, i was tired and wanted off the simplicity ride. The language was a burden, to me.