A better language design means fewer corner cases, fewer forward references when learning and a higher signal to noise ratio in code.
Those are real things that real programmers benefit from. I don't get all this nonsense about whether something is academic or not. Ask instead whether it's correct, whether it's useful, what it needs to be useful if it's not. The subject here isn't politics or religion, we can handle the truth. On Oct 26, 2012 7:04 PM, "Fabrizio Giudici" <[email protected]> wrote: > On Fri, 26 Oct 2012 23:41:35 +0200, Simon Ochsenreither < > [email protected]**> wrote: > > >> I'm sorry, but I feel I should point out that this contributes to the >>> academic/elite argument about Scala. >>> >> >> >> Isn't this argument getting boring after a while? I think it is sad that >> "academic" is being used as a slander along the line of "not being >> practical". >> > > If you prefer "unpractical" to "academic" I'm fine, but the Merriam > Webster reports > (http://www.merriam-webster.**com/dictionary/academic<http://www.merriam-webster.com/dictionary/academic>) > as a meaning of academic: > > 3b. "having no practical or useful significance" > > > (I've checked just to verify that it wasn't a false friend to me). > >> Is there actual _any_ point someone is allowed to make which can't be >> hand-waved with "If you say that, you're an academic and therefore what >> you >> say doesn't count"? >> > > You are again misreporting my statement. I've said: you focus on the > compiler design, and most programmer just don't care of compiler design: > your argument doesn't "sell". *Thus* I think it's not practical > > In my opinion cleaning up syntactical and semantical warts and weirdnesses >> is one of the most practical things to do, but feel free to disagree. >> > > Generally speaking I don't disagree. I can think of the concept of a > language that's practically better than Java for most people, for me, and > it is syntactically and semantically cleaner than Java. What I'm saying is > that the implication "cleaner -> more pratical, more popular" is not > automatic. It's just that practical evidence says that people do care more > of other things. When we'll have more Scala programmers than Java > programmers I'll be proven wrong. Furthermore, there are many languages out > here and I don't think Scala is the only one cleaner than Java. > > Every item (except for "Hardcoded implicit conversions for certain types >> ") >> on the list above is actually something a user of Java is exposed to while >> reading code. >> > > ... and it seems people handle it very well. That's my point. BTW, > autoboxing, which I understand is not an elegant solution from the compiler > design point of view, is rather intuitive for a developer (what's not > intuitive is a bag of nasty side effects of autoboxing, such as performance > traps or equals() vs == mismatches, but honestly they aren't ruining many > programmers' days). I think this is a effective counter-example. > > No point above is in any substantial way related to an actual compiler >> implementation. >> > > So perhaps I've missed the reason for which you were citing them. > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/**blog <http://tidalwave.it/fabrizio/blog> - > [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to javaposse+unsubscribe@** > googlegroups.com <javaposse%[email protected]>. > For more options, visit this group at http://groups.google.com/** > group/javaposse?hl=en <http://groups.google.com/group/javaposse?hl=en>. > > -- You received this message because you are subscribed to the Google Groups "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.
