> El mié, 19-08-2009 a las 00:04 -0300, [email protected] escribió: Miguel,
> > Em 18/08/2009 22:25, Igor Stasenko < [email protected] > escreveu: > > > > >> Em 18/08/2009 20:23, Ken.Dickey < [email protected] > > > escreveu: > > >> [snipped] [snipped] > > Maybe you can tell us how much time would you estimate for a java (or > better yet, c++) version of Seaside or maybe of GLORP, that were made > for a significant part of their initial life for a single person. > This kind of repts have been used for year to attempt to prove a lot of non provable things: a similar argument was used to attempt to "demonstrate" that Linus Torvalds could have written the kernel for Linux [which applies for the requirement of yours "...significant part of their initial life for a single person."] Other languages/technologies all have histories, but see: this in logic is considered the fallacy of cherry picking, where an interesting and sufficiently high profile case can be shown off (a famous one is the developmet of the Viaweb site [http://en.wikipedia.org/wiki/Viaweb]). The issue about productivity and discussions about differences thereof due languages is the _average_ productivity for the mass of active users. > I *am* times more productive in Smalltalk than in Java or PHP or C, even > if I can not show an *enterprise* benchmark the kind of ones that Garner > and friends so happily like to show in magazines and flyers. > I don't deny you can be, as I am. I can tell why it is in my case. If you and we cannot show hard data on an *enterprise* benchmark (I represent in this country one of the friends and used to work to the mentioned) you'll a *lot* of difficulty on convincing companies to embrace this technology. > So, a lot of people here can attest that indeed it is more productive to > work in Smalltalk taht in other languages, and that is the reason why > this *myth* persist. Maybe subjective, maybe not. We know that when we > work in Smalltalk and think how much more time/work/effort/boredom will > take to do the same on other languages. > My contribution to this debate is that if we don't bring demonstrable data to become facts, we will continue to be heard as some kind of hacker of a wacky or semi-defunct language (depending upon the thoughts of the listener). > > > Today, due the minute participation of Smalltalk in world production > > of new funcionality, you cannot find in any commercial or publicly > > available database on productivity (like ISBSG http://www.isbsg.org/) > > it mentioned by itself, but only lumped as OTHER 4GL). > > > > For a more or less uptodate and public reference, give a look at > > http://www.qsm.com/?q=resources/function-point-languages-table/index.html > > > > > > WTF. From the page: > > What is a gearing factor? The gearing factor is simply the average > number of Source Lines of Code (SLOC) per function point in the > completed project. It is calculated by dividing the final code count > for a completed project by the final function point count. SLOC counts > are logical, not physical line counts. > > Nuts, is this how the *enterprise* projects are evaluated? > That is absolute non-sense. What is the difference between logical and > physical line counts? The main point of the text you read is that the evaluations should be done asap in IFPUG Funtion Points or similar metric. The proviso thy put there is to allow different coding practices to be accomodated without inflating the outcomes. A lot of languages allow more than a logical statement to put in a single line, or for aesthetical reasons break a single statement in more than a single line. > > > >Or maybe there is something which > > >increasing their productivity? > > > > As you make the rept "are they all genious", I counter with: would you > > accept/believe that all managers who're responsible for development > > worldwide are "pointed haired bosses" which cannot discover if such a > > thing as 'silver bullet' existed? > > > > Most productivity is obtained due discipline, processes, trained and > > motivated people, and one of the last factors is programming language > > syntax. Programming language technology obviously has a role, > > otherwise it would be indifferent programming in (say) Smalltalk, > > versus (say) assembly. > > More non-sense, the process isn't a factor. The very same person can do > sometimes the same work in a week or in a night with coffee. A single *task* yes! A complete project like the Pharo revamp of a renewed Squeak *not*! That's where processes come into play and modify the outcomes. > WE ARE NOT machines producing nails in a predictable, constant over > time, unaffected by personal affairs. This factory model doesn't work > and has never worked. And the ever increasing complexity and irreal > methods created to try to measure people are a sad result of this way of > thinking. Agreed. It is not for this that development processes are for. It would become out topic here so I refrain of further discussion. > I believe that the work we do is more akin to the artistic disciplines. This kind of thinking is an attempt to evade the necessary debate. Most of software development is not of pure conception but turning into some usable artifact the conception. I would quote T.A.Edison on his saying about "1% inspiration and 99% transpiration.", processes is to make us more productive in 99% part of the job! > Will you try to measure the work done by a musician? or a painter? When [s]he is composing, probably not (but: get a look at the Movie and Advertising industries), when they're playing or the painter is applying the picture in church's roof, *yes*. > That is why the pointed haired bosses depiction and Dilbert cartoons are > so popular. I agree they are popular, but remember that geeks and nerd depictions are also popular! Regards, -- Cesar Rabak _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
