smalltalk vs visual basic

[hidden email] (Alan Wostenberg) writes:

As I am currently trying to re-write and debug a major project that
started off as a large number of 'throw-away utilities' that sort of
grew together over the years (not written by me!), I constantly campaign
against the idea of the VB way of working.  I strongly believe that
*every* project or utility should be written as if it were going to
be re-used in some future code.  I have a strong aversion to the use of
scripting languages unless really necessary.

... just my two cents

Steve Zara

[hidden email] (A SERFer) wrote in message news:<[hidden email]>...
> [hidden email] (Alan Wostenberg) writes:
>

Steve I agree! A million VB guys ever rewriting their throw-away
utilities is a terrible waste of human time and talent. Smalltalk
hasn't won the conservative IT VB Script guys here because they do not
accept the promise of reuse in class heiarchies or patterns even when
phrased as starkly as "You can have 4 use cases in VB or 20 in
Smalltalk for the same manhours in this project"

I wonder of Extreme Programming would be better bait than "serious OO"
for the guys who buy books like "Weekend crash course in VB"?

-Alan Wostenberg

[hidden email] (Alan Wostenberg) writes:

I think the waste is also a result of bad management, who repeatedly
ask for quick fixes and short-term solutions.  Any talk of restructuring
or reorganising code to allow future re-use is often considered
to be 'good in principle, but outside of the budget for development',
and so the VB/PERL script mentality survives.

I have real experience of this, although these days I have far more
sensible bosses.

Steve Zara

Alan Wostenberg wrote:
[snip]

>
> Steve I agree! A million VB guys ever rewriting their throw-away
> utilities is a terrible waste of human time and talent. Smalltalk
> hasn't won the conservative IT VB Script guys here because they do not
> accept the promise of reuse in class heiarchies or patterns even when
> phrased as starkly as "You can have 4 use cases in VB or 20 in
> Smalltalk for the same manhours in this project"

Alan and Steve,

Yes, I agree with you both.  One of the side effects, IMO, of, first,
the workstation revolution in computing and, later, the dot-com
revolution was general software sloppiness encroaching back into
mainstream data processing.  The apparent rapidity with which, first,
desktop and, then, Web applications were turned out ("Internet time")
belied their poor design and their lack of maintainability.  Of
course,
in some of those cases -- not that many -- maintainability wasn't
a requirement, because all were considered throwaway.  But,
eventually,
there are stable applications required and, eventually, even for the
"quick and dirty" applications, without sharing of design and base
code,
these will be much more expensive for customers, whether than expense
is in the form of taking too long to develop or having problems that
the customer has to react to.

I had experiences in 1996 of a Web shop having no documentation, no
configuration management, no disaster recovery plans, and no objective
means to charge customers for their work.

Now, it is true that, to be useful, it is necessary these days for
developers to work directly with end users and to do without written
requirements or their equivalent.  Even in the early 1990s, it was
possible for a developer to write down what the client thought they
wanted and to ask them to read and comment on it.  Towards the late
1990s the pace became so fast that even that was hard to do and the
readings were often superficial and one always found "new"
requirements
or misstatements of requirements during system testing.

There are three problems with this.

First, there is an expectation on the part of some clients that one
ought to be able to produce good systems in this environment and that
developers -- and, often, testers -- who can't simply don't know what
they are doing.

Second, there are some employees who are responsible for managing
vendors and developing requirements who take advantage of the fact
that the developer or tester is the last in the chain before the
product is released or is near the end of that chain.  Basically, the
repercussions of poor or changing requirements are taken out on
developers and testers.  It is very difficult to demonstrate this to
management because there is no paper trail of requirements.  This
tends to create an atmosphere where developers do "defensive
development", documenting everything for themselves in the case that
the business association turns litigigous.

Third, there is no lasting statement of what a system can do or
cannot do.  Thus, extensions or adaptations of existing systems are
based upon loose analogies of function, usually on the part of
managers, rather than actual technical capabilities.  Some of the
adaptations and extensions, therefore, are either doomed from the
start or doomed to exceed the schedule allocated.


>
> I wonder of Extreme Programming would be better bait than "serious OO"
> for the guys who buy books like "Weekend crash course in VB"?

I don't know.  I know there are a lot of features of Extreme
Programming which are attractive, such as having a client rep who
can make decisions locked down as part of the team.

I do know that one of the reasons I've decided to go back out on
the road doing Smalltalk full time is that I have actually been
zinged in an appraisal literally for "doing too good a job".
My current workplace is an environment with a high turnover and
no documentation and little in the form of requirements.  Of course,
their applications are not technically challenging but they do
generally attempt systems which are chronically late and far
more expensive to develop and maintain than expected.  There is
a lot of the "if we can just get through the next month it'll
be okay" attitude.  Seat of the pants changes are made creating,
down the road, even bigger problems.

I don't know the answer to this.  It seems that data processing
and information systems management have forgotten a lot of the
very painful lessons learned from the late 1960s through late
1970s.

 --Jan


[snip]

--
-----------------------------------------------------------------------
 Jan Theodore Galkowski        °o°            [hidden email]
 http://www.scguild.com/usr/1707I.html              [hidden email]
***********************************************************************
             "Smalltalk?  Yes, it's really that slick."
-----------------------------------------------------------------------
    Check out http://st-www.cs.uiuc.edu/users/johnson/smalltalk/,
              http://www.object-arts.com/DolphinWhitePaper.htm
              http://www.dnsmith.com/SmallFAQ/
***********************************************************************