Hacker News Reader

Comment by frio | Hacker News Reader

The big problem I had with Scala, and the reason I stopped actively developing in it months back, was its similarity to Perl's philosophy: there are too many ways to skin the same apple. Problems can be resolved functionally, imperatively, or in some (inevitably, when you come back to work on it, hard to follow) hybrid of the two; unless you set down clear restrictions and code guidelines, one man's Scala is entirely different to the next's.

I initially liked the expressivity the language afforded (and some of the supporting ecosystem - sbt, specs - I found extremely impressive), but came to abhor it over time. Unfortunately, after maintaining legacy Perl applications I've developed an aversion to anything that doesn't follow the Zen of Python: "There should be one-- and preferably only one --obvious way to do it."

View on HN

  > I've developed an aversion to anything that doesn't 
  > follow the Zen of Python: "There should be one-- and 
  > preferably only one --obvious way to do it."

this is an interesting argument. but surely, given enough rope, a non-expert can hang himself in any language. I'm starting to wonder that all these language X vs language Y problems are really a matter of the skills of the team matched with the difficulty of the problem. joe bloe's blog needs beginner skills with python. embedded wireless systems need experts and C/asm, nuclear control systems are prototyped by experts in haskell. bigcos need large teams of average skill with Java, but as they are driven to become more competitive, perhaps they will turn to small teams of experts using scala.

The difference is how easy a language makes it to hang ones self, or how many ropes are lying around to do it with. I think the article touches on it aptly. It's not so much a fault of the language (one can debate the semantics of it), so much as it is an outcome of greater-than n-sized (where n is 1, 2, maybe 3) non-high-expert-Scala-users teams. The lack of an easy to grok idiomatic way of writing code is hard on a team. It bothers me when I write code and don't know the idiomatic way of doing it, and I'll often solicit feedback and rewrite it just for my own sake (really, on code that no one else will ever really see or touch).

> surely, given enough rope, a non-expert can hang himself in any language

I completely agree, and sometimes productivity absolutely demands that developers become more expressive. I've found Java overly restrictive in the past, and have spent time learning Python, Haskell and other languages (and seen decent increases in productivity when I feel less fettered by the language I'm programming in). That said, I've also come to appreciate the effect of more restrictive languages: readability and long-term maintainability. Coming back to old code can always be jarring; having to maintain decade-old Perl written in a variety of different styles was maddening.

While you can screw up in anything, it's worth appreciating that more expressive languages effectively hand you more "rope" :).

> having to maintain decade-old Perl written in a variety of different styles was maddening.

Interesting... I wonder how many languages can still run a decade old program?

This shows both the strength and weakness of Perl in that...

i) It has excellent backward compatibility

ii) So no one is forced to improve or update the program (over time) :(

nuclear control systems are prototyped by experts in haskell

Do you have any source to back that (honest question)?

C. For the non-control and more fucking your shit up systems

It might be a pun referencing Atom ( http://hackage.haskell.org/package/atom-1.0.11 ) which is used for control systems, but not nuclear ones, AFAIK

not a nuclear control system, but embedded monitor (slide 26:

http://www.galois.com/~leepike/fm-galois.pdf

nah, no sources, but its the quintessential application of haskell

I honestly suspect that kind of stuff is more likely to be done in Ada.

It's easy to blame the user, but the fact is that there are languages designed in good taste and languages designed in bad taste. I'd argue C++ is an example of the latter, with its panoply of awkward non-orthogonal features. It's quite possible that Scala is too, and that it's not just the user's fault.

I'd consider that Scala is pretty much on the “good taste” side.

The features are very orthogonal and thought-out and much of the old legacy cruft is removed.

I don't know how you can consider Scala's features as being orthogonal.

Because I actually have used it, which separates me from “experts” like Colebourne.

I spent a while in Perl and tend to agree, I was the only one in my group who went out of his way to write readable/maintainable code. Everyone else believed in extreme code ownership and enjoyed playing "golf".

I've never coded in Python, but spent a little time in Ruby and liked how they knew you could do things many different ways, so the community and leadership focused on identifying and promoting idioms. I think that's a key factor in adoption. Perl had some of that (and the excellent "Effective Perl" had a chapter on it), but you need to make it part of your culture.

> so the community and leadership focused on identifying and promoting idioms. I think that's a key factor in adoption. Perl had some of that (and the excellent "Effective Perl" had a chapter on it), but you need to make it part of your culture.

Yes it does need to be part of your culture. And there is no reason for a Perl team/shop not to because best practise idioms are heavily preached [1] and baked into [2] Perl and its community.

[1] Modern Perl movement & Perl Best Practises (http://en.wikipedia.org/wiki/Perl_Best_Practices)

[2] Perl::Critic (https://metacpan.org/module/Perl::Critic), Moose (http://moose.perl.org), EPO extended core (http://www.enlightenedperl.org/extendedcore.html), etc

Python has been by far the most straightforward and easy language for me to pick up and just code and also read out of anything I can remember. Not that I use it a whole lot, it's still beautiful to me.

This is a fair complaint, but doesn't Python let you mix functional and imperative styles just as much?

It does, but the point is that with Python there's generally one "obvious" way of accomplishing something. With Scala, I found when tackling certain problems (and my memory is fuzzy here; like I said, it's been several months :)), no particular solution stuck out as obvious. I'd consider myself fairly expert in Python now, so it may well be that what I see as obviousness may well be (reasonably) deep domain knowledge... but I didn't find the curve with Python anywhere near as steep as Scala's.

It's not nearly as ingrained into the language as Scala. Python's functional tools are rather basic. My understanding is that Guido believed that adding too much functional style to Python risked making the language muddled, exactly as we're discussing. A prime guideline for the language has always been (from the Zen of Python):

> There should be one-- and preferably only one --obvious way to do it.

http://fold.sigusr2.net/2010/03/guido-on-functional.html

http://python-history.blogspot.com/2009/04/origins-of-python...

has some notes on the history of functional tools in Python, though not much reasoning.

> Curiously, the map, filter, and reduce functions that originally motivated the introduction of lambda and other functional features have to a large extent been superseded by list comprehensions and generator expressions.

unless you set down clear restrictions and code guidelines

What happened when you tried?

I was using Scala on some lone projects as prototypes, working with at most one other developer. In the end, we decided against it; there was never a chance to set down such guidelines (which I'm sure would be effective). The spectre of our Perl codebase was too much, sadly.

> The spectre of our Perl codebase was too much, sadly.

Just curious, though -- was that Perl codebase written and factored correctly, or was it already a big mess when you got it?

Compared to Perl though, thankfully in Scala you do have a static type system to protect you from going too crazy.

> I've developed an aversion to anything that doesn't follow the Zen of Python: "There should be one-- and preferably only one --obvious way to do it."

Ok, so which language(s) are you using then?

ZoP doesn't say that there should be only one way to do something, it say there should be one obvious way to do it. That doesn't preclude alternate, equally or - preferably - less obvious ways. Many languages could stand close to that aphorism.

Reply on news.ycombinator.com