2011/3/22 Cédric Beust ♔ <ced...@beust.com> > > > On Tue, Mar 22, 2011 at 9:29 AM, Kevin Wright <kev.lee.wri...@gmail.com>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. > > Neither actors nor cp are actually functional programming. Most implementations in production are actors that send messages to each other and internally mutate state. It's a good way to handle concurrency and locking, but also still very imperative. Not that it has to be, actors can also be completely immutable, just acting on a received message by sending another one.
This is not to dissimilar to the logical fallacy that OO and FP are diametrically opposed. > >> , 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()". > Google Guava's... and yes, that particular library has also drawn heavily from FP ideas, and its very necessity demonstrates some of the weaknesses of Java's default collections. Though it continues to propagate the lie at compile time that such collections can be mutated - only to risk a potential runtime error at some point in the future. This is a requirement imposed by the pretty impressive Java collection API, and unavoidable unless you wish to represent everything as an Iterable (as clojure does) Create a new List in Scala, try it right now, open up a REPL and type "val xs = List(1,2,3)", don't import anything first. Now try and find the methods to mutate it. This is the standard List implementation, as supplied by predefined imports. The language may not "enforce" immutability, but it certainly makes it the default and demands you to take explicit steps if you want anything different. > >> 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" > > Exactly, so it's a lie to claim that Scala doesn't have dot notation. It does, though this doesn't preclude the alternate infix notation. You'll also note the example in my previous reply when I pointed out exactly the same avoidance of postfix operators. > > 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. > Again, it's also a lie to claim that Scala doesn't use parentheses in method calls. Reinier didn't claim it's a problem that you can leave out dots and parentheses and semicolons in Scala, he claimed that the language doesn't have these things, that claim is false. Just because a language will allow you to leave a thing out, it does not mean that it doesn't have that thing at all. > 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. > Scalaz has always been a rich source of controversy, you won't see me arguing the point :) Though please don't use it as an example of idiomatic or typical Scala, this is a library that's truly pushing the boundaries of what the language can do. To use scalaz as an example would be like evaluating Java based on this: http://apocalisp.wordpress.com/2008/10/23/heterogeneous-lists-and-the-limits-of-the-java-type-system/ > >> >> >>> 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. > and case classes, can't get enough of them :) > 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. > > Nobody ever claimed they were parallelizable, nobody ever claimed you had to use them, nobody even ever claimed they were a particularly common practice. I can guarantee that, at no point, is any use of folds ever demanded by the Scala compiler. I personally find folds to be be to imperative in nature for my liking, they state *how* you are doing something and not *what* you're doing. This is a fold: val total = xs.foldLeft(0)(_+_) This is idiomatic Scala val total = xs.sum folds are are red herring, they exist, but so what? Reflection also exists, does that make Java a dynamically typed language because you can, optionally, do everything by passing raw objects into invoke methods? > > >> >>> >> 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. > > > Why, do you genuinely believe that Java prevents anyone from ever writing bad code by removing access to capabilities that would allow some people to write better code? -- > Cédric > > > -- Kevin Wright gtalk / msn : kev.lee.wri...@gmail.com <kev.lee.wri...@gmail.com>mail: kevin.wri...@scalatechnology.com vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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.
