As long as you smart people are having discussions like this, us enterprise developers will just wait. :)
I have tried Scala, and felt uncomfortable with it (see http://www.weiqigao.com/blog/2008/03/24/scala_still_uncomfortable_after_five_years.html). I'm not disagreeing with all the principles behind Scala, but to make it a viable enterprise language requires a lot of investment, retraining of personnel, and integration work, etc. The question is very simple: What is Scala? What do I gain by switching to Scala? The trick is, you have to distill your answer to fifteen seconds or 140 characters, whichever is shorter. And you have to keep saying it for fifteen years or until everyone agrees with you, whichever is earlier. As an example, the message for object-orientation was: "OO is encapsulation, inheritance, and polymorphism. It lets you reuse your code." -- Weiqi Gao [email protected] http://www.weiqigao.com/blog/ Reinier Zwitserloot wrote: > Replies to everyone, specifically: Michael, Peter, Casper, Gabriel, > Jorge, and James. > > MICHAEL: > > I am confused about your continued insistence that 'enterprise folk' > aren't relevant to this discussion. See the name of the topic. But not > just that: > > enterprise folk are also the main bastion of java. (enterprise folk > are people who program solely because it is their job. They don't toy > with new languages as a hobby, and for them looking into another > programming language isn't worth it unless it has a positive effect on > their paycheck and/or their political power at work.) They aren't just > the majority of programmers, but they are also an untapped market. 90% > of them do Java, 10% of them do Microsoft stuff, and that makes 100%. > Other languages do not intrude here, except maybe a tiny smidgen of > PHP. That's way less competition, compared to the folks who look into > programming languages for fun. Then you've got python, ruby, groovy, > haskell, lisp, lua, fan and many more to compete with. If scala is > going to grow into something big, it either has to be so amazingly > incredible it can handily beat ALL those languages in coolness. That's > a hard sell. If not, then it has to make inroads into those > 'enterprise folk'. Scala is sort of intended as a drop in replacement > for java in many ways (a big one is its compatibility with not just > the JVM, but the way it tries to integrate with Java (the language) by > e.g. generating a nice class with a constructor, toString, equals, > hashCode, and getters, for case classes. No other JVM languages go > this far). It therefore seems that scala is trying to go after this > crowd. > > And therein lies the relevance of this discussion: It seems they don't > realize they don't have a snowball's chance until someone sits down > and really thinks this one through. > > PETER: I think you completely missed the point. Sure you can write > ugly code in Scala. If you couldn't do that, it wouldn't be turing > complete :P. But when you do, and we all invariably screw up, scala > bites your head off. This isn't good. And I _claim_ that it isn't easy > to fix. My point -isn't- about 'complicated code'. You could have a > programming language that is unbelievably complex but that still gives > you useful pointers when you make mistakes. As I said, I don't buy > into the 'keep it simple' train of thought, but I do, strongly, buy > into the thought that a real programmer works with an IDE and has > better things to do than debug by eyeball. > > CASPER: The coalesce operator is an abomination. It should not exist. > Instead, you should have something like: coalesce(a, b, c, d, e), > where coalesce is just a utility method defined in a library. Possibly > a library in java.lang, possibly something that is import staticed by > default, but a library nonetheless. Relegating that stuff to operators > is sillyness - where would you possibly draw the line if 'coalesce' is > useful enough to warrant an operator? Incidentally, scala is one of > the few languages that can completely do coalesce in method form, > because scala has lazy evaluation for parameters (you could write one > in java, but every parameter would be evaluated, whereas in coalesce, > like in e.g. || and &&, when an earlier parameter is not null, the > rest isn't even evaluated). It's also not nearly as common as you > might think. In a language with some closures and a Maybe construct, > for example, it hardly ever happens (because 'null' is then not used > to signal 'not found'). > > GABRIEL: But you CANT get the car out of sports mode. Scala is set to > sports mode out of the box and you can't fix this (another MAJOR > problem with Scala I tend to harp on about). Stuff like /: and :\ are > always imported. Unless you want to write a boatload of import > statements to 'unimport' these, and include that in every single scala > file you write, you're stuck with those. You're also stuck with the > double-edged sword of operator flexibility, and the use of 'implicit > def' is pretty much forced on you anytime you use certain libraries. > There's no way to tell scala: Not right now with that advanced stuff, > I'm not ready for that. Please don't use those, I'll write just a > little more boilerplate. Or I'll import what I need instead of > starting with a list of cryptically named operators and methods as > long as my leg. As you yourself said, you haven't written much Scala > code. You won't run into these issues until you've written a little > more. > > JORGE: You make many valid points but few of them are relevant to my > issue. For example, why does it matter that scala produces java > bytecode? I'm complaining specifically about the way scalac doesn't > help you very much. The bytecode produced by scala when your code does > happen to compile, but not the way you imagined it, is sufficiently > 'magic' that it is very difficult to use that to figure out where > things went wrong. You need an intimate understanding of scalac to > even begin to make sense of it all when scalac doesn't do what you > think you meant. (with all due respect to the scalac team, they've > done an AMAZING job making scala code run fast eventhough it really > isn't a way of coding that the JVM was ever designer for!). I'm not > talking about scalac producing 'incorrect' bytecode in the sense of > 'bug'. I'm talking about scala reading your code, which just so > happens to be valid, legal, scala, but it isn't what you think it > means. For example, you swapped a fold operation around but due to a > bunch of implicit defs, the List<Foo> gets translated to a List<Bar> > and the Foo gets translated to a Doohickey<Baz> and those are foldable > as well, and because of all the latent typing, the bad types percolate > up so far that the point where it goes wrong is miles away from the > problem and you just sit there scratching your head. How do you debug > this one? > > I mentioned that scala has a better type system. The problem lies in > scala's extensive auto-casting AND extensive auto-typing. Those two > together spell trouble. Scala's typing system is very good. But it's > not very explicit, quite unlike java's. Then there are the simple > gimme's that scala does NOT have, such as a 'version' keyword to > specify which scala language version you want to compile with. > > JAMES: Yes, java's generics inference can create some pretty crazy > error messages and they often point to the wrong place. Touché. Your > specifc mention of 'generic array is created for varargs' is a point > I've harped about, mailed Sun about, mailed java engineers about, and > so far everyone in this newsgroup eventually agreed that javac is > effectively buggy on the topic (you're right, it's in the wrong > place), but everyone at sun just didn't get it and explained to me the > danger. I tried to reply that that wasn't the problem, but no luck :( > > As far as a practical example, here's one that is so complicated that > a core scala developer (Martin himself?) screwed it up in the official > docs. Trying to make sense of what's going on took me about 30 minutes > of reading specs and chatting about it with the kind folks in > FreeNode's #scala: > > http://lampsvn.epfl.ch/trac/scala/ticket/1188 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
