Live data from Hacker News

Making the move from Scala to Go

movio.co

261–270 of 378 posts

Re: Making the move from Scala to Go

#261
post #227

Earlier quoted context omitted.

"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras." -- Alan Kay, The Computer Revolution hasn't happend yet — 1997 OOPSLA Keynote

Could you explain how exactly this quote is applicable to Dijkstra's quote? Which part do you think is arrogant? Alan seems to make an overly broad statement, which is funny, but also weak.

Correct me if I'm wrong, but was Dijkstra not known for never actually using a computer. He wrote code with pencil and paper. There's a gulf between academic code and the needs of the day to day programmer. That said, I agree with his statement about one liners. Code should be parsimonious. It should never be a puzzle to understand what the code is doing.

Re: Making the move from Scala to Go

#262

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

It got really bad the past 10 years or so with the "look at what I can do, ma!" blog posts where someone spends 4 pages violating the language in order to get clicks. It's especially endemic in Ruby-land, I find.

Re: Making the move from Scala to Go

#263

Earlier quoted context omitted.

I think it is interesting that you left out the very next few sentences, which provide very relevant context: "I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque." While I agree with the general sentiment, it's very important to…

I agree with todd8, but would like to add that the next paragraphs were not added for two simple reasons: the quote itself was already too long and I felt it summarizes well enough the gist of the argument: programming languages should not allow 'clever' tricks. But, lets discuss the 'for clause' and 'do loop': these constructs were made specifically for one kind of simple loop. It is not a systematic solution for an…

"I agree with todd8, but would like to add that the next paragraphs were not added for two simple reasons: the quote itself was already too long and I felt it summarizes well enough the gist of the argument: programming languages should not allow 'clever' tricks."

It still seems intellectually dishonest to leave it out. Clearly, what Dijkstra in 1972 considers too "clever" may in fact be tools that are now basic building blocks of everyday software. We can all agree that "too clever" is bad. We can't agree on what "too clever" is.

"But, lets discuss the 'for clause' and 'do loop': these constructs were made specifically for one kind of simple loop. It is not a systematic solution for an iterative process."

I'm fairly sure (from what I remember him writing) that he doesn't like it because you can do the same thing with existing constructs, so you'd be adding complexity to the language that isn't strictly necessary. History has shown that actual programmers prefer having for loops like Algol.

"To me it seems Dijkstra specifically aims for languages such as LISP (which, with the renewed interest from Clojure is one of the most oldest successful (semi-) functional programming languages)."

Probably not, or else he would've talked about LISP in a different manner (he does talk about it in an earlier paragraph).

Re: Making the move from Scala to Go

#264
post #251
post #209

Earlier quoted context omitted.

I've used Scala, Clojure, and Go. I found Scala to be too feature-rich for its own good. It was fun to write (Look at me! I just spent two hours figuring out how to compress this old Java 7 function into a one-liner in Scala!), but reading someone else's Scala was almost as mind-numbing as reading another programmer's C++. Go is... meh. Quick to learn, easy to write (and read), but you quickly hit a plateau as far as…

The way you describe your experience with Scala makes me think you only had a very superficial look at it. At it's core Scala is very simple & the syntax is very regular, far more than Go or Java and a lot less complex than C++. It's the most expressive typed language on the JVM, so if you like to think in types & you're on the JVM it's your best option. Clojure is untyped, I hear many people praising it but I don't…

When I read comments like this I wonder if the person posting is trying to justify their own development decisions or seriously trying to "enlighten" the person they're responding to.

Re: Making the move from Scala to Go

#265
post #240

Earlier quoted context omitted.

I agree with Dijkstra, the looping constructs of FORTRAN's DO and ALGOL 60 were too baroque. Dijkstra's comments were written in 1977, at that time FORTRAN IV and ALGOL 60's loop semantics were a mess and were common sources of errors. Without qualification, Dijkstra was one of the greatest computer scientists in our field's short history. While I don't agree with every single one of his ideas, I would encourage budd…

I know about Dijkstra. I didn't say Dijkstra was talking out of his ass in this case. I'm saying you often can't tell when people like him are talking out of their ass, as they sometimes do . Who would think the inventor of all these algorithms would ever utter a half-formed thought, on a whim? Unthinkable! Yeah... no. Another distinction you fail to see is that somebody who is great at finding the best or optimal al…

