Scala use is less good than Java use for at least half of all Java projects

http://goodstuff.im/scala-use-is-less-good-than-java-use-for-at-l

by DanielRibeiro • 15 years ago

115 83 15 years ago

goodstuff.im

zoowar• 15 years ago

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

jjm• 15 years ago

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

mark242• 15 years ago

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.

dkhenry2• 15 years ago

You comments on Lift are spot on. I think as a precursor to reading this post one needs to go write something in Lift. I better understand where this guy is coming from and understand why he gets his conclusions. That being said he is still wrong and your observation about the difficulty of the language are great counterpoints.

jerf• 15 years ago

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... 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.)

vegai• 15 years ago

"Kids can learn Scala."

Kids can learn anything. The question is, can adults learn it or do we have to wait for the kids to grow up?

wiredfool• 15 years ago

<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?

crenshaw• 15 years ago

I think that's an exaggeration. In the real world you spend a week trying to track down a nasty bug -- the net result is two new lines of code in a week. Or writing a bunch of new tests or creating a new test harness. Or designing new features. Or figuring out a way to rearchitect your code to add a new feature in a way such that any new similar features don't require code change at all.

I thought we had gotten past LoC as a measure of programmer productivity?

outworlder3• 15 years ago

We have. But we still have to write something, don't we?

super_mario• 15 years ago

That has not been my experience. I just wrote a script to compute my stats for the last 10 years. I did roughly 20,000 lines of code per year (this is not counting comments and empty lines, if that is included then this goes up to 35,000 lines). Oh, and I prefer VIM to Eclipse :D.

But using LOC as a measure of work quality or suitability for learning another language is really ludicrous. I would really hope that most people in the industry and Java programmers in particular are capable of learning Scala. I like to think that suitability of the language for a task is a quality of a language not the programmer. Yes, all languages in use are Turing complete, but some are better suited for certain tasks. The question we should be asking is what kinds of projects Scala excels at, and what kinds of applications is it really good for?

outworlder3• 15 years ago

> Oh, and I prefer VIM to Eclipse

And yet think you are part of the group mentioned by the article?

srparish• 15 years ago

Assuming lines of code is a valid argument, all the more reason to make sure those lines are doing as much as possible.

eengbrec2• 15 years ago

I would say in many places it is, but the numbers are often misleading. I'm not completely familiar with how we count it, but I believe when we count ELOCs (Effective Lines of Code) not only is the time people spend writing code counted, or even all the time spent by people who write code, but all the time by people spend on the "software engineering" portion of the project. That can include managers, requirements development, configuration managers, system administrators, QA, the people who collect metrics, etc.

So the number is really more reflective of how much an organization lumps under "software engineering" and how much general overhead its processes incur than it is of the productivity of individual programmers.

barrkel3• 15 years ago

Yes. In one particular business domain: much of the time is spent nailing down requirements, then adjusting very complex conditionals (so much of the business-spec requirements will be almost legalese nests of conditional clauses - in the insurance domain I have in mind, written by actuaries), tweaking UI, and fairly exhaustive testing.

outworlder3• 15 years ago

Yes.

However, that depends on who you ask. Specifically, try banks (and other financial institutions), Fortune 500 companies (exclude the more tech savvy such as Google, Microsoft as the code that does get written is meaningful), and anywhere that is infested with suits.

And, by the way: I believe that, out of the 20, 15 are XML.

freshhawk2• 15 years ago

Absolutely.

I took some high paying contractor gigs through an agency a few years ago because I wanted to figure out what direction to take in the next phase of my career, the cash was great and I'd never worked in the fortune 500 / government contractor kind of space before.

I wasn't that surprised when I got told that I was now their second developer (out of a few dozen) who "actually writes code in his free time sometimes! isn't that crazy!" since I was prepared for big company suit world.

The reality was right in line with the quote, if not worse.

fadzlan3• 15 years ago

This kinda remind me of a lunch that I have with an old friend. I was asking him (he works at a fairly large company) if he knows anybody who learns or codes stuff that is outside of their working area, and his answer is, possibly in the whole building that he works, there isn't another one.

Myself being a optimist, I don't believe that statement, there is probably someone. It has to be. Then again it could just be my wishful thinking.

michaelochurch3• 15 years ago

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.

vorg2• 15 years ago

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

SomeCallMeTim3• 15 years ago

I wrote and maintained most of a (2d) video game library over the course of four years. Almost entirely by myself. I just looked, and it comes to something like 80000 lines of code.

So you're saying I was maintaining code that was ultimately enough for four full-time maintenance engineers while developing two games as lead, supporting other developers to put together nearly 100 games based on that library (I was also externally-facing support), AND designing and implementing the beginning of the next revision of the library)?

And people also raved about my support, to the point where it felt like I had a fan club. Maybe the bar is just that much higher in video game development; I'm certainly not even the most efficient developer I know.

I did refactor the code from time to time, though there were a lot of games based on this library by the end that I couldn't risk breaking, so I couldn't change the public API. Mostly I just wrote it to be solid the first time around. It was the fourth or fifth time I'd written a similar game library; after a while you get the hang of it, you know? Not to say there were never bugs, but they were (almost) always easy to find and fix, since the architecture was solid.

My only point really is that rules of thumb like the one about 20k lines of code per maintenance engineer can be off by an order of magnitude or more, if you've got the right code and the right developer. I'd estimate that no more than about 40% of my time at the end was taken up by maintenance, and it was probably more like 25%. And a lot of my "maintenance" time was spent fixing bugs in other developers' games that they just couldn't find, and that weren't in my code at all.

