Making the move from Scala to Go

Post by pjmlp » Wed, Jan 25, 2017, 5:30 AM UTC

Daishiman wrote: post #90

jghn wrote: post #83

Earlier quoted context omitted.

Sure but I'm talking about things like "break things down into lots of small functions to make things more readable!" vs "keeping code together makes it easier to read!" or "make things verbose so it is easier to read!" vs "conciseness makes code easier to read!" On a lot of those I know what makes code easier for me to read. It's not the same as some of my coworkers. Based on some of your phrasing I suspect we'd agr…

In my experience, very experienced programmers end up converging towards very similar idioms: terse expressions for common patterns, clarity when the domain is complex through verboseness if necessary, and just keeping things as simple as possible unless there's evidence that complexity will reduce technical debt in the future. I don't really see highly competent devs doing the whole J2EE architecture astronautics an…

Post by edblarney » Wed, Jan 25, 2017, 5:58 AM UTC

jghn wrote: post #84

edblarney wrote: post #71

Earlier quoted context omitted.

I'm not sure if this is true. Scala provides a whole new level of ability for people to write code that can be meaningless to others. It really is quite different.

And that sort of scala code is extremely meaningful to other folks, which captures my point. I see scala code all the time that would give me an instant headache but there are people who would find that more readable. To each their own, the is to work with people who are at least somewhat aligned to your sensibilities.

Post by lacampbell » Wed, Jan 25, 2017, 6:06 AM UTC

stcredzero wrote: post #2

As 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. "…

Post by lacampbell » Wed, Jan 25, 2017, 6:14 AM UTC

unoti wrote: post #55

didibus wrote: post #43

Earlier quoted context omitted.

But the best thing you can do to improve the team's chances of accomplishing business objectives is to choose its members more carefully.

I agree. But personally I'd be concerned about a team lead who thinks the make or break thing is whether a candidate engineer loves fondling their monads all day.

Post by pacala » Wed, Jan 25, 2017, 6:18 AM UTC

kbenson wrote: post #34

nrjdhsbsid wrote: post #15

Earlier quoted context omitted.

I always work with a few developers that complain about my long variable names and aversion to certain shortcuts like ternary operators. They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse. Some of their code is so "clever" that I've refactored the line with 7…

> aversion to certain shortcuts like ternary operators. > They don't understand that unclear code is probably the number one cause of technical debt. At the same time, verbosity can have an obfuscation quality all of its own. For simple assignment , I find a ternary operator very clear and concise, and much preferable to a 5-9 line (depending on style) if/else for a simple assignment. It also might keep you from usin…

    val usefulMetric = if (wantComplexCalc) {
      complexCalc(foo)
    } else {
      simpleCalc(foo)
    }