---------- Forwarded message ---------- From: jitesh dundas <jbdun...@gmail.com> Date: Fri, 6 Aug 2010 18:44:44 +0530 Subject: Re: [The Java Posse] Re: Scala and Java spec size To: Kevin Wright <kev.lee.wri...@gmail.com>
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 <kev.lee.wri...@gmail.com> 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 <jbdun...@gmail.com> 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 <fabrizio.giud...@tidalwave.it> 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 >> > fabrizio.giud...@tidalwave.it >> > -----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 javapo...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> >> . >> > For more options, visit this group at >> > http://groups.google.com/group/javaposse?hl=en. >> > >> > >> > > > > -- > Kevin Wright > > mail/google talk: kev.lee.wri...@gmail.com > wave: kev.lee.wri...@googlewave.com > 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 javapo...@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.
