Fwd: OverlyComplex

Yes.

>
> This is NOT an invitation to a discussion of what is reasonable in an optional
> Complex package.
>
> ...
>> I don't want to be peevish here, but things like:
>> >>Note that there is no attempt to change oddities of Smalltalk syntax.
>> >>E.g.
>> >>  (3 + 1/2i) -->  (0 - 2i)  NOT  (3 + (1/2)i)
>>
>> indicating that Ken don't realizing completely what is Smalltalk.
>

Well, this comment was not really a inspired one, when I saw it I also had hitches to post a question to Igor to understand what was the complaint...

> I indicated that I know the Smalltalk syntax by knowing that
> (3 + 1/2i) --> (0 - 2i)
> and indicating I would _not_ change that.
>
> Smalltalk syntax is certainly confusing to people which come from other
> languages which parse 1/2i as a number, which is why I pointed it out -- for
> people who don't know the Smalltalk parse strategy.
>

Also, Etoys already did somenthing about changing the syntax for mathematical operations http://www.squeakland.org/download/releaseNotes.jsp

> I presume that you _do_ want users to switch to Smalltalk from other
> languages! Yes?

I agree 99.9%.

>If you start adding new rules - it is very likely that you'll make
>things overly complex & redundant.

Is a risk all languages that evolve and attempt to be all encompassing run into, and again I'm with you on attemting to avoid this deadly downward spiral.

>There are many studies showing that smalltalkers are times more
>productive than developers who using
>"industry" programming languages. Do you think they are all genious?

I don't want to rain in your party, but I work with benchmarking of application development for more than ten years and I have to inform you that this statement does not stand.

Perhaps when Smalltalk was near its inception and other platforms were in their infancy this kind of rept could be called by smalltalkers when buiding complex GUI apps, but right now there is no headway for Smalltalk...

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

>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.

HTH

--

Cesar Rabak

As I already pointed out, this kind of "anedoctal evidence" is fallacious due the cherry picking nature, and the impossibility of comparing the outcomes in terms of all factors (including obiously the processes :-).

>
> Non-commercial: Ruby On Rails Tomcat Apache web server
> FreeBSD/NetBSD/OpenBSD Squeak Pharo
>
> Commercial: Amazon Facebook Google 37signals.com
>
> Failed ones, well a lot more than can be described, although they are
> almost never publicly mentioned.

Yes, this is true state of affairs on our industry right now, but you can get some aggregate figures if you have access to reports like the Standish Chaos Report (http://www.standishgroup.com/), of which certain earlier versions exist in the web (http://www.cs.nmt.edu/~cs328/reading/Standish.pdf or http://www.projectsmart.co.uk/docs/chaos-report.pdf).

> Lots of project from Consulting
> houses using *enterprise* products as ERP and processes like RUP (and
> others even more "proved"), with ISO certifications on processes have
> failed espectacularly.

Yes, and when you do a Independent Validation and Verification you discover that a lot of root causes stem from the certified professionals tossing the procedures and processes!!

> Here in my work, at least 3 projects done by
> external consulting firms have failed and took a lot more time and
> resources than the initially estimated.

I've seen in my practice a large number of failed and a similar number of projects that succeeded (meaning in time, in budget and with overall functionality delivered near 100% of required and withing agreed quality level).

So the same way we don't want a failure of someone could attributed (solely) to the choice of Smalltalk (and later Pharo!), we should be more rigorous on the analysis of those 'failures'.

> Also the poor souls that they
> bring to work in the project keep changing every 2 or 3 month (burned
> by the pressure and the impossible deadlines), and we have had 3
> managers for one of these projects. So, yes, I have a very bad
> impression.  Maybe it is just bad luck. Who knows? My friends on other
> places tell similar stories.

Yes, and as soon you start of thinking about it, you'll see that the 'pressure' is 'accepted' tossing all the Body of Knowledge on how to do such things and then .hit happens...

>
> So, as you say, nothing can be take for granted on a project both
> *managed* and *unmanaged* projects
> can fail, but the fact that a lot of unmanaged projects succeed, makes
> me wonder of the usefulness of the enterprise *ways* of work.

No. What you've seen is that the declaration of success for a 'unmanaged' project (normally a successful Open Source one) is different from a 'managed' (more often than not a enterprise/commercial venture).

This another fallacy of comparing apples to oranges.

>
> But, lets no start a flame here. I respect your opinion about
> *managed* projects and have my opinion about *unmanaged*
> projects. The enterprise world will never change.
>

No my intent.  What I would like to bring to the community is this: if the goal of Pharo project is bring it (Smalltalk) to the enterprise, we must have a good understanding of what it means, and then understand what it takes to get there.

Hint: just saying Pharo [Smalltalk] is more productive will not cut!

> >
> > 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.
> >
>
> I am 100% agree with you, sadly that it what the "pointed haired
> bosses" want to save its asses in the case a project fails. That way
> they at least can say that it was not because of a bad technology
> election. How the say goes? Nobody has been fired for choosing IBM?
> Now you have ISO900*, RUSP, SAP, oracle, etc. :)

