
Scala use is less good than Java use for at least half of all Java projects - DanielRibeiro
http://goodstuff.im/scala-use-is-less-good-than-java-use-for-at-l
======
socratic
There doesn't seem to be much discussion of the core of Pollak's argument.

Specifically, Pollak appears to be arguing that a key question in language
adoption is the historical or recent _win_ _rate_ for projects. (Ratio of
Scala projects that succeeded divided by total Scala projects.)

Pollak wants the average doofus Java developer ("COTM" as he terms them) not
to use Scala so that Scala's win rate stays high, even if Scala's absolute
number of wins remains low.

But having a multitude of doofus developers leads precisely to things that
Scala kind of lacks right now, like quality IDE support, idiomatic libraries
for every possible use case, and so on. Without the _hoi_ _polloi_ , why spend
a massive number of man years developing IDE support that can efficiently
parse incorrect source code in the language as correctly as possible? Why
write idiomatic payment processor code?

Similarly, focusing on only the best developers has arguably led languages
like Haskell and Lisp to be great languages for learning language constructs
and new ways to think, but poor day-to-day languages. (Though I do recognize
that Clojure is gaining ground, etc.)

In short, is Pollak right? Is win rate so critical to adoption of a new
language that Scala should kick out the COTM programmers? Or is he proposing
imposing an exclusiveness that will only slow the development of tools and
libraries necessary to open up the language to a larger and larger community?

~~~
stonemetal
Kind of depends on what you mean by adoption. If you just eliminated better
than 50% of developers for being "COTM" or less in ability, then the question
becomes adoption by whom? You can have it adopted by everyone without taking
COTMs too.

------
runT1ME
I think DPP has a fundamentally flawed argument: He seems to be assuming that
all those Java developers that fail to learn Scala are using Java
_successfully_.

Sure, their projects may compile, they may even be deployed and used on a
daily basis. But are they maintainable? Are they able to function when load
increases? Are there hidden race conditions that go unnoticed for years? If a
user inputs bad data will the application suddenly throw NPEs? Will moving to
a different hardware platform with more cores expose a fatal deadlock?

Scala's "weakness" is not that it is harder than Java, it's that it exposes
the difficulty and complications of software engineering to developers at an
earlier point in the development cycle.

If your standard of success is compiling and deploying a product, than yes,
I'll admit Scala makes it 'harder' than java. However, if you define success
as writing defect free, performant software, than I'd argue that Scala is
actually easier than Java.

~~~
cageface
Most software doesn't need to be performant or defect free. It just needs to
be _barely_ good enough to accomplish some task. An average developer with an
average tool like Java can meet that criterion.

~~~
Roboprog
Gotcha. In contrast, having a C program borking itself to death with wild
pointer errors is usually _not_ good enough. Thus, Java is in fact wildly
successful. (whether or not you and I are tired of it, and want something mo'
better)

------
mark242
I utterly, completely, totally disagree with this post.

May I cite: <http://www.scala-lang.org/node/10714>

Kids can learn Scala. It isn't "hard", any more so than the syntax of any
language is "hard". It's just another syntax to represent the logic you're
looking for. The FP aspect of Scala, imho, actually makes it _easier_ to write
this kind of logic.

I think Lift is way, way too heavy a framework. It seems like it's trying to
be Scala's version of Struts, which I guess is admirable, but Struts is also
way, way, way too heavy. Any time a web framework starts making you learn a
brand new templating language, that sets off warning bells. I like the concept
of snippets in markup, but I could honestly leave the whole render-logic-
inside-class-attribute business.

~~~
jerf
I'm not sure the fact that kids can "learn" language X proves much, because
generally we're teaching kids language X so they can take some kid-friendly
subset of the language and do kid projects in it. This is great on its own,
but showing that kids can learn Scala or Haskell doesn't necessarily mean that
they're going to be able to _program_ in it.

