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

301–310 of 378 posts

Re: Making the move from Scala to Go

#301

Post by tel »

Karrot_Kream wrote: post #285
pka wrote: post #239

Earlier quoted context omitted.

> If I am facing a problem that I have never faced before, I like to start off without any types in my code, and then, as I understand the problem more, I like to add in more contract-enforcement. This seems to be a widespread sentiment. In practice, I've found that prototyping anything remotely complex without types is so painful that I'd rather settle for an inferior design than trying to come up with the best poss…

> In Haskell, I come up with a coherent skeleton without having to implement mundane details, hit a wall in the design space because of some case I didn't think of, come up with a better idea and then go back to the code and refactor with confidence. The type system always guarantees that my prototype is coherent as a whole. And I can do that dozens of times. Could you go into a bit of detail about this approach? Do…

I'm about 5% into a side project implementing Erlang-like actors in Haskell and it provides an example of this workflow.

https://github.com/tel/hotep

Note that src/Hotep.hs exports a bunch of undefined functions. I've been able to verify that these types all make sense even without implementing a thing. As time goes on I may learn that the implementation drives the types somewhere else and then the compiler will make refactoring easy.

However, already I've gone through about 5 iterations of this design which drove me to debug some structural questions about the whole affair and also dive deep into Erlang documentation to determine how they solved problems. These explorations and their results are encoded into the types.

At this point I'm beginning to consider implementation and I can keep filling out just partial implementations against these types. I'll probably make 2 or 3 toy implementations to test out the ideas again with more strength before moving on the final ones. The whole time the types will be guiding that development and helping it move quickly.

Key to this whole affair is the need to describe types utterly before a completely successful library is made... and also the ability to defer the burden of providing type-checking code for as long as desirable. Haskell supports this wonderfully—even more wonderfully with things like Typed Holes and Deferred Type Errors which enable a really great interactive experience I haven't yet needed to employ.

Re: Making the move from Scala to Go

#302

Post by edejong »

sten wrote: post #261
edejong wrote: post #253

Earlier quoted context omitted.

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.

I hereby correct you. You are wrong.

Dijkstra decided to program using pencil and paper much later, and mostly because he (like most good programmers) already knew the solution before writing it down.

I correct you again for implying he wrote purely academic code. This is plainly false: for example, he specified part of and implemented the compiler of the Algol-77 language. He implemented one of the first multi-layer (ring-based) OSes.

And then you mention the day-to-day programmer is not in need of academic code. To the contrary! Dijkstra argued that the software crisis (the gap between what computers can do, and what they are actually doing) is caused because day-to-day programmers do not have the right tools and knowledge at hand. In EWD 340, Dijkstra argues this is caused by the mental overhead caused by clever tricks and languages allowing these tricks.

As a professional, I am constantly relating to concepts and code which have an academic basis. Examples are from type theory, lambda calculus, paxos, map-reduce, queueing theory, compression algorithms and many more. I have seen many programming languages, wrote assemblers, interpreters and compilers, worked professionally with imperative, OOP, functional and (higher-order) logical languages, so I dare to say that programming is not about what you can do with the language, but what the language does with you.

Re: Making the move from Scala to Go

#303

Post by edejong »

kazinator wrote: post #299
galacticpony wrote: post #263

Earlier quoted context omitted.

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

> We can all agree that "too clever" is bad. We can't agree on what "too clever" is. Of course we agree. Too clever is "stuff I'm too lazy to understand". What we don't agree is on the definition of I ; everyone has their own binding for that symbol, which carries a context for different types of stuff we are too lazy to understand.

Interesting take. 'Too clever' for me is: 'using underlying concepts which have semantics that have a poor mental overhead versus applicability within the domain'.

Re: Making the move from Scala to Go

#304

Post by cube2222 »

lazyjones wrote: post #175
unoti wrote: post #52

I have a simple question. In the article they mentioned they had a concurrency issue with a timed buffer that they later neatly solved with go channels and goroutines. They said that they solved the problem in Scala by moving to the actor model, but that required importing Akka into their project and training everyone how to use Akka. My simple question is: couldn't they have achieved the heart and soul of the actor…

I found the Go solution for that issue a bit odd - channels aren't for data processing, they're synchronisation primitives. Using them the way they did in the article ruined the piece for me, since it reads like a rather uninformed decision now.

That's just not true. You often use channels for messages of various kinds, or for returning values in async code.

Re: Making the move from Scala to Go

#305

Post by importantbrian »

galacticpony wrote: post #257
todd8 wrote: 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…

> To the contrary, perfectionism and productivity are at great odds.

I've learned this the hard way in my career. I always have to fight against taking the extra 20 hours to perfect something when it only took me 1 hour to get to 95% and 95% is more than good enough for the particular task.

Re: Making the move from Scala to Go

#306

Post by macintux »

hyperpape wrote: post #221
fpgeek wrote: post #149

Earlier quoted context omitted.

As long as you get your mutable code right. If there are any unintentional holes in your instantiate/operate/consume box...

There just isn't that much to get wrong in pure for-each loops: def filter_broken(widgets): broken_widgets = [] for widget in widgets: if widget.is_broken(): broken_widgets.append(widget) return broken_widgets The actual errors with loops and mutable objects come from complex nested loops, continues/breaks (multi-level ones especially!), extra boolean conditions, and sharing mutable objects between parts of the code…

Hm. Wouldn't your code reverse the order of the list?

Maybe that's right, maybe that's wrong, but it's indeterminate from the code whether it's desired, whereas a filter function and a reverse function would make it explicit.

Re: Making the move from Scala to Go

#307

Post by josch »

oelang wrote: post #251
jcadam wrote: 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…

I guess Scala being "the most expressive typed language on the JVM" is true in the sense that it has a ton of features (OOP, FP, Exceptions, null Java backwards compatibility, etc.), but that's just too many features for a coherent language.

Re: Making the move from Scala to Go

#309

Post by lacampbell »

enqk wrote: post #138
lacampbell wrote: post #132

Earlier quoted context omitted.

Why? The code is still there even when a person leaves.

Code is really hard to work with without the theory that surrounds it, and is alive in the people who worked on it. Peter Naur - Programming As Theory Building http://pages.cs.wisc.edu/~remzi/Naur.pdf

Legacy shitcode is legacy shitcode. If it's owned by someone at least we can push for a sane interface, which is better than the abandoned communal messes I encounter in the real world.

Re: Making the move from Scala to Go

#310

Post by lacampbell »

runT1ME wrote: post #136
nemothekid wrote: post #127

Earlier quoted context omitted.

>And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". IMO, the answer is people vastly underestimate the cognitive cost of reading code. "Code" rarely exists in a vacuum, the reader has a universe of inputs, outputs, problems, solutions, failures and goals. The cognitive cost of trying to read someone's code is something that must be paid multiple times per day and at one poi…

I'll keep repeating myself: the cognitive cost of "code" is dwarfed by the cost of understanding an application . If a couple esoteric languagn features take an extra few hours to learn but reduce LOC tenfold, it's a price I'd pay every time. Not everyone feels this way, the investment to learn these features may not pay off right away, and if you come from a "move fast and break things" language (python/php/js) it c…

I can't up on this enough. If the line count is low and the interfaces are great I'll forgive all manner of oneliners.
Post reply on HN