Making the move from Scala to Go
movio.co
Making the move from Scala to Go
1–10 of 378 posts
Re: Making the move from Scala to Go
#2This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging.
"Clever" should be regarded as a limited resource. Also, the shop should encourage a culture where "clever" with regards to making code easier to understand should be valued above all else.
Re: Making the move from Scala to Go
#3As it turned out, more flexibility led to devs writing code that others actually struggled to understand. This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging. "…
Re: Making the move from Scala to Go
#4As it turned out, more flexibility led to devs writing code that others actually struggled to understand. This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging. "…
For instance, python has never had the problems that ruby or perl had.
Re: Making the move from Scala to Go
#5The exodus away from Scala continues.
Re: Making the move from Scala to Go
#6Re: Making the move from Scala to Go
#7As it turned out, more flexibility led to devs writing code that others actually struggled to understand. This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging. "…
this is a developer problem not a language issue, i've seen "nifty" code in go just as well..
Re: Making the move from Scala to Go
#8First Yammer, then LinkedIn, then Twitter, and now movio.co. The exodus away from Scala continues.
Re: Making the move from Scala to Go
#9As it turned out, more flexibility led to devs writing code that others actually struggled to understand. This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging. "…
I don't agree that all languages are created equal in this regard. I think that there are cultural norms and expectations that come with certain languages that make them more or less susceptible to "cleverness." For instance, python has never had the problems that ruby or perl had.
I never said that. I'm only asserting that no language is completely immune, because hubristic cleverness is intermediate to stupidity and genius.
I think that there are cultural norms and expectations that come with certain languages that make them more or less susceptible to "cleverness."
Cultural norms can indeed help or hurt.
Re: Making the move from Scala to Go
#10Case in point, when (2)Paul Phillips went after Scala (mentioned in the article), Odersky took some of that criticism to heart for the next iteration/rewrite of the Scala compiler. In an industry where everyone doubles down, that's extremely refreshing.
Scala's cognitive footprint can lead to misbehaving programmers, but clean Scala has its own elegance if the cuteness is avoided. The slowness I'll give you though :(.
1) I'm old enough to remember this language CoffeeScript that "really really sucked". And then all of a sudden, people were using ES6/TS with parameter destructuring, classes, lambdas, but yeah, CS was the bad guy.
2) Despite his bellyaching, Paul Phillips never really left Scala the language (check his commit log), just the compiler team & lightbend.