Here's a group using Haskell:
[http://cdsmith.wordpress.com/2011/09/03/haskell-for-kids-
wee...](http://cdsmith.wordpress.com/2011/09/03/haskell-for-kids-week-3/) Are
they choking and dying because Haskell is just too magically difficult for
children to learn? Goodness, no. On the other hand, does this prove that
Haskell is never confusing when you're three layers deep in monad transformers
trying to use a parsing library and you get a twenty-line error message about
a failure to unify types with type signatures bigger than Twitter will let you
post full of "a" and "t1" and "t2" and "t3"s?

I mean, let's be honest, that just doesn't happen when you're using Python or
Perl. (It can in Java, but still a lot of times it's just _verbose_ , vs.
Haskell's actual _complexity_.)

------
dkhenry
So I think it is clear this was a defensive response to valid criticism. The
initial "Virginia" post claimed that if you don't program Scala like he does
then your doing it wrong and its too hard for you. He still makes the claim
that Scala is too hard for most people and should be reserved for use by the
talented and/or motivated developers.

My criticism of this was that you don't need to program like him to have a
great Scala experience. You can still program in a OO manner and get plenty of
benefit out of Scala. As you get more familiar with it you will pick up some
nice features that it gives you that Java doesn't. Everyone comes at things at
a different level and I think its quite pretentious to claim that most people
aren't smart enough to use your tools and they need to stick with simpler
tools. If you give someone the tools they will learn to use it. The real
problem is when you need to be an expert to use the tools at all. thankfully
Scala isn't like that you can jump in with a hour or two of instruction and
write perfectly good Java++ code. then as you learn how to use the tool you
will pick up the nuances of the language and really unlock its power.

I would say this post like the last overlooks some of the broader issue and
really does the community a disservice.

~~~
barrkel
Your argument sounds exactly like C++ - as you echo in Java++ - and it
logically should come with exactly the same problems: different groups of
Java-Scala developers will adopt subsets of the language, with coding
standards etc., in an effort to institutionalize the simplification - but will
come up with different subsets.

I think it's too optimistic to expect most standard developers (normally
employed by companies whose main business is _not_ software) to "pick up the
nuances of the language" - these developers typically learn by example and
copy-paste-modify from other similar functionality to fill out the
application. They see their jobs as implementing features, and understanding
nuances is not typically the quickest way for them to get their job done.

~~~
Flow
I see what you are saying, but feel that C++ is in a different league than
Scala when it comes to why you avoid certain language features. If you don't
know exactly what a feature does in C++ you might end up with memory leaks,
excessive memory copy, having the wrong methods being executed or stupidly
long compile-times. Your app will simply not work with these problems.

In Scala(guessing a bit here since I've not done any large projects in Scala)
you might have hidden performance costs, method signatures for your own
library code that are insufficiently reusable because of lack of covariant et
al specifications.

But the rest of the problems for Scala seems to me to be style guide problems.
For example, using or not using . and ()'s, how many classes per file.

------
wiredfool
<blockquote>"We live in a world where the average developer writes 3,250 lines
of code per year (about 20 per day). This is going into Eclipse, pressing the
"give me pattern X" and filling in the blanks, then going to a few meeting and
calling it a day.</blockquote>

Maybe I'm out of the loop, but is it really this bad out there in the real
world?

~~~
michaelochurch
It's not about meetings, incompetence, or lax work hours. It's the reality of
software maintenance.

Lines of code is an awful metric of productivity but, yes, that figure of 3250
is accurate. Between 1,000 and 10,000 LoC per year is normal for a software
engineer in the industry, and the rate is often closer to the lower number.

Note also that code of average architectural quality will require about 1
maintenance day per year per 80 LoC just by virtue (vice?) of existing. (Paul
Graham: a full-time maintenance engineer can own 20,000 lines of code.) LoC
are a cost: if we rate a developer's time (including benefits, office space,
etc.) at $80/hour and charge each LoC for 4 years, we pay $32 per line of code
in maintenance. (We spend $2-3 per line to _write_ it.) That is, IMO, a pretty
accurate estimate of what we pay for software.

If you write at 500 LoC/day under ideal circumstances but you're writing code
that's merely average in architectural integrity, the maintenance problem will
catch up with you very quickly.

It's a lot better to write 150 lines per day of great code (200-300 including
unit tests and debugging utilities) and maintain that pace than to start out
at 500+ but stall out late in the project. Great programmers don't write code
at college-project speeds; they write in such a way that they can sustain
triple-digits in perpetuity.

A single developer solves this problem by refactoring the code when necessary
and incrementally improving the architecture so as to reduce the maintenance
cost. It's only by doing this that projects beyond about 15,000 lines of code
per person (75% maintenance burden if code is of average quality) are even
feasible.

It's not just a problem of incompetent developers. Maintenance imposes a 70 to
90% overhead on most important projects in large companies, just because these
projects become difficult or impossible to refactor and fix and their "broken
windows" patterns of decline take on a life of their own. Individual
developers can refactor aggressively when their maintenance burden breaks 50%
(70% being a crisis) but this is not usually feasible for multi-developer
enterprise projects that have changed hands several times.

