Re: Digital Twin applied to Software

Cesar Rabak wrote:
> I'd like to say that I agree with Andre's comments and say that we 
> cannot overemphasize last paragraph of Dec, 4h (2 h ago from this 
> reply) message:
>
> « I should maybe note that C++20 is lightyears ahead of older 
> standards and much of what made C++ a PITA back in the day is no 
> longer relevant today. »
Perfect example.
Smalltalk discovers, innovates and explores.
Good features are ported to C++.
This is happening naturally. Great. BUT IT TOOK 50 YEARS.
If Digital-TwinS is practised consciously and systematically, Smalltalk 
and C++ would be more in sync.
Lags could be limited to 1-3 years by design.
Knowledge transfers can and should work both ways.
All the failings of Smalltalk can be covered by C++.
All the failings of C++ can be covered by Smalltalk.
The cross checking during development will enhance both productivity and 
quality.
The redundancy of twins is also advantageous as proven in all of 
engineering.

Imagine where Smalltalk would be today if it received just one percent 
of the money thrown at C/C++. Software innovations would abound.
Digital-TwinS would mandate 10, 20 up to 50% of software resources be 
spent on Smalltalk.
St and Cpp teams would be working together instead of having current wars.
I see Digital-TwinS happening at every level and field:
St CAD with Cpp CAD    computer aided design
St XR with Cpp XR    virtual, augmented, mixed reality
St Simulation with Cpp Simulation
St Finance with Cpp Finance
Artificial Intelligence, Autonomous Vehicles, Avionics, IoT, etc.
Every area innovating faster, producing fast and reliable software faster.

I am coining Digital-TwinS as follows:
Digital Twin means one physical system with a software twin
Digital-TwinS mean one software with another software twins
Digital-TwinS could also mean one software, another software and one 
physical system triplet.

Let's INNOVATE.

All the best,
Aik-Siong Koh
>
> Also, it is a perhaps 30+ years experience with a (then commercial 
> product) library for the earlier days C++ which emulated the rich (vis 
> a vis that time /coeteris paribus/) collection classes from Smalltalk.
>
> About CLion I say that history shows that the now famed Eclipse came 
> from Visual Age (which had a Smalltalk and then a Java version), so we 
> probably could inject this on them, but the question seems to be why 
> they don't feel the need:
>
> my 0.019999....
>
> --
> Cesar Rabak
>
>
> On Sun, Dec 4, 2022 at 4:31 PM andre <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     Hi Eliot,
>
>     > In your team maybe :-)
>
>     I was talking about the base images and packages, not our own.
>
>     > C++ does nothing to fix these issues either
>
>     Oh, it does a lot of things. Most importantly, it refuses to even
>     compile incomplete or mismatched code. It enforces consistency
>     reaching into transitive depths that no human is able to forsee or
>     keep track of manually (types, immutability, ownership, etc). Some
>     cryptic error message may make you scratch your head, but it never
>     misses a thing.
>
>     Smalltalk silently swallows everything and keeps you in the dark
>     until its too late. Small shops simply cant afford to add manpower
>     only to maintain a level of consistency that C++ has already built
>     in. With a complex UI, unit tests also have limits. Unless you can
>     afford to spend more time testing than developing. And if so,
>     where's the productivity advantage?
>
>     The problem is not "old hands" vs. impatient newbies. It's lack of
>     formal support from the language when you need it (if you need it).
>
>     I should maybe note that C++20 is lightyears ahead of older
>     standards and much of what made C++ a PITA back in the day is no
>     longer relevant today.
>
>     Andre
>