Am 10.01.20 um 15:42 schrieb horrido:

> 
>> So let's stop trying to convince people with things that mattered some 
>> 20 years ago. Even the function point thingie we keep carrying in front 
>> of our bellies (Capers-Jones was it?) is a lie when you want to build an 
>> application for today's markets.
> 
> I disagree that it's a lie. The study is based on thousands of projects and
> millions of lines of code over a period of several decades, including recent

Well, naming it a "lie" is perhaps too strong - but Joachim (did you
have a bad Smalltalk day ?????) statement is from my point of view
correct - this talking about function point and productivity is an
academic point.

If I am a Java developer and my productivity is around 10% compared to
Smalltalk developer it is still useful to use Java - because for my
problem there might exists already dozen of libraries and solutions.

Using Smalltalk today is matter of personal taste and love - like many
other developers in other languages.

Joachim mentioned the critical points and for me perhaps the following
statements are true:

* Smalltalk development over the last decade ran in circles

and due to that

* Smalltalk is not solving the biggest problems any more

So many time has been wasted to make a Smalltalk dialect running in a
browser.

I would use (my loved) Smalltalk today only, if

* I have an application, which was written in Smalltalk (and I have one)

* Smalltalk is superior to other solutions in a specific topic (and with
Gemstone I have one topic)

When I would start from scratch ... build a headless Smalltalk, put lots
of good communication libraries into it, spread it over Windows, Mac and
Linux, make it open source and put some XML and JSON and solve printing,
multithreading/multiprocessing (framework) runtime AND (!) debugging,
scripting, interconnections with other languages. Try adding a modelling
and source code generator. Build the whole stuff with concurrency in
mind - offer specific data structure to help you here. Look for suitable
persistency options.

Go back to the time, where Smalltalk source code was hold in a
repository to manually work with it and and not getting software via
Github with some broken relationships between packages and nobody knows why.

Use the browser (with Javascript) as the main UI and build a superior
interface in Javascript to the backend Smalltalk. Use the Electron
framework and build some specific support for Smalltalk into that.

But even with that in mind you will not catch the Javascript developers
(because they are on that way already and they do not need Smalltalk),
but you may survive as a Smalltalk developer.

Spread the word around, that multi-language development is a MUST and
one should support it.

So, to summarize - this is my personal view of Smalltalk today - since
1986, where I first met Georg Heeg on a Atari fair in Düsseldorf seeing
the first Smalltalk system in my life.

Marten




-- 
Marten Feldtmann

Reply via email to