The more progressive large companies now actively discourage any mention of
LoC in performance reviews. First, _deleting_ unnecessary code is one of the
best things a person can do for a code base. Second, if someone in a big
company generates 250 LoC/day reliably over years, it doesn't _always_ mean
that person is a great programmer; it could mean that, or it could mean that
he's always taking the fun, "green field" projects and passing the legacy
maintenance (on which 10 LoC/day is a typical clip) to others.

~~~
vorg
> Second, if someone in a big company generates 250 LoC/day reliably over
> years, it doesn't always mean that person is a great programmer; it could
> mean that, or it could mean that he's always taking the fun, "green field"
> projects and passing the legacy maintenance (on which 10 LoC/day is a
> typical clip) to others.

This is what I call the Dirty Little Secret of Corporate IT shops: The
mediocre programmers spin a story and slag off others to get the jobs
developing new systems or rewrites in new technology to pad their CV; the
programmers with aptitude end up in maintenance roles digging deep through the
said code to fix all the bugs afterwards and make that software usable, while
the mediocre programmers who wrote it are already in their next jobs doing it
again.

~~~
gaius
I absolutely agree with this. One of my more flighty cow-orkers sent round
this link yesterday - calling maintenance programmers "the residue". Yeah, him
and his mates have been talking non stop about how shit systems X, Y and Z
are, how they could do so much better etc. Meanwhile, that system, that I
maintain is _paying all of our salaries_. And those boys have produced
something approximating... sod all. While getting paid by the revenues
generated by that old code.

[http://brucefwebster.com/2008/04/11/the-wetware-crisis-
the-d...](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-
effect/)

~~~
bartwe
Inversely I have had experiences with maintenance coders going like
mercenaries into code i wrote and without respect for architecture or future
extensions making changes because they didn't understand the code and we're
not interested in the concepts behind it.

~~~
gruseom
_going like mercenaries into code i wrote and without respect for architecture
or future extensions making changes because they didn't understand the code
and we're not interested in the concepts behind it_

This is a problem even when the maintenance programmer is not a mercenary.
Check out the essay by Peter Naur (the N in BNF) called "Programming as Theory
Building". It's one of the best things ever written about software (albeit in
disappointingly bloodless language) and explains this masterfully.
[http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn...](http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn,+Musashi%22)

The essential point is that source code and documentation, no matter how well-
written and extensive, are insufficient for understanding a large system. You
have to have the "theory" (the article explains what this means) and for this
you have to have someone who knows the theory.

------
kronix99
Let me start by saying that I love using Scala and consider it a net positive
but stating that anyone who can't grok Scala is a poor developer just
absolutely smacks of arrogance. Every tool has drawbacks.

1) Documentation for the standard Scala library is absolute crap. The JDK is
much better at not only documenting methods in a reasonable way but also
giving you common usage patterns for classes/packages. I really don't like
having to piece together the method signatures of a class to figure out the
intended usage pattern.

2) This might be a problem in IntelliJ but I can't figure out a good way of
getting the debugger to work well. Sometimes it'll catch breakpoints other
times it won't.

3)Lack of maturity in libraries. A perfect example is Scala's built in XML
support. It works for 90% of what you want to do but finds good ways to waste
your time, especially if you're dealing with namespaces.

4) Obscure syntax and abuse of the single argument method call syntax. What
does :+ mean to anyone? What's the difference between +++ and ++ or :: and
:::. Scala is a dyslexic's nightmare and I don't agree with such heavy use of
symbolic shorthand.

Again I love Scala and have used it write some heavily parallel code with
minimal effort thanks to the functional nature of Scala but I feel like the
learning curve is a lot harder than it should be.

------
JoachimSchipper
Relevant [dead] comment:

fogus 20 minutes ago | link [dead]

    
    
        ad hominem rhetoric

Yikes! I seem to have struck a chord with Mr. Pollack. The problem is that I'm
not sure that the gap between what he said and what I said is very large. I
certainly wasn't attacking him in my post, although I did link to his article.
Additionally, I would never question his Scala credentials, but I tend to
question those who say that Scala is complicated based on type signatures and
syntax oddities. However, I will say in that with his latest post I think the
gap between our opinions has widened. His comes off as cynical, but I have to
think that I'm misreading the post. I do however find it odd that "ad hominem"
would be used by someone who bases a dev's programming potential on the number
of hours they choose to work during the day and their familiarity with Zed
Shaw.

