Thank you , Andrew, for that back-story!
I really liked OS/2 and was extremely reluctant to give it up; it had
a really good design.
On Sat, Oct 28, 2017 at 10:59 AM, Andrew Glynn <aglyn...@gmail.com
<mailto:aglyn...@gmail.com>> wrote:
Your history is accurate, but there’s a few things I’d like to
add, due to having been employed by IBM at exactly that period
working specifically on VisualAge, not only for Smalltalk, but for
Java, C++ and Cobol as well. (my NDA’s finally having expired
also helps 😉). It’s not a correction or contradiction, but a
complement to your description, providing a relevant but different
perspective.
IBM /did/ tell some// of their customers to move to Java, but that
was partly based on the existence of VisualAge for Java, which in
some ways went beyond VA Smalltalk, in others not as far, but did
make migration to Java easier, and in some cases possible at all.
Its replacement, Eclipse, simply doesn’t. And it could do so,
because as with all VisualAge products, it was written in
Smalltalk. One of the things that annoys me about the whole thing
the most is that the biggest complaint, which was a partial but
significant reason it wasn’t more popular, was from developers who
‘couldn’t see their files’, i.e. couldn’t edit them in vi(le) and
build on the command line. I heard that complaint on a project
using both the Java and C++ versions so many times I finally
responded “nobody gives a shit about your f*cking files”, in the
middle of the office at Pratt & Whitney Aerospace, lol.
Since VA for Java (and VA C++) are now abandonware, it’s an
example of what I meant by owning a market, failing to promote it,
and thereby destroying it, and also the reason I referred to IBM
specifically as being ‘very good at it'
I was involved in writing a major application in both Java and C++
using CORBA in 2000-2002, and on that we also used both VA C++ and
VA Java. Otherwise, quite honestly, we may not have finished it
despite having some brilliant people on the team, since doing
CORBA manually, especially with object trees that use C++ multiple
inheritance, can be near impossible to get working reliably.
Unfortunately, due to being abandoned, the core of the app is no
longer even buildable with current tools. If you look at the
binary jars in the latest release (2016) the dates on them are
still mid-2002. The most surprising thing to me is that they
still run at all, particularly with Java 8 on current platforms
(mainly Solaris 11 and Windows 10), considering they were written
and built on Java 1.3.1, and although they targeted Windows and
Solaris/AIX, were in fact written on OS/2 v. 4, because Solaris
didn’t run at the time on any laptop, and Windows 2000 /loaded/ on
a high spec laptop for the time but couldn’t really be judged to
be /running/, i.e. it loaded and proceeded to thrash to the degree
that nothing further got accomplished.
VA Smalltalk as it’s publicly available (at the not insignificant
cost of ~$8500+ per license), is written on a base IBM Smalltalk
that’s ~26 years old. Instantiations has improved some things,
but the core is vastly out of date. Meanwhile, IBM themselves have
a fully current version (the last version I saw, when visiting a
former colleague at the lab, was released early last year, but is
only available internally. This wasn’t one of the four I referred
to in my other post, but nearly qualifies as ‘publicly
unavailable’, since the available version is not nearly the same.
VA is also very out of date in comparison with VW, Pharo, F-Script
and Squeak, not only in comparison with the internal version. In
particular the UI doesn’t fully incorporate the improvements made
(largely via the Announcer) in Morphic and the other current
Smalltalk GUI’s. Like Swing and SWT, part of those improvements
are there, but that in many ways only makes things worse. That
WindowBuilder (available free for Java in Eclipse, but not for
free in VA Smalltalk) is in fact a simple port of the original
Smalltalk version is demonstration enough that the UI is not
significantly different than the UI in Eclipse itself, or in
Swing, since Swing is also supported by WindowBuilder.
As an example of the remaining problems, I recently reverse
engineered a complex legacy database via the Eclipse Dali JPA
tools in order to make it available to BIRT / Talend for
reporting. On an i7 with the DB on an SSD, it took over 950 CPU
hours to complete. As of today, it has been in process of exiting
for another 140 CPU hours, trying to catch up with the events
triggered by Dali.
Perhaps that helps understand why I’m not thrilled with even some
of the better libraries in many other environments.
Outside Smalltalk and languages with IDE’s written in it. OS/2
is a great example of owning a market, then destroying it by not
promoting it. OS/2 never owned the mainstream market of course,
but what it did largely own was the smaller but sometimes crucial
market for PC based systems that could run complex software
reliably. Despite having ‘killed’ OS/2 13 years ago, version 5.0
came out in June, released by a “company” of former IBM people
financed by IBM, whose company name means “new box”.
The reason IBM can’t completely kill it is that companies who
can’t move software off it, because every attempt to do so (to
either Windows Server or different forms of *nix) has failed, in
some cases over a dozen times, include such small entities as
Boeing, MIT, NASA, the US government, including all four branches
of the military, all of the world’s airlines, GE, Rolls Royce,
Pratt & Whitney, GM, Siemens, AT&T, and Citibank, just to name a
few I know of (and none are exactly publicizing the fact). Despite
the existence, today, of both Linux and Solaris on x86, and the
improvements between Windows NT in the 1990’s and Windows Server
today, institutions with fairly capable developers, such as MIT
and Bell Labs, just to name two, can’t port software they
simultaneously can’t be without, to any of those platforms. There
/is/ a specific technology in OS/2 not available elsewhere that is
the main culprit, the Distributed System Object Model. Somewhat
ironically though, one of the main uses of SOM/DSOM is to provide
the type of live object manipulation and debugging to the core
environment (and in a distributed manner) common in dialects of
Smalltalk but virtually unknown otherwise.
The person I learned Java RMI, JINI and J2EE architecture from
was, by happenstance, the same person who architected OS/2. A
somewhat humorous story is that IBM dropped out of a project begun
with Sun in the late 1990’s to write a pure JavaOS. IBM’s reason
for dropping out was embarrassment at the fact that pure Java apps
ran faster on OS/2 than on the pure JavaOS. Sun couldn’t at the
time afford to complete it on their own so it disappeared, as
unreleased products do, without even the marginal trace of
existing on abandonware sites. That person was also,
unsurprisingly, one of the key developers of IBM Smalltalk.
I’m not claiming that IBM or anyone else does such things in a
completely aware way. Rather, the fact that efficient environments
are difficult to build without significant time and resources
(both are necessary because no matter how many resources are
available, rushing the development will result in mistakes that
have to be fixed later, giving the environment an unstable base to
build on), combined with the advantage industry inefficiencies
provide to the companies /with/ those resources, makes the
situation relatively easy to reinforce /without /really needing to
admit what you’re doing, particularly to yourself.
Andrew
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>
for Windows 10
*From: *jtuc...@objektfabrik.de <mailto:jtuc...@objektfabrik.de>
*Sent: *Monday, October 23, 2017 3:32 AM
*To: *Any question about pharo is welcome
<mailto:pharo-users@lists.pharo.org>
*Subject: *Re: [Pharo-users] perspective request for those earning
a living fromSmalltalk
Petr,
I've been working as a Consultant for many big corporations
(mainly in
VA Smalltalk) since 1996. The situation you describe is very well
known
to me. But in my opinion there is no technical reason for this.
It's a
managerial problem. Ever since IBM went out to their customers and
told
them to move to Java for the better ini the mid-90ies, managers
wanted
the Smalltalk projects to go away as fast as possible. Nobody
asked why
IBM was still happily using VisualAge Smalltalk internally at that
time
frame....
So the Smalltalk projects were declared legacy by Management.
Replacement projects were started with big efforts and optimism. Some
went well, some somewhat came to fly in a bit more than double the
time
and much more times the costthan planned, some failed miserably. One
thing was in common to the replacement projects all over the
place: they
took much longer, turned out to be much mor complicated and took a
lot
more manpower than anybody had ever imagined.
So two important things happened:
1) People were told the old Smalltalk stuff would be gone soon, so if
you wanted to be a valued and appreciated staff member, you better
stay
away from these projects
2) The people who knew the business and technical side of the
existing
projects were moved to the new projects. Some liked it (because of 1)
some were frustrated (because they knew / feared the new project was
going to be a death march)
Over the first 2 years or so, nobody realized how bad the situation
really was. It was easy to postpone user requirements to the new
project, accumulate more and more manpower in the new project and
still
keep up green flags everywhere.
...until yellow was the new green and users/stakeholders wanted
the new
features NOW - and not one day when the replacement project would
become
real.
So the remaining manpower in the old project (not the ones with
lots of
experience and knowledge) had to extend the old system, integrate it
with the new system (thereby implementing all the stuff that IBM once
told their management would never be possible in Smalltalk) and
keep it
up and ranning year after year. Nobody ever said Thank You or would
appreciate the work they did. Because that was old stuff anyways
and was
already irrelevant.
Some of these old systems still exist today, serving users every
single
day, while some of the new systems never appeared. No manpower was
ever
added to these projects, and never would anybody ever say: okay,
guys,
you won. They still work on legacy code and try to do their best to
fulfill user requirements. While on other projects that never see the
light of day, people get appreciation, are allowed to work with new
technologies and do cool stuff. Nobody ever asked the Smalltalkers
whether they could do that as well, because "if you want to do
web, you
need to do Java". IBM said so, you know (and many other
consultants as
well).
So this is why new people try to stay away from these old
projects. This
is why the remaining staff is frustrated and this is why nobody
allows
them to do the cool things that Smalltalk can do as well as the
others.
They are just required to fix bugs, add new features in the old
GUIs and
else keep silent. Some of them were trying to fight this and tried to
prove Smalltalk's strengths, but back then nobody would listen.
One day
they gave up.
Management still frustrates people every. single. day.
Just my opinion
Joachim
Am 22.10.17 um 18:56 schrieb Petr Fischer:
> Here. (But from one point of view, it's a litte misery, 10-20
year old code sometimes, a mess, old VAST, absolutely no interest
from young colleagues with no experience to willingly learn
something about Smalltalk etc etc.).
>
> If I bring up enough arguments, we will use Gemstone+Pharo tools
in the future, which is a dream for me... but, we will see...
>
> pf
>
>> At https://news.ycombinator.com/item?id=15523807
<https://news.ycombinator.com/item?id=15523807>
>> the question is asked... "Does anyone on here program in Smalltalk
>> professionally? Not to get off topic, but I'm curious and would
like to
>> know how it stacks up compared to what they did previously? "
>>
>> If you've earning a living from programming Smalltalk, please
drop a
>> comment there.
>>
>> cheers -ben
>
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel
mailto:jtuc...@objektfabrik.de <mailto:jtuc...@objektfabrik.de>
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
<http://joachimtuchel.wordpress.com>
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