Most of what we see as "...saving their asses" is in fact a managerial reaction to our engineering community incapacity to sustain its promises and even going to the tenth year of the XXI century we still have the same reports of overrun projects, etc.

>
> >> 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).
>
> But hey, that is not a goal of the smalltalk community, to appeal and
> to be the first option for a new project as the java guys, for
> example, want.

Except if we want to compete in the single to small team space, if we stay in the sideline on this more and more our 'opportunities' will be have a powerful environment that should to .Net, connect to JNI, etc.

> We know that there are right tools for each problem in
> hand. The Pharo project has a goal of be a platform for enterprise
> apps, but that is different to want to be *the* platform for
> enterprise apps.

Yes I agree.

> Take the case of ruby on rails (and dynamic languages
> too), 5 years ago it was crazy to even propose them on a meeting for a
> new project. Now even SUN is sponsoring them on their vm. Times
> changes, and with time (and even more with the apropriate marketing)
> the technologies will reach the key people on enterprises and will be
> an option, even if no metric can be shown for them.

You can bet your favorite beer that Sun has enough data to back its offerings [and I don't want to recurse in a second discussion about the validity of them, which see, I'm not waiving]!

>
> >
> >>
> >> > 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 div iding 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.
> >
> Yes, I know that, but my point is: What t hat does show about a
> project?

It shows that for a lot of projects you can expect that productivity (rate of deliver) on the average (with some extremes captured in some tables as well) so you can do better estimates, which are root cause of a lot of, so declared, failure due overrun [w/proportional increase in cost].

>
> A closure in Smalltalk it is more powerfull and usefull that 100 lines
> of java code or 1000 lines of java code. But a the very same code
> could be produced in java by using the apropriate library and reduce
> the line count from 100 to 1. What does that demonstrate?  That java
> is on par with smalltalk?

Yes. If for getting at the business functionality a library call can avoid the writting of the code, you're done as we do in OPP reusing code from inherithed methods (of course it happens in Java which is OO, this is an example).

As powerful as closures are they'll be small part of an average commercial application, so quickly the advantage of them will be reduced in the averages.

> That java it is not just 10 times more
> productive than c++ but but 1000 times better. I am exaggerating, I
> know that the numbers are not used that way, but you get my point:
> although the metrics are promoted as more enterprisey, they aren't.
> In a certain leve, they are arbitrary.

I cannot grok your assertion above, from the number in the tables I cited you can see that C++ and Java are more or less similar.  These metrics are for "promotion", they were created to help companies to make decisions about these technologies based on real data.  Look that the companies that produce those tables are not connected with the providers of the technologies involved.

HTH

--

Cesar Rabak