~~~
irahul
Why is fogus being downvoted? I don't see anything wrong with his comments -
he is being civil and rational.

~~~
JoachimSchipper
He's not getting downvoted, he's getting flagged - mere downvotes don't result
in [dead] comments.

I didn't follow the whole discussion (especially since I was on holidays), but
the comments I saw were not obviously worthy of being [dead]; hence my repost.

------
dools
_"just as there are those that can code PHP but could not code Java."_

Really? The use of the word "could not" here seems kind of presumptuous.

It's possible that the "barrier to entry" for PHP is simply lower because
there are more places you can easily run a "hello world" script, but once
someone is setup with some kind of repeatable code -> deploy process "writing"
the difference between "writing" one language and another is relatively
benign.

He seems to be making out that Java is some kind of hard language to learn
compared to PHP.

I learned Java before PHP (and after C/Assembly at uni) but I much prefer
writing code in PHP compared with Java - not because Java is "hard" but
because it's annoyingly verbose.

Perhaps what he's referring to is not so much people that "code PHP" but
people that "get something running" based on existing software or copied and
pasted module snippets (like installing Drupal or Wordpress modules).

That would seem to me to be more in the realm of running Macros in Excel or
Word than actually being a "coder".

I seriously doubt that there's anyone who's capable of writing a program from
scratch in any language that couldn't learn to do it in any other language.

------
cgopalan
This is just unfortunate.

First David writes a post thats not befitting of a person that promotes a
language. I am not doubting his competency with Scala - his display of his
contributions prove that. But I have found that there is somewhat of an
inverse relation between a person being productive in and promoting a language
to how much he disses other languages as well as extolling the virtues of his
own language. I am pretty sure you will not hear such stuff from people like
Martin Odersky, Rich Hickey and Matz. Guido I am not so sure, ;) (j/k, I am a
Python enthusiast)

Now that that was said and done, would it have been a big deal to close the
chapter and move on?

The only way such a post would have struck somewhat of a cord is if he gave
specific code examples for each case as to when scala is hard, or when scala
is better. Theres not much of that in the post.

"What has changed is that I've realized that there's a vast quantity of
development shops where the developers show up, have a few meetings, write a
few lines of code and go home. I've had experience with three instances of
that kind of company over the last year"

This is one instance of how off-the-cuff the post can sometimes get. I am sure
there are shops like this, but can you draw a conclusion that the above
situation equates to what he says in his previous post: "Your developers come
in at 9:15 and leave before 6 and don't check work email at night: Hard"

I thought his was the humor section of the post, but I am not so sure now.

I knew of David from a while back when Lift was starting to get popular among
people looking for a different web framework. There's no doubt Lift leverages
a lot of Scala's strengths. But maybe sometimes (times like this) David should
let Lift do the talking.

As I said, simply unfortunate.

------
swah
I just checked and can't really make sense of why Option extends Product, so
it's probably not for me.

<http://www.scala-lang.org/api/current/scala/Option.html>

~~~
quatrevingts
Option is implemented only by the two case classes Some and None. All case
classes implement Product automatically. Having Option extend Product allows
access to these methods from variables with the static type Option.

I'm having a hard time thinking of a use for the Product interface to Option,
but I suppose it might as well be allowed since it is implemented anyway.

------
peter_l_downs
Alternative title: "Up to half of all Java projects could use Scala better
than Java"

~~~
alatkins
Pleased I'm not the only one who had trouble parsing the title...

------
Stormbringer
Just because I like tools that are powerful _AND_ easy to use doesn't mean I'm
stupid.

A good tool should be a force multiplier, not just another damn hurdle.

------
vrode
I tend to get confused when people mix the discussion of syntax, coding style
and API into the aspects of environment itself.

This pointless way of thinking is very much like finding a more appropriate
keyword for a public field, while trying to improve the methods by which VM
handles big integers.

Scala is liberal.

It allows you to express yourself more elegantly. But freedom comes at a cost
(this is natural!). The price is learning it, remembering it and a constant
state of awareness for all the patterns it has to offer.

The speed of a compiler (think of PyPy), is a thing that can be improved at
least to some extent. But very few people are willing to work on the inner
structure of a language, that you doom to be inappropriate for 50% of the
tasks out there.