> Another distinction you fail to see is that somebody who is great at finding the best or optimal algorithms (i.e. a great theorist) isn't necessarily a productive programmer.

I suppose what you're saying here is that there are a lot of business tasks which don't require a great theorist.

I don't think Dijkstra would disagree.

But still, calling Dijkstra an "unproductive programmer"? Really? I'll take one Dijkstra's algorithm over a dozen web apps. And if I can have a patent on it, I can even make a solid business case for that choice.

> If we followed his opinions on how to program, we wouldn't get much of anything done.

And yet, how many man-years of engineering effort could we waste having bad theorists who can quickly hack out LoB code try to re-invent Dijkstra's algorithm?

Perhaps software engineering is a very wide field, and it takes all types?

Re: Making the move from Scala to Go

#266
post #220

Earlier quoted context omitted.

The second example is vastly more readable in terms of understanding what it is supposed to do. I mention this as neither a programmer on either Scala nor Go. If it is of any relevance, I've been writing code for about 20 years across C, Java, Javascript, PHP and shell scripts. I'm sure other FP developers will roll their eyes to a traditional developer like me but the one-liner you mention is simply not self-explana…

The second one is so readable it contains a subtle bug nobody noticed.

What 'subtle' bug ?

It returns 'email' instead of 'emails' which I assume was a typo, which of course the compiler would complain about, are you claiming that a variable name typo is somehow a 'subtle bug' ?

Only other thing I see directly is that 'users' is undefined, but this is a code snippet after all, not a working program.

Re: Making the move from Scala to Go

#267

Maintaining a Scala code base for some years, I've learned a lot. I would not go back to a language that does not support Option/Maybe and map/flatMap. These really changed my coding style. My largest problems [1] are all still there after years, developers only payed lip service and that killed Scala I think. The largest bad design decision was to support inheritance which leads to it's own problems with type infere…

Is there something that you can express with Option that you cannot express with a nullable type?

Re: Making the move from Scala to Go

#268
post #109

Earlier quoted context omitted.

OP is about Scala, where you write directly what you mean, without special operators: val usefulMetric = if (wantComplexCalc) { complexCalc(foo) } else { simpleCalc(foo) }

I'd rather have Python's way of doing it, which plays with the order for the sake of readability: useful_metric = complex_calc(foo) if want_complex_calc else simple_calc(foo)

Ruby has something similar, and I can't stand it. I think the conditional is the most important item in the phrase, and it's shoved off to the right. If you lead with the conditional, it becomes immediately apparent that the assignment is predicated on the result of a branch.

Re: Making the move from Scala to Go

#269

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…

IMHO it's a wrong approach. Every programming language, just like the spoken ones, has it's common shortcuts and idioms. The fact that they're commonly accepted and used is what makes them easy to understand. Your brain learns to recognize them quickly, often much quicker then the long version. With newbies and programmers who switched from other languages problem is that their brain is just not yet trained to do tha…

Your underlying assumption that everyone working on the code will be skilled is wrong in any large team. It's not like it takes a lot longer to read a 3 line if statement than a ternary operator.

Terse code isn't much faster to read, the difference between a 300 and 400 line file isn't significant.

Your attitude of "he isn't 1337 enough to understand my code" is the logic that leads to no comments and horrible to maintain code in the first place

Re: Making the move from Scala to Go

#270
post #231

This mentions weak IDE support as one of Scala's pain points, but Go has very much the same problem, and the language is vastly less complex. The two best IDEs for Go right now IMO are VS Code and the EAP Gogland, but both of them are not yet on par what you get with Java. VS Code has only support for very rudimentary refactoring (renames) and relies on a rather slow horde of external CLI linters (executed on save) t…

Go can be written without good IDE. I just use Sublime with Go plugin it works great. Also Gogland gives sub-par experience to many experienced Go users. E.g. it does not use `gofmt` but their own formatter which they use for all IDEs. Not sure about their refactoring tool but `gorename` seems to me fine refactoring tool.

Any language can be written without a good IDE. This argument is always given when a language doesn't have a good IDE.
Post reply on HN