barnaby• 15 years ago

Agreed. My net total for LOC written in the past year is probably -700, because I've refactored so much verbose code.

I don't know how to count unit tests in such a metric though... because I took a code base from 2% code coverage to 70% and that meant writing something like 200 LOC in unit tests alone per day, even though the actual code being refactored under these tests diminished in size.

silon• 15 years ago

This is true in my personal observation. I mostly wrote two pieces of software rougly 50,000 lines each, and it's my limit of manageability. Will need splitting up and modularizing if it needs to get larger.

fadzlan3• 15 years ago

Well, this does not address one of his core argument, which is basically coding for average Java developer is just one small part from his/her day activity.

Especially in the case of maintenance of existing legacy system, where most of the activity resolves around understanding existing code, writing is just a small part of it. If maintaining the system needs to be financially feasible, hiring expensive Scala developer may not be the best idea to maintain the system. Unless of course, using Scala outweights the benefits of using Java even with the potential financial cost.

vorg2• 15 years ago

When the programmers in these places take over the hiring process, they actively keep out anyone who can code better than average to protect their jobs. Many banks and insurance companies IT shops fall into this category.

peter_l_downs• 15 years ago

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

alatkins• 15 years ago

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

runT1ME• 15 years ago

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.

jshen• 15 years ago

I think the standard of success is profitability. By that metric many of these buggy java apps are profitable.

JoachimSchipper4• 15 years ago

Those developers are, largely, still employed at companies that are still not bankrupt. If Scala changes either of those, it will encounter resistance, no matter how bad the original code was.

grok2• 15 years ago

Perhaps he doesn't care that they are using Java unsuccessfully -- he is saying that he prefers they not have or have fewer failed projects in Scala...

barrkel3• 15 years ago

"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?"

All of these are secondary to turning a profit. If the only developer(s) the business can afford commits these mistakes, so be it; but if the developer is adding more value than he is costing, it still makes sense. And no amount of appeal to technical superiority will change this; there are too many businesses that can benefit from someone able to write software, but not enough returns for them all to hire great devs. This is basic economics. You can't fight it outside of a non-existent world of surplus.

cageface4• 15 years ago

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• 15 years ago

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)

dkhenry2• 15 years ago

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.

barrkel3• 15 years ago

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.

Flow2• 15 years ago

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.

JoachimSchipper4• 15 years ago

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.

andrewcooke• 15 years ago

the gap between what he felt and what you said is only large because you are, apparently, completely tone deaf. programming and communicating in english are quite different things. you are good at programming, apparently, but not at communicating with the written word. that's ok. after all 50% of people are below average. and just because you're not good at this doesn't mean you can't still chat to friends in the hallway.

JoachimSchipper4• 15 years ago

Another [dead] comment:

fogus 6 hours ago | link [dead]

In the case of my blog post I would say you are 100% correct. Without a doubt I was unable to get my point across since Mr. Pollack, whose work on Lift I respect, thinks that I attacked him personally instead of his point. As for my more general tone-deafness and inability to communicate using the English language I can only say that if I keep at it, then maybe I'll one day be successful.

eengbrec2• 15 years ago

I don't think the gap between what he originally said and your response was large. I was rather surprised by his "ad hominem" remark, but the rest of his last blog was pretty much exactly what I would have expected.

DPP's a freelance consultant, and I suspect one with no shortage of business. He'd rather stick to projects where the technology he is advocating won't get blamed if the project fails. That's not really surprising.

irahul• 15 years ago

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

JoachimSchipper4• 15 years ago

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.

bodski• 15 years ago

I agree, the only 'rebuttal' to fogus comment seems to be saying that he is tone deaf and bad at communicating with no explanation of why. The flagging of his comments seems to be other politics at work with no explanation of what they are.

ap22213• 15 years ago

The anonymous down-voting on hn is really a problem.

swah• 15 years ago

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

swift• 15 years ago

Yeah, neither can I, that's really bizarre. Shouldn't it extend Sum? (which doesn't appear to exist)

Can anyone familiar with this design decision shed light on this?

quatrevingts• 15 years ago

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.

kreek• 15 years ago

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• 15 years ago

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

calebmpeterson• 15 years ago

Covariance I was good with, but contravariance didn't click until I read that SO post. Thank you.

shadowfiend• 15 years ago

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

Stormbringer• 15 years ago

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.

dools• 15 years ago

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

naragon• 15 years ago

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

socratic• 15 years ago

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• 15 years ago

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.

vrode• 15 years ago

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'.

jrockway• 15 years ago

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!

fadzlan3• 15 years ago

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.

cageface4• 15 years ago

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.

cageface4• 15 years ago

OOP mirrors familiar, everyday imperative concepts. FP is much more rigorously mathematical and abstract. The evidence is overwhelming at this point that the average programmer finds the former easier than the latter, despite well over a decade of denial by some of the more vociferous advocates of FP.

Those people would do well to emulate DPP's example here and recognize that the long-term success of FP depends on selling to the right audience at the right time and not promoting it as a panacea.

bphogan2• 15 years ago

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.

cageface4• 15 years ago

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.

bphogan2• 15 years ago

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

kronix99• 15 years ago

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.

cgopalan• 15 years ago

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.

Scala use is less good than Java use for at least half of all Java projects

Related Stories