Look at the set of various languages as a biosphere of evolving organisms.
They tend to improve. If there was no demand for Scala or PHP, they wouldn't
have occured in the first place.

I think the original article and the follow-up is a poorly disguised attempt
at elitism, or maybe just an excellent way to challenge people.

I will say it in simplest terms possible, what really matters is how Scala
handles tail-recursion, not whether it allows it. And the first point is out
of reach for consideration, if you are a simple developer that may encounter
'learning difficulties'.

------
bphogan
This doesn't surprise me in the least.

The problem with Scala's adoption in my opinion is that everyone, Pollack
included, writes about Scala being a "better Java." The Scala books out there,
his book included, take that approach. assuming that its audience is a bunch
of Java programmers that want a better syntax. "Instead of using this syntax
to call this existing Java library, you do this instead:"

So, of course he's going to get frustrated when the Java folks don't "get" it.
The article links to another article about the "perils of JavaSchools" which
don't teach "real programming."

Scala, like Clojure, strives to be "real programming" on the JVM. It's
exciting, and in my opinion, a very fun language and can totally stand on its
own.

So, given that Pollack is finding that the benefits are not always there for
Java programmers, maybe we'll see a shift in the way Scala is taught or
presented. I know at least I would love to see a "so you know Perl, Python, or
Ruby? Learn Scala!" approach.

~~~
cageface
The chief problem with this is that a big part of Scala's value proposition is
its integration with the JVM. In fact, a lot of the more awkward bits of Scala
(and Clojure) are the price that has to paid to interoperate with Java. It's
worth it for predominantly Java shops but for people already outside of that
ecosystem it just looks like baggage.

For people without debts to the JVM I think it would make as much sense to
just jump to Haskell.

~~~
bphogan
Agreed on one hand, but there is some great stuff on the JVM, and that is
stuff you could expose people to _eventually_.

------
kreek
As I'm self taught I lean towards the engineering side of software
development, should I do a CS crash course before tackling Scala? Any advice
on the best CS books to read?

~~~
DanielRibeiro
If you can use the map function from collections and if you understand why
function with one argument has the following signature[1]:

    
    
        Function1 [-T1, +R]
    

Then you should be fine

[1] Explanation here: [http://stackoverflow.com/questions/5277526/real-world-
exampl...](http://stackoverflow.com/questions/5277526/real-world-examples-of-
co-and-contravariance-in-scala/5279656#5279656)

~~~
shadowfiend
Not even. To date, while I've learned about and understand contravariance and
covariance, I haven't really needed to distinguish between the two in code
I've written. I also haven't really needed to distinguish between them in code
I'm writing.

The thing about type signatures is that if they're set up properly, you rarely
have to think about them. Only when your assumption and the reality of a type
system disagree do you have to look up why that's happening. And then you can
look up covariance and contravariance is necessary.

But then, that's just the learning approach that works for me. Call it `Just
In Time learning or `Agile learning'. `Learn learning', even...

------
zoowar
One thing is clear, Lift documentation is 'less good' than any other
documentation.

~~~
jjm
I'm going to have to say I somewhat agree with this personal observation a
bit.

------
jrockway
If the reason people shouldn't use a tool is because they are too dumb to
understand it, they're not going to be able to use the other similar tool
either.

Programming in Scala and programming in Java are equally difficult. That's
because the hard part is programming. The easy part is the syntax. If you are
mentally capable of "getting" OOP, you are mentally capable of "getting" FP.

If a team decides that Scala is the right thing for their project, then it
should be no problem transitioning the good programmers over. After all, it's
just programming!

~~~
fadzlan
To be fair, not all people who use OO languages 'gets' it. They still get
things done (there are a lot of simple things in the market) and although
their works are not in the excellant range, it is good enough and they do come
by much cheaper.

When resources are cheap, things get less risky in a way since people are much
more easily replaceable.

Now, I do not condone or even like to work at those kind of places, but that
is just the reality in most places.

~~~
cageface
A huge amount of code gets slapped together by mediocre programmers but still
serves a useful business purpose. I think we should be trying to design
languages that are accessible to people like that but less cumbersome to more
skilled developers. Scala was intended to be such a language but I think it
has unfortunately overshot its goal.

I have high hopes for Jetbrains' Kotlin project. Even though I don't do any
JVM development at the moment if Kotlin turns out to be a good Android
language I might pick it up just for the pleasure of programming in such a
nice environment.

------
naragon
'Scala use is doubleplusungood in at least half of all Java projects'

