I agree with you on this.. To be honest, defining complexity in terms of the metrics is a big task and the scope changes for each condition..or state in the language.not even perception, actually the third party outlook or environmental expectations has to be taken..
regards, jd On Sat, Aug 7, 2010 at 4:32 PM, Kevin Wright <[email protected]>wrote: > I do worry that people are using a self-referential definition though: > "easy = That which Java programmers are familiar with" > > > By that definition, Java is easier than LOGO. > and yet this instinctively feels wrong; I know from personal experience how > difficult it is to e.g. explain the need for static compilation to a child > > Kids also seem to understand "pure" functions more readily. Where every > time you call them with the same input, you get the same output, guaranteed. > Kids also like immutability. When you create some variable `myBirthday = > 22-04-1977` then it's fixed, because birthdays just don't change > (well, unless you're a monarch or a major celebrity, even then kids will > recognise it as a kind of cheating) > This is clearer when you consider the opposite... > > I recently had the misfortune to work on a Java codebase containing a > method `void toXml(Element xml)` > This would take the supplied node as a root, and mutate it in-place to add > some child nodes. It was not fun to unit test. > That sort of thing would never be tolerated in Scala, its the very > antithesis of FP, and I can imagine the difficulty in explaining that > `toXml` definition to an 8 year old. > > Admittedly, there is a long journey in learning to distinguish between > "familiar", "easy" and "simple", but IMO it's one worth taking. > > > On 7 August 2010 11:32, Ben Schulz <[email protected]> wrote: > >> There is a difference between perceived complexity and actual >> complexity. Some tasks the human mind excels in and we intuitively >> know the correct answer. Java (mostly) stays in this domain which >> reduces the perceived complexity, even though the actual complexity >> (due to baggage and backwards-compatibility) has gone through the >> roof. On the plus side one does not have to be a rocket scientist to >> read and write Java code, but when one's intuition of what is right >> gets confounded, i.e. one stumbles over a Java puzzler, things get >> hairy. >> >> Scala on the other hand has its complexity in all the right places: >> Where it helps developers solve complex problems with complex >> solutions. The issue with that is of course that reading library >> code[*] requires a lot more than the seemingly simple Java code. >> >> On the whole I have to give the edge to Java (complexity-wise) in that >> anyone can understand it; and that's what is being discussed here, >> right? >> >> [*] When debugging, I tend to step into library code to get a clearer >> understanding of the overall situation; if I can't understand the code >> then I'm hosed. >> >> PS: As far as fantom goes, I really want to like it, but I just don't >> see the point of having an unsound type system. >> >> With kind regards >> Ben >> >> On 7 Aug., 08:56, JodaStephen <[email protected]> wrote: >> > The Fantom BNF grammer is 144 lineshttp:// >> fantom.org/doc/docLang/Grammar.html >> > - Java: 368 lines >> > - Scala: 257 lines (EBNF) >> > - Fantom: 144 lines (BNF) >> > >> > However, these numbers need normalizing before comparison, as Fantom's >> > is written in a more compact style than Scala. >> > >> > As Charles says, grammer isn't that decisive or useful, but its useful >> > to go to the next step of defining what are the learning points of the >> > language. At that point, the optional elements reduce down to far >> > fewer learning points. >> > >> > For example, LanguageX has n concepts to learn. Each concept can then >> > be given a subjective simple/complex rating 1 to 10, et volia! >> > OK, its psuedo science, but its better than counting spec pages... >> > >> > Stephen >> > >> > On Aug 6, 11:07 pm, Kevin Wright <[email protected]> wrote: >> > >> > > You can't claim that the numbers I posted are subjective, I counted >> > > them fair and square! >> > > *this* post however, will be subjective. >> > >> > > The idea that all kids go to "high school" and have a "grade 11" is >> > > also subjective :) >> > > I give you... Kojo!http://netbeans.dzone.com/learn-scala-with-kojo >> > >> > > It's also subjective to simply discredit any methodology that happens >> > > to disagree with your gut feelings. >> > >> > > Incidentally, the "few object-oriented features" in Scala amount to a >> > > more complete/purer OO language than the entirety of Java. >> > > i.e. >> > > all values are objects (no primitives) >> > > all members are defined on an *instance* of some class, and are >> > > capable of inheritance/overriding (no statics) >> > >> > > The way I see it is that Scala = Java >> > > - the non-OO bits >> > > - other boilerplate >> > > - frustrating restrictions >> > > + FP >> > > + a world class type system >> > >> > > and yes, that's subjective. At least until someone comes up with >> > > measurable criteria for "frustrating restrictions" :) >> > >> > > On 06/08/2010, ADRA <[email protected]> wrote: >> > >> > > > This whole topic is by its nature subjective. Its not like Scala and >> > > > Java are exact language fits for one another. As I see it, Scala is >> a >> > > > functional language that has some object oriented features. Java is >> an >> > > > object oriented language with a few procedural features (baggage) >> and >> > > > will eventually have a few functional features. If you want to ask >> > > > which one is easier, ask yourself if you like Wrox or Head start >> > > > books. Each book conveys the information to you in the end, but each >> > > > person reading them will have wildly different takes on each style >> of >> > > > presenting the content. >> > >> > > > If you really want a quantifiable result, then get a pilot program >> > > > with two high school grade 11 classes and teach one class Java and >> the >> > > > other Scala. Personally, I find Java vastly simpler understand and >> use >> > > > vs Scala, but I come from a solid procedural foundation long before >> I >> > > > touched java. To forget the educational background of the person in >> > > > question is a horrible mistake to make in this topic. >> > >> > > > -- >> > > > 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]<javaposse%[email protected]> >> . >> > > > For more options, visit this group at >> > > >http://groups.google.com/group/javaposse?hl=en. >> > >> > > -- >> > > Kevin Wright >> > >> > > mail/google talk: [email protected] >> > > wave: [email protected] >> > > skype: kev.lee.wright >> > > twitter: @thecoda >> >> -- >> 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]<javaposse%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> >> > > > -- > Kevin Wright > > mail/google talk: [email protected] > wave: [email protected] > > skype: kev.lee.wright > twitter: @thecoda > > -- > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- 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.
