Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making the move from Scala to Go

movio.co

Post reply on HN
Print view View original

31–40 of 378 posts

Re: Making the move from Scala to Go

#31

Post by [deleted] »

hliyan wrote: post #20
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. "…

As the saying goes: it's easier to write code than understand it. Therefore if you write code as cleverly as you can, then by definition you're not smart enough to understand it...

[deleted]

Re: Making the move from Scala to Go

#32

Post by JulianK »

hliyan wrote: post #20
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. "…

As the saying goes: it's easier to write code than understand it. Therefore if you write code as cleverly as you can, then by definition you're not smart enough to understand it...

For those that like trivia, the original quote I believe is by Kernighan and it's about debugging code rather than writing it, which I feel makes more sense:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

https://en.wikiquote.org/wiki/Brian_Kernighan

Re: Making the move from Scala to Go

#33

Post by nradov »

hliyan wrote: post #20
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. "…

As the saying goes: it's easier to write code than understand it. Therefore if you write code as cleverly as you can, then by definition you're not smart enough to understand it...

Yes but occasionally there's no other option. I once had to code a parser for a data format with an odd non-BNF grammar with a bunch of special cases. In order to meet the functional requirement for user-friendly error reporting when parsing invalid inputs I was forced to write really clever (in a bad way) code. Fortunately we haven't found any serious defects in it because I don't think I understand it well enough to debug it.

Re: Making the move from Scala to Go

#34

Post by kbenson »

nrjdhsbsid wrote: post #15
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. "…

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 using the single statement version of if/else if your language supports it, and that's probably justification in itself given how many problems that's caused in the past.

Specifically, I think:

    usefulMetric = wantComplexCalc ? complexCalc(foo)
                                   : simpleCalc(foo);
is preferable to:

    if ( wantComplexCalc ) {
        usefulMetric = complexCalc(foo)
    } else {
        usefulMetric = simpleCalc(foo)
    }
even if only because it doesn't obscure intent with what is essentially boilerplate.

Re: Making the move from Scala to Go

#35

Post by lazzlazzlazz »

runT1ME wrote: post #26

It took some of us six months including some after hours MOOCs, to be able to get relatively comfortable with Scala Huh. Yeah, sounds like Go is a really good choice for you guys! For some reason our team is able to onboard new engineers and have them be productive in less than a month...

You're either being a little unfair, or have a very low standard for "productive".

Re: Making the move from Scala to Go

#37

Post by ludicast »

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…

Agreed, plus obviously your "if" statement doesn't do the assignment to usefulMetric. One more way the ternary wins (along with functional languages that use "if"s as expressions).

Re: Making the move from Scala to Go

#38

Post by namelezz »

andrewvijay wrote: post #16

Really well written. We have a similar story where we re wrote parts of our Java code in go and the build time has reduced from 15m to 3.6m! Coffee break to reading a small medium article.

> the build time has reduced from 15m to 3.6m.

Is 3.6m the build time of the remained Java code, the rewritten Go code, or both remained Java and rewritten Go code together?

Re: Making the move from Scala to Go

#40

Post by imh »

runT1ME wrote: post #27
imh wrote: post #23

Looking through the really abstract scala code they linked brings up a problem that really frustrates me in haskell. Why doesn't anybody document their really abstract code? You know it's going to be confusing, so why not help out? If I have a type like def foreignKey[P, PU, TT It's not sufficient to document the function's arguments. You also need to document the type variables! Likewise in haskell with code like f…

What do you mean "document the types". They're type parameters... can you suggest better names for the parameters in StrongSyntax?

As a small example, let's say I have a typed "agg" function with associated typeclass:

    class typedAgg t where 
      agg :: t f r a b -> (r a -> b) -> f (r a) -> f b
      ...
To lots of people, that's going to be really confusing. It might be easier if I document that f is supposed to be the type of the table, r is the type of the row, and a is the type of elements in the rows, if that's the intended usage.
Post reply on HN