ok right - yes I kind of ignored the title of the post didn't I ;) I do see your point - but I think you are a bit dismissive of the work and also quiet successes of scala out there - there is no reason why some of those points can't be addressed, but yes there is a chance it won't be suitable for that 90% you are talking about.
I am not sure about those figures you just made up - but I do see your point. I am just not convinced these old dogs couldn't cope with a bit more then java makes them cope with (it actually makes them cope with a lot more then you realise). On Dec 20, 10:39 am, Reinier Zwitserloot <reini...@gmail.com> 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 javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
