Oh sure, you can go way beyond this! For example, should the standard library be considered part of the language? On one hand, Scala does stuff in libraries that Java handles as a core language feature, so there is grounds for a comparison here. On the other hand, stuff in libraries can be superseded or replaced in the future, so this is exactly what *shouldn't* be included in any complexity measurements of the spec. Scala also inherits Java's libraries and adds it's own, it can only *ever* so it'll always be at an unfair disadvantage here Nor can you compare Java libs to only pure Scala libs, as Scala depends on Java libraries and isn't standalone, so this would put Java at an unfair disadvantage.
My feeling is that anything where another user could come along and write an alternative should rightly not be considered part of the core language. So it's valid to not include libraries in this particular measurement. The other quality here is what I call "emergent complexity"; or the complexity that can arise from combining specified aspects of the language. This can't really be measured though, as both languages are Turing complete, so all you'll be measuring is which particular flavour of infinity is most appropriate - so not useful What else can we measure here? LOC for a cross-section of common programs is a good candidate, but a reduced LOC doesn't necessarily mean easier (e.g. perl) - so not objective I've picked the spec size as it's the only truly objective measurement I could come up with, but I'm open to suggestions for others. On 06/08/2010, jitesh dundas <[email protected]> wrote: > Can we measure complexity of the expressed functions in the Specs , besides > the complexity in user understanding > of the same, as a function here. > > Does that also come into the 30% that you mention here.. > > jd > > On Sat, Aug 7, 2010 at 1:37 AM, JodaStephen <[email protected]> wrote: > >> Excellentt work. I believe that the grammer size comparison is a much >> more reasonable than spec pages. I'd also say that a reduction in >> grammer size of 30% intuitively sounds about right. >> >> More broadly, I would argue that there is a general acceptance that >> any language beyond Java will not have exposed primitives, arrays or >> checked exceptions, but will add other features like closures. Clearly >> this will result in some aspects where the grammer shrinks and some >> where it grows. >> >> It will be interesting to compare the grammer sizes of other "beyond >> Java" languages such as Groovy and Fantom. Of course grammer still >> only tells a small part of the story... >> >> Stephen >> >> >> On Aug 6, 8:29 pm, Kevin Wright <[email protected]> wrote: >> > ah-hah! >> > >> > both specifications contain a grammar, so I counted em' :) >> > >> > Java desribes it's grammar thusly: >> > >> > "The grammar presented piecemeal in the preceding chapters is much >> > better >> > for exposition, but it is not well suited as a basis for a parser. The >> > grammar presented >> > in this chapter is the basis for the reference implementation. Note that >> it >> > is >> > not an LL(1) grammar, though in many cases it minimizes the necessary >> look >> > ahead." >> > >> > and for Scala, it's simply: >> > >> > "The lexical syntax of Scala is given by the following grammar in EBNF >> > form." >> > >> > Ominous, to be sure, but not exactly objective. The actual sizes, on >> > the >> > other hand... >> > >> > - Java: 368 lines over 12 pages >> > - Scala: 257 lines over 6 pages (Scala uses a smaller font) >> > >> > The Scala spec is 111 lines shorter, a reduction of roughly 30% >> > >> > So I could, in one sense, claim that Scala is 30% simpler than Java. >> > I just don't know if it's a particularly useful sense :) >> > >> > On 6 August 2010 14:20, jitesh dundas <[email protected]> wrote: >> > >> > >> > >> > > ---------- Forwarded message ---------- >> > > From: jitesh dundas <[email protected]> >> > > Date: Fri, 6 Aug 2010 18:44:44 +0530 >> > > Subject: Re: [The Java Posse] Re: Scala and Java spec size >> > > To: Kevin Wright <[email protected]> >> > >> > > I never meant the >> > > size of the specifications,rather the type (& even readibility of the >> > > same.) >> > >> > > A specific fruit is present at east corner of the basket. >> > > The user wants that fruit.The tutorial tells him how that can be >> > > done(where to get this fruit & how) >> > > specs tells everything & not the solution. >> > >> > > regards, >> > > jd >> > >> > > On 8/6/10, Kevin Wright <[email protected]> wrote: >> > > > I'm under no delusion here that the size of the specification >> document >> > > > proves anything. >> > >> > > > However... If one is to OBJECTIVELY decide which of two programming >> > > > languages is inherently more complicated, then something must be >> > > measured. >> > > > Going on a sense of "well, X *feels* more complicated to me" may >> well >> > > have >> > > > personal value, but it carries very little authority when attempting >> to >> > > > persuade others of your viewpoint. >> > >> > > > Measuring spec size is a very flawed methodology here (it's not the >> size >> > > > that counts...), but at least it IS a methodology, and it involves >> > > something >> > > > that can be impartially measured. And, as a methodology, it can be >> > > improved >> > > > upon. >> > >> > > > As previously stated, I believe that measuring the size of some >> formal >> > > > grammar would be far more revealing. >> > > > And accurate :) >> > >> > > > On 6 August 2010 11:38, jitesh dundas <[email protected]> wrote: >> > >> > > >> Very honestly, I found that reading specs was more about >> understanding. >> > > >> Specs are complicated & rather difficult to understand. Moreover, >> > > >> would you like to look into a basket of mixed fruits everywhere >> > > >> when >> > > >> you could look at just a location of the basket. >> > > >> Tutorials help you with the latter & that is what novice people >> want.. >> > > >> Specs reading is for experts & interests.. >> > > >> I am in the second category as reading specs does boost your >> > > efficiency. >> > > >> Fabrizio Sir, you might like adding the last point of reading specs >> in >> > > >> your article (really interesting article on improving efficiency) >> > >> > > >> Regards, >> > > >> Jitesh Dundas >> > >> > > >> On 8/6/10, Fabrizio Giudici <[email protected]> wrote: >> > >> > > >> > -----BEGIN PGP SIGNED MESSAGE----- >> > > >> > Hash: SHA1 >> > >> > > >> > On 8/6/10 11:32 , Kevin Wright wrote: >> > > >> >> First came bikes, they had very few moving parts, and so were >> easy >> > > >> >> to understand Then came the infernal combustion engine, with >> > > >> >> more >> > > >> >> moving parts and harder to understand, but definitely faster >> > > >> >> Then >> > > >> >> came the jet turbine, with just a single moving part, and >> > > >> >> rockets >> > > >> >> with none >> > >> > > >> >> A car is more effective than a bike, but also more complex A >> plane >> > > >> >> is more effective than a car, but also less complex So >> > > >> >> simplicity >> > > >> >> and effectiveness are not correlated here. >> > >> > > >> >> Why is it, then, that cars seen as normal and simple; while jets >> > > >> >> and rockets are perceived as modern and advanced? As many will >> > > >> >> point out, rockets pre-date cars by a long way, the Chinese have >> > > >> >> used them in fireworks for a *long* time. And the concepts >> > > >> >> underlying a turbine are far simpler than those behind a >> > > >> >> four-stroke engine. >> > >> > > >> >> It's a good metaphor, with plenty of scope for extending. >> > > >> >> Consider that modern petrol engines use "injection"... >> > >> > > >> > Right. In fact I question that a car is more effective than a >> bicycle, >> > > >> > or a plane more than a car. It depends on the use. But there's >> another >> > > >> > thing to add: one thing is the implementation complexity (needed >> for >> > > >> > people that make bikes/cars/languages) and the interface >> complexity >> > > >> > (needed or people that use bike/cars/languages). I find quite >> obvious >> > > >> > that driving a car is more complex than riding a bicycle (*). So, >> we >> > > >> > should also put the specs size in this perspective (in other >> words: I >> > > >> > suspect that 99% of the people who program in Java never read the >> > > >> > specs, but a much simpler tutorial). >> > >> > > >> > (*) In general. I drive cars, but I'm not able to ride a bicycle >> :-((( >> > >> > > >> > - -- >> > > >> > Fabrizio Giudici - Java Architect, Project Manager >> > > >> > Tidalwave s.a.s. - "We make Java work. Everywhere." >> > > >> > java.net/blog/fabriziogiudici -www.tidalwave.it/people >> > > >> > [email protected] >> > > >> > -----BEGIN PGP SIGNATURE----- >> > > >> > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) >> > > >> > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ >> > >> > > >> > iEUEARECAAYFAkxb2hgACgkQeDweFqgUGxccfQCaA8FnQlvuVj5LIosLHmbZAUzM >> > > >> > O34Al0605IAMxeyXHEJ2X3VcT1ZfIdg= >> > > >> > =3DuM >> > > >> > -----END PGP SIGNATURE----- >> > >> > > >> > -- >> > > >> > 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]> >> <javaposse%[email protected]<javaposse%[email protected]> >> > >> > > <javaposse%[email protected]<javaposse%[email protected]> >> <javaposse%[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]> >> <javaposse%[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. > > -- 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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
