replies inline... On Dec 20, 2:06 am, James Iry <james...@gmail.com> wrote: > 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.
This thread is about conquering the enterprise. In the enterprise, fan, scala, lisp, lua, haskell, etcetera aren't big. They are non- existent. > > 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. > Except 'length' is much more descriptive, and /: and \: are aliases for foldLeft / foldRight (a more appropriate simile would be that Java's String classes support both 'length' AND 'size' in the name of making code 'easier to read', which I think we can all agree is not really a good strategy to get there. Lastly, in java, the length method is run via someString.length() and that's the only way to do it. In scala you've got a bazillion ways to foldLeft. The dots are optional, they can bind to either side (/: hangs right, :\ hangs left), the list end can form via an implicit def, and so and so forth. Java does not have this problem, so trying to analogue to java is a mistake in the first place. > > 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. No; you don't program in a vacuum. You use libraries. It'd be kind of a drag if an enterprise shop decides: You can't use libraries that use any implicit def in its API, because we abhor implicits in general. > > So now you're complaining that Scala is a high level language that's > removed from the details of byte code? Seriously? Seriously? Why don't you follow the thread a bit better! I was specifically highlighting that the argument 'you can just use a java debugger to figure out why the compiler isn't doing what you thought you wrote' is not a viable strategy. That's all. > This isn't an inference problem. [about generics array created for varargs > error]. That one isn't. Believe you me I can tell you every last detail about that personal crusade of mine in my sleep. I was referring to java and generics in general: If you use a lot of inference (static methods instead of constructors, not assigning to variables but directly inserting into method parameter lists, a few layers deep), you can get some very weird inference that errors in the wrong place. > >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. Look a little closer. There isn't an easy fix for this, other than using an scala.lang level implicit (and I don't think I need to extoll about the monsters that lie in that direction), and the compiler really isn't all that helpful in fully understanding why () => FOO is somehow different from => FOO / named parameters. > So, I ask again, give an actual example where a syntax error is > indecipherable. I'd love to oblige. I ran into 4 of them in a week when I was writing a project in scala about 7 months ago. Since then I've barely scala at all, and I'm not willing, for the sake of this argument, to spend a day creating the particular mix of methods and code again to give you the compiler errors. One of the involved swapping the parameter order for a fold operation which caused a wildly different interpretation. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
