> 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.
I wasn't referring to this sort of person at all (a type of person I have not met for years, but thats probably due to the circles I am in). Why must we use something that is suitable for these sorts of people? I thought the promise of a MLVM is that producers/consumers of features and libraries could use what they please (within reason). (perhaps I posted this to the wrong topic). On Dec 17, 10: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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
