Scala: properties, closures, functional, and still OO. Still the JVM you love. WANT !
On Dec 21, 7:43 pm, Jorge Ortiz <jorge.or...@gmail.com> wrote: > "Scala is a better Java: closures, interfaces that can implement > methods, Erlang-style concurrency, user-defined control structures, > and more" > > --j > > On Dec 19, 8:35 pm, Weiqi Gao <weiqi...@gmail.com> wrote: > > > 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 > > (seehttp://www.weiqigao.com/blog/2008/03/24/scala_still_uncomfortable_aft...). > > 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 > > weiqi...@speakeasy.nethttp://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 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 -~----------~----~----~----~------~----~------~--~---
