Can write, can't read... Will Scala be the Perl of the JVM world? Hmm...
Alexey 2001 Honda CBR600F4i (CCS) 1992 Kawasaki EX500 http://azinger.blogspot.com http://bsheet.sourceforge.net http://wcollage.sourceforge.net --- On Wed, 12/17/08, Frederic Simon <frederic.si...@gmail.com> wrote: > From: Frederic Simon <frederic.si...@gmail.com> > Subject: [The Java Posse] Re: Scala for the enterprise? > To: javaposse@googlegroups.com > Date: Wednesday, December 17, 2008, 10:08 AM > Wow... > Well, from my personal short experience with Scala I can > say I really felt > this issue.In the last Scala Lift Off day, I was looking at > some code > written by Martin Odersky himself and the way the > variables, where used in > the list comprehension... Did not make sense to me. Then > when he executed > it, it failed. Solution: Write the code "a la" > Java by declaring variables > before using them... > > For me that's the point: Do you want to write 80% less > code if it takes 500% > more time to read and understand it? > The thing is that the gap may be due to my lack of Scala > knowledge, but the > fact is: I can write it, I cannot read it! > > Still very confused by this language. From what I see in > Clojure and Fan > (and FCM), powerful language features does not need to be > hard to read. > > I hope to invest my time in Fan in the future. > > Still missing DI and AOP anyway :( > > On Wed, Dec 17, 2008 at 1:14 PM, Reinier Zwitserloot > <reini...@gmail.com>wrote: > > > > > I don't think it's up to me to -prove- > scala's problems here, as > > proving it would take a few man-weeks- of work. Call > it personal > > experience + a strong personal conviction that if you > were to try and > > prove it, you'd succeed: > > > > As Alan said, scala's lenience in syntax (example: > allowing both a dot > > and a space), the ability to automatically rewire > objects to fit the > > required type, a.k.a. extensive inferred casting > (implicit def > > shenanigans), extensive inference for types. > > > > Note that haskell, for example, SPECIFICALLY chose to > have absolutely > > ZERO inferred casting, not even a float to an int, > because they > > believe that combining inferred types with inferred > casting eventually > > leads to ambiguous code, or if it doesn't, to code > which is only a few > > characters away from a completely different > interpretation. I'm sure > > Odersky knows about haskell, so where's the paper > to prove haskell is > > wrong? I'd think the onus is on scala to prove > that its strategy is > > sound, especially considering that the limited > resources we have right > > now, seem to indicate I'm right: The current > version of scalac will > > indeed bite your head off when you typo out. > > > > > > Personally, when I was toying around with scala, I ran > into quite a > > few very confusing errors. For about 3/4s of them, > when I finally > > figured out what I did wrong, I grokked the error > message. I > > understood what the compiler was thinking. But that > didn't change the > > simple fact that the error message was no help then > and would be no > > help later. I even realized that it would be really > hard to rewrite > > the compiler so it would have realized that I was > thinking along > > completely different lines. > > > > Such a compiler would need a hefty amount of A.I. and > would need to > > have the ability to provide a cascade of error > interpretations, where > > the compiler gives you a few different ASTs each with > their own > > (probably completely different) errors in them, along > with a button > > that reads: "None of these are close to what I > was thinking about, > > please use your A.I. to go to some more depth to come > up with even > > more outlandish interpretations". > > > > That sounds like an awesome tool, perhaps, but its > quite a leap from > > how we work now. The principle of highlighting > mistakes with red wavy > > underlines certainly needs quite some redesign before > it would work > > with a language that is so complicated that the > compiler is forced to > > give you multiple interpretations for most syntax > errors. > > > > > > Many of these problems are due to scala's > 'academic' nature: In > > attempting to prove how smooth the language can LOOK, > in the hands of > > a professional, they've made their grammar too > permissive. One is > > reminded of applescript, which looks fantastic (just > like english), > > but is virtually unwritable for a programmer, because > only very > > specifically structured 'english' sentences > are actually understood by > > the parser. > > > > For example, what if a method had to be specific about > which separator > > is allowed? You could still create DSLs in scala, > you'd just have to > > be more specific about it. Because often code is > adapted to function > > in different ways, some way to override the allowed > separator in your > > own source file with some sort of tactical import > statement might be > > warranted. Sure, this means any example showing off > this feature would > > not be complete without a bunch of 'settings' > lines, either in the > > source file that uses the separators, or the source > file that contains > > the method you'll be using an alternative > separator for. Looks bad in > > the example, but in practice works much better. > > > > What if scala would never cast automatically, and > implicit def instead > > was a feature to inform the compiler about being more > useful? What if > > using the 'wrong' type, but one where an > implicit def is available, > > simply causes the compiler to emit: A 'Foo' > doesn't work here. But a > > 'Bar' will, and I can convert a foo to a bar > for you here, by calling > > convert(fooInstance, Bar) or some such. Looks dumb on > a casual glance > > (if the compiler knows how to fix it, why doesn't > it do so?), but > > taking into account that people make mistakes all the > time, it is FAR > > easier to debug that error (Uh, whoops, I didn't > mean to use either a > > Foo or a Bar here, but this unrelated Baz thingie > instead!) compared > > to a runtime error where you seemingly execute the > wrong method. > > > > I could come up with a few more of these examples, but > it'd be all > > anecdotal. The real way to prove this is to take a > bunch of real scala > > code, write an engine that creates random permutations > of the text in > > ways that are similar to how humans sometimes make > mistakes, and to > > have some sort of measure of the distance between any > given source > > code file and any given AST. Then see how scala's > mean Distance > > between Nearest Alternative Interpretation (mean > DNAI!) compares to > > java's number, or python's number, or > haskell's number. > > > > Would be interesting research, surely, but not > something I can whip up > > in an hour or two. > > > > Moving it to the practical, I can boil it down to > this: the current > > version of scalac will be hated fiercely by > 'programming is a job, not > > a hobby' professionals, because it is of precious > little help when you > > make the invariable mistake. This will need to be > addressed before > > scala has a serious chance in 'the > enterprise'. I have no proof of > > this (no test lab with a roomful of programmers in the > basement, > > sorry), but from speaking with many other enthusiasts > who gave scala a > > spin, this was complaint one, with a big margin. > Anecdotal evidence > > will have to do. As an addendum, my gut feeling tells > me that this is > > a virtually impossible job without reducing > scala's syntactic > > flexibility. I have no proof of this. Merely many > examples and some > > incomplete reasoning based on the idea of thinking > about how scalac > > would have to be changed in order to be more useful > everytime it > > throws a confusing error at me, and not coming up with > simple > > solutions most of the time. Could be I'm a lousy > engineer. Could be > > its a formidable job. > > > > On Dec 17, 3:22 am, Alan Kent > <alan.j.k...@saic.com> wrote: > > > I thought the technical point was in the first > sentence - the point that > > > minor typos cause very strange/confusing error > messages. Because of > > > things like you can leave out semi colons, leave > out parenthesis, etc - > > > all useful in their own ways - it means that > given a sequence of tokens > > > the compiler may easily misinterpret what the > programmer intended. > > > Other languages with a more rigid grammar (e.g. > Java function calls must > > > *always* have parenthesis) makes it easier for > the compiler to correctly > > > guess what the problem really is. > > > > > > To me the real question is whether this is a > symptom of the language > > > grammar or just that the compiler needs > improving. Good error diagnosis > > > in compilers can be very hard to achieve with > more permissive grammars. > > > > > > Alan > > > > > > peter wrote: > > > > I read your rant but I do not see *any* > technical points. > > > > > > > On Dec 16, 5:06 pm, Reinier Zwitserloot > <reini...@gmail.com> wrote: > > > > > > >> No amount of tooling in the world is > going to fix scala's uncanny > > > >> ability to throw tantrums the moment you > make some typos. > > > > > > > > -- > http://www.jfrog.org/ > http://freddy33.blogspot.com/ > http://nothingisinfinite.blogspot.com/ > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
