On Tue, Mar 22, 2011 at 9:29 AM, Kevin Wright <[email protected]>wrote:
> Repeated case studies have shown time and time again that imperative code > is harder to reason about > Come on now. I was going to ask you for some evidence to back up this claim but the fact that there are millions of lines of code written in imperative style today is enough to prove this claim completely wrong. Can we improve over the imperative style? Of course. But assuming that the only way to do so is by switching to a functional, actor based or asynchronous style is just the illustration of how blinded by your Scala love you are. Personally, I find Actors and asynchronous/CP style much, much harder to reason about. It has some benefits and using such techniques is occasionally the best way to solve certain problems, but again, arguing that these techniques are an improvement over the current state of affairs with no drawbacks whatsoever is delusional. > , I defy you to find me a single person who's seriously looked into the > question who won't also claim that this aspect of Java's collections is > unnecessary complexity. > > Don't make the mistake of thinking Java's collection framework is good > design simply because of your own familiarity. Times have changed and > problems have been discovered, but backward compatibility has become a > ball-and-chain, preventing Java from removing problematic features, other > JVM languages don't have this burden. > Overall, I think the Java collections are a pretty impressive piece of work, considering the constraints in which they were designed. They are easy to use, effective and fairly versatile. Java's accidental verbosity sometimes leads to more lines of code than I'd like to see, but I would definitely call Collections a resounding success overall (they even survived their retroactive generification, which is quite a feat). Scala's collections have some very interesting properties too but they haven't been out for an entire major version yet and they are already coming under heavy fire (read Tony Morris' blog or his rants on #scala to get an idea). That's not a good sign. The parallel collections also feature some interesting stuff but I think they have crossed the academic threshold too far to be of interest to mainstream Scala programmers. I also find it interesting that for a language that claims to have embraced the next killer feature, parallelism (something I completely disagree with, by the way, just like Rainier), it's necessary to resort to libraries to actually get some juice out of the nice properties of immutability instead of leveraging the language. I already mentioned in a couple of previous messages to this mailing-list that Scala-the-language does close to nothing to enforce immutability, and the new collections prove this point. In effect, we're not in a very different situation from Java's "ImmutableList.of()". > no semicolons: Scala has semicolons, they're just optional when it's > obvious what's going on > Do you even see the problem with this kind of statement? > no dots: Eh, since when? Scala uses dot notation for calling methods > exactly as Java does > No it doesn't. Come on Kevin, seriously? You need to improve on the objectivity side of your statements if you want to be taken seriously. Here is Martin's "Scala tip of the day" from yesterday: " tip of the day: Avoid postfix operators except in a DSL. Use f.op, not f op. Much safer for semicolon inference" no parens: Same as dots. > Here is another tip from Martin, from a few days ago: "tip of the day: Never omit ()'s for methods that have side-effects." Kevin, I'm seriously beginning to wonder if you know Scala as well as you think you do. Read through "Java Puzzlers" again, look at how many of those problems no > longer apply to Scala... > Do you seriously think that a book called "Scala Puzzlers" could not exist? I could write one just by taking random commits from the scalaz project. > > >> It gets more complicated if you want to change the underlying structural >> data (i.e. the fields). For example, envisioning a way to make >> java.awt.Point immutable requires a lot more crazy stunts, but at least you >> could make a Point 'class' that is mostly immutable, i.e. will only end up >> changing if you pass it into code that uses the old API and that code makes >> changes to it. >> > > Ahh, yes. Such as the ability to change a public field into a method, for > example. This is known as the universal access principal, and was another > core design goal of Scala, > Yes, this is great. As are traits and compact class declarations. You repeatedly bring up the presence of folds as your main argument for the > claim that Scala isn't ready for concurrency, but the truth of the matter is > that folds aren't actually used very much at all in a great deal of Scala > programming. > Tying the concept of folds to a programming language is quite baffling. Folding is an algorithmic concept and it's something that you have to do on a regular basis, regardless of what kind of code you are writing or what language you are using. You iterate over a collection and you perform an operation that has some sort of side effect. Some people enjoy trying to wrap the operation in a monoid so they can say that their code is pure, others just use an accumulator and move on with their life. The bottom life is that from a practical standpoint, 1) folds are not parallelizable and 2) they are pretty easy to write in a non functional style. > >> > I'll leave you with a great snippet from Glen Vanderberg: > http://www.vanderburg.org/blog/Software/Development/sharp_and_blunt.rdoc That's a horrifyingly condescending quote making fun of people who actually ship software. -- Cédric -- 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.
