8 ms·

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

115 points by DanielRibeiro 15y ago

zoowar 15y ago
One thing is clear, Lift documentation is 'less good' than any other documentation.
- jjm 15y ago
  I'm going to have to say I somewhat agree with this personal observation a bit.
mark242 15y ago
I utterly, completely, totally disagree with this post. May I cite: http://www.scala-lang.org/node/10714 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.
- dkhenry 15y 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 15y 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-week-3/ 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 15y 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 15y 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 15y 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?
  - outworlder 15y ago
    We have. But we still have to write something, don't we?
    - michaelochurch 15y ago
      Sure, but there's an order of magnitude difference in average difficulty (at least) per LoC in legacy maintenance vs. green-field development, and most software jobs are in the former camp. It's true that 20-40 LoC/day is a fast clip in most of the software industry; it's not true that this results from laziness or too many meetings. Hacker News gives us a rose-colored view of the software industry-- one in which knowing about functional programming and agile methodologies (regardless of whether one intends to use them) is a prerequisite for being considered literate, and in which 200 line-per-day development on new invention is something people can actually get paid for. That's now how the average developer experiences software.
    - SoftwareMaven 15y ago
      If what you are measuring doesn't give you data you can really make decisions with, it is worse than no data. You'll be tempted to make a decision because you have that data. BTW, this is one of my startup rules: measure what's important. Decide what's important by how it would affect your decision-making.
peter_l_downs 15y ago
Alternative title: "Up to half of all Java projects could use Scala better than Java"
- alatkins 15y ago
  Pleased I'm not the only one who had trouble parsing the title...
runT1ME 15y 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 15y ago
  I think the standard of success is profitability. By that metric many of these buggy java apps are profitable.
- JoachimSchipper 15y 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 15y 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...
- barrkel 15y 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.
dkhenry 15y 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.
- barrkel 15y 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.
  - Flow 15y 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.
fogus 15y ago
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.
JoachimSchipper 15y 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 15y 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.
  - fogus 15y ago
    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.
  - JoachimSchipper 15y 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.
swah 15y 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 http://www.scala-lang.org/api/current/scala/Option.html
- swift 15y 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 15y 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 15y 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 15y 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-examples-of-co-and-contravariance-in-scala/5279656#5279656 http://stackoverflow.com/questions/5277526/real-world-exampl...
  - calebmpeterson 15y ago
    Covariance I was good with, but contravariance didn't click until I read that SO post. Thank you.
  - shadowfiend 15y 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 15y 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 15y 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 15y ago
'Scala use is doubleplusungood in at least half of all Java projects'
socratic 15y 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 15y 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.
cgopalan 15y 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.
vrode 15y 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 15y 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!
- fadzlan 15y 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.
  - cageface 15y 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.
- cageface 15y 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.
kaffiene 15y ago
I find the chauvinism against Java displayed here quite disturbing. Java - like all tools - is good at some things, poor at others. Stigmatizing programmers on the basis of the tools they use ('Blub' programmers? C'mon!) is coarse and invalid discrimination, no different to sexism or racism. Being a language bigot isn't the same as being a good developer, no matter what PG or HN group-think says.
bphogan 15y 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.
- cageface 15y 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.
  - bphogan 15y 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 15y 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.

115 points by DanielRibeiro 15y ago

zoowar 15y ago

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

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

mark242 15y ago

I utterly, completely, totally disagree with this post. May I cite: http://www.scala-lang.org/node/10714 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.

dkhenry 15y 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 15y 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-week-3/ 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 15y 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 15y 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 15y 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?
- outworlder 15y ago
  We have. But we still have to write something, don't we?
  - michaelochurch 15y ago
    Sure, but there's an order of magnitude difference in average difficulty (at least) per LoC in legacy maintenance vs. green-field development, and most software jobs are in the former camp. It's true that 20-40 LoC/day is a fast clip in most of the software industry; it's not true that this results from laziness or too many meetings. Hacker News gives us a rose-colored view of the software industry-- one in which knowing about functional programming and agile methodologies (regardless of whether one intends to use them) is a prerequisite for being considered literate, and in which 200 line-per-day development on new invention is something people can actually get paid for. That's now how the average developer experiences software.
  - SoftwareMaven 15y ago
    If what you are measuring doesn't give you data you can really make decisions with, it is worse than no data. You'll be tempted to make a decision because you have that data. BTW, this is one of my startup rules: measure what's important. Decide what's important by how it would affect your decision-making.

peter_l_downs 15y ago

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

alatkins 15y ago
Pleased I'm not the only one who had trouble parsing the title...

runT1ME 15y 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 15y ago
I think the standard of success is profitability. By that metric many of these buggy java apps are profitable.
JoachimSchipper 15y 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 15y 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...
barrkel 15y 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.

dkhenry 15y 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.

barrkel 15y 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.
- Flow 15y 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.

fogus 15y ago

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.

JoachimSchipper 15y 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 15y 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.
- fogus 15y ago
  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.
- JoachimSchipper 15y 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.

swah 15y 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 http://www.scala-lang.org/api/current/scala/Option.html

swift 15y 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 15y 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 15y 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 15y 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-examples-of-co-and-contravariance-in-scala/5279656#5279656 http://stackoverflow.com/questions/5277526/real-world-exampl...
- calebmpeterson 15y ago
  Covariance I was good with, but contravariance didn't click until I read that SO post. Thank you.
- shadowfiend 15y 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 15y 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 15y 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 15y ago

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

socratic 15y 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 15y 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.

cgopalan 15y 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.

vrode 15y 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 15y 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!

fadzlan 15y 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.
- cageface 15y 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.
cageface 15y 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.

kaffiene 15y ago

I find the chauvinism against Java displayed here quite disturbing. Java - like all tools - is good at some things, poor at others. Stigmatizing programmers on the basis of the tools they use ('Blub' programmers? C'mon!) is coarse and invalid discrimination, no different to sexism or racism. Being a language bigot isn't the same as being a good developer, no matter what PG or HN group-think says.

bphogan 15y 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.

cageface 15y 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.
- bphogan 15y 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 15y 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.