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