On Dec 19, 3:39 pm, Reinier Zwitserloot <[email protected]> wrote: >Then you've got python, ruby, groovy, haskell, lisp, lua, fan and many more to >compete with > 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.
Only to the extent that you think it's a winner take all world. Since it's not a winner take all world, Scala can be "big" without being seen by as "cooler" than all those languages. By the way, I know two of them (Haskell and Common Lisp) and I think Scala is much cooler in some dimensions and much less cool in others. I sorta know about Fan and think the idea of optional duck typing is intriguing. Lua I know nothing about, but I'm sure it has something cool too. Also, in the history of all programming languages, Scala already is "big". And so are all those languages except perhaps Fan. Not Cobol or Java big by any stretch of the imagination, but bigger than the million language you and I have never even heard of. Scala will likely never, ever be Cobol or Java big. And none of the languages in your list will, either. But if that's the only yardstick for language success then concede "failure" now. Scala is not destined for that. > > 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 I cry FUD and BS! /: and :\ are perfectly ordinary methods Scala's List class. You might as well say that "length" is always imported in Java because it's a member of the String class. > double-edged sword of operator flexibility, and the use of 'implicit > def' is pretty much forced on you anytime you use certain libraries. You can import what you want and use be explicit wherever implicits are called for. There emphatically is a "wait, I'm not ready for this" setting. > 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, So now you're complaining that Scala is a high level language that's removed from the details of byte code? Seriously? Do we need to have the asembly vs high level language wars again? Look, Scala's magic isn't that magic. Structural types are done with reflection - don't use in performance critical code. Closures and by- name parameters are objects - same overheads as always with allocating a bunch of small objects. It's not much more deeply mysterious than Java code. The compute language shootout bears me out on this. >'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? Concrete, actual example from real code or it didn't happen. > JAMES: Yes, java's generics inference can create some pretty crazy > error messages and they often point to the wrong place. Touché. Your This isn't an inference problem. It's an interaction between several complicated bits of Java. 1) Java's arrays are covariant. That's fundamentally unsound so Java plugged that hole with runtime checks. 2) Varargs are implemented with arrays. 3) Generics are implemented with type erasure. 4) Hilarity ensues. Java could have prevented the problem by fixing any of steps 1 through 3, but didn't. Scala fixes #1. It actually fixed #2 for awhile, but that caused Java incompatibilities. > > 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 Oh come one. It's a typo. Quite likely caused by snippets from two different versions of the library being pasted into the document. But whatever. Here's the part you didn't mention but which I asked for: the error message associated with that screwup. scala> type Action = () => Unit defined type alias Action scala> def test(a : Action) = a() foo: (() => Unit)Unit scala> test(println("foo")) <console>:7: error: type mismatch; found : Unit required: () => Unit foo(println("foo")) The error message couldn't be more clear. It emphatically does not support your thesis that Scala's syntax prevents clear error messages or that Scala's syntax requires a compiler with "A.I.". So, I ask again, give an actual example where a syntax error is indecipherable. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
