-------- Prvotno sporo?ilo --------
Datum: Wed, 1 Feb 2012 11:54:22 -0500
Od: Paul Baumann <paul.baumann at theice.com>
Peter's point that "that there is [not] any inherent advantage in using
Smalltalk development over any other language" is true by the criteria
that he defined to judged it.
It is funny to see "Smalltalk efficiency" is being framed by a standard
of high resource requirements, and that Java having twice as many
function points and four times as many cases for equivalent architecture
and design was somehow a less relevant measure. One might observe that
having such a wide variety of similar tools for a language like Java can
indicate a limitation of reuse and extension. Smalltalk syntax is less
restrictive in how a framework can be reused and extended; that is a
better criteria to judge efficiency of the language.
"Smalltalk" is syntax and a basic class library; it is not defined by
the availability of a vendor features. IBM failures are more relevant
than a Smalltalk failure. Large IBM projects of that era failed from
Analysis Paralysis. A common goal was compliance with the latest buzz
that IBM sold. There were a multitude of management styles in vogue at
that time and all could be characterized as top-down management. The
"60% heads down developers" were given static designs that had a high
and continuous cycle of costs as theory met reality. Large amounts of
dumb and redundant code would be generated early. Code inertia and
resistance to change would preclude opportunity that is discovered later
(like the ability to eliminate thousands of classes with a single
reusable type). The result is as predictable as any top-down management
style. All design problems were prevented from being fixed until they
caused serious and recognizable problems. The management styles of the
time promised theoretical efficiencies of scale that had been determined
from earlier failures with less malleable languages than Smalltalk.
Effectiveness of these feudalistic management styles had yet to be
recognized as Dark Ages in the context of software development.
Smalltalk does well when individual developers are given opportunity and
responsibility, and to the extent that implementation is not restricted.
Success with Smalltalk is about rewarding independent action that
furthers an objective goal. Management of a Smalltalk project is about
providing healthy incentives while minimizing barriers to change.
Top-down management (sold by IBM) was more to blame than "Smalltalk".
Smalltalk is successfully used for large mission-critical projects that
affect global markets. It doesn't take even a dozen Smalltalk developers
to do that. Smalltalk can be more efficient than other languages when a
compatible management style is used. Smalltalk struggled through the
Dark Ages of project management while more popular languages were
developed outside of those conditions. Smalltalk is a victim of timing,
management, and vision. The more popular languages provide opportunity
of market more so than opportunity of syntax. Languages have evolved to
be increasingly more malleable like Smalltalk; that is recognition of an
advantage that Smalltalk has always had rather than proof that Smalltalk
never was more efficient.
Some people value opportunity of syntax that Smalltalk offers and have
the vision to leverage that to a competitive advantage. Other people
recognize that the availability of resources and frameworks can also be
leveraged as an advantage over Smalltalk. It is possible to find success
or failure either way.
Paul Baumann
*From:*vwnc-bounces at cs.uiuc.edu [mailto:vwnc-bounces at cs.uiuc.edu] *On
Behalf Of *James Robertson
*Sent:* Tuesday, January 31, 2012 14:10
*To:* VWNC NC
*Subject:* Re: [vwnc] [Pharo-project] Smalltalk for small projects only?
Ironically, I worked on a telecom project <in that domain> over a decade
ago, with more people involved. Still in production, too.
On Jan 31, 2012, at 8:54 AM, Peter Hunsberger wrote:
With all due respect to the experience of everyone here, people really
need to give up on this naive belief that Smalltalk development is any
more efficient than development in any other language. The simple fact
is that within the Smalltalk community a large portion of the developers
have been using the tools for a long time and are very good at using
them. Throw them at another environment and they are not as efficient.
However, if you take new developers and throw them at a Smalltalk
project it takes longer to get them up to speed than throwing them at a
Java project simply because of the fact that Smalltalk is not
as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so
I've seen both sides of this issue for a long time, so let me related
some anecdotal experience:
I'm currently working on a Smalltalk project that has about about 50 man
years of effort in it over 10 years. Prior to this I worked on a Java
and XSLt project that had about the same effort over the same period.
Both have web based GUI's with a fair amount of JavaScript and the
usual HTML crud and use a relational DB back end (SQL server and Oracle
respectively). The Smalltalk project has had a mix of very experienced
Smalltalk developers and inexperienced ones. The Java project was
mainly junior and intermediate experience devs. I'd say the overall
architecture and design was about equivalent; very different, but
equally well done and comprehensive. The projects are very similar in
concept and execution. The Java project had about twice as many
function points (some pretty major) implemented and four times as many
use cases supported at the point I switched to the Smalltalk project.
For the most part this has little to do with the language itself.
Rather, it is mainly, the supporting infrastructure that one is able to
draw on in Java projects and this includes Eclipse, Git, etc. Open
Source projects also played a big part of this, in the Java world one
can pull in large chunks of functionality at very low cost (eg. XSLt 2.0
processors and pipelines, Spring, Hadoop, you name it) that are just not
quite matched in the Smalltalk world. You can often get close, but it
seems that there is always something missing, if only because the teams
supporting the Smalltalk projects are often much smaller and just can't
quite keep up with the every changing specs and requirements.
Bottom line, don't kid yourself that there is any inherent advantage in
using Smalltalk development over any other language. It is faster for
experienced devs in small projects, but if you've got to pull a team
together from scratch for some medium to large complexity enterprise
scale project it is probably not going to fair as well.
Now onto the main question posed here....
I have also worked on a successful 200 man year project (C and C++ in
this case), which broke down to a little less than 100 people over a
little more than 2 years. This was in the telecom world and involved
many main frame billing interfaces and switching equipment interfaces,
all very mission critical. In this case about 60% of the team was heads
down developers. The rest of it was dedicated testers, tech writers,
business analysts, project managers and managers. Here again the
supporting infrastructure played an important role. Business analysts
could write up use cases that got stored in a repository (a proprietary
system) that could be used to generate test case stubs and documentation
stubs. The development team tracked progress and bug reports in the
same repository and source code version control was tied to the
repository. End user documentation was stored in the repository and
version controlled. It was simple to know what was going on anywhere in
the project and to know where the problems were and what code did what
and to see the entire life cycle of any portion of the code base from
customer requirement to final deliverable. I know of no
support infrastructure that even comes close in the Smalltalk world and
would consider it madness to even consider taking on such a project
using Smalltalk.
Peter Hunsberger
On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont
<laurent.laffont at gmail.com <mailto:laurent.laffont at gmail.com>> wrote:
200 developers on a project ? Scaring ..... They should use another
technology than Java to go under 50 developers. They will save a lot of
money :)
Laurent
2012/1/28 Janko Miv?ek <janko.mivsek at eranova.si
<mailto:janko.mivsek at eranova.si>>
Hi guys,
Ralph Johnson in his InfoQ interview made an interesting observation:
2:55 minute: "Smalltalk made an fundamental error ... image ... you can
build something with 4-5 people what 50 people can build in Java, but if
you take 200 people in Java ... it is really designed for small systems
... "
Are we because of the image really destined for relatively small
projects and small systems (of Java 50 people project size)?
Are we really not able to scale to bigger projects/systems because of that?
Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
[1] http://www.infoq.com/interviews/johnson-armstrong-oop
Best regards
Janko
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Pripet del sporo?ila
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120202/9e428e2d/attachment.ksh>