Re: Digital Twin applied to Software

I think your assertion "... will use speed as criterion..." is an all
encompassing one, which logically is a  flawed reasoning.

In development horses for the courses is the more sensible and in the long
run the most successful way to run a shop or to stay in market.

Approaches which lead to flexibility may be required for certain
businesses, while speed may be needed for other tasks. But surely we don't
need to start in one approach and migrate to another.

In a not recent paper by Heeg (in this forum) showed the use of VW
Smalltalk to do prototypes and proof of concept before embarking in the
full product for a commercial ERP product, which see, the implementation
language of the additional funcionality was not even a pure Object Oriented
Language.

I think that if we reason a little, we already have not only "Digital
Twins", but "digital siblings" all scattered and being exploited on a daily
basis. . .

--
Cesar Rabak


On Tue, Nov 8, 2022 at 3:15 PM Aik-Siong Koh <[email protected]> wrote:

> As long as a program has dynamic code, it will not run as fast as a pure
> C++ program.
> A customer evaluating which software to buy will only use speed as
> criterion as long as it runs his problem.
> That is why I think Digital Twins are necessary. One for flexibility.
> One for speed.
>
> Aik-Siong
>
> Colin Sare-Soar wrote:
> > This all sounds rather complicated for what would be achieved in the end.
> > It isn't Smalltalk and therefore a bit out of the scope of this board
> but I thought I should mention Pyside6 in respect of prototyping in an
> interpreted language (Python) and running with C++ libraries (Qt) accessed
> from within Python code.
> > Maybe something similar could be done with SmallTalk which seems to be
> what you are suggesting in your final paragraph.
> >
> >> On 08/11/2022 13:59 +07 andre <[email protected]> wrote:
> >>
> >>
> >> As said, there is no formal mapping.
> >>
> >> One could enforce a common denominator (design patterns) at both ends,
> like shared pointers for all objects, only virtual methods at the C++ end
> and strong typing at the Smalltalk end. In reality it get's a lot more
> complex than that (need for class-side virtual methods, reflection).
> >>
> >> That would rob each side of its unique advantages. You would get
> something a C++ compiler can compile, but not C++. Not much would be left
> of the performance gain.
> >>
> >> The new Smalltalk compiler would have to deal with strong typing and
> the exceptions and dependency management it implies. It'd be a new language.
> >>
> >> Porting Smalltalk to C++ involves a lot of deep thought and manual work
> that can be assisted by tools only to some extent. Porting C++ to Smalltalk
> is even more daunting (almost impossible, I would say) except for simple
> classes and domains.
> >>
> >> Another approach is to embedd a Smalltalk interpreter or VM into a C++
> application. That way you get a solid foundation with dynamic
> extensibility. Should work fine for CAD.
> >>
> >> Andre
> >>
> >> --
> >>
> >>> On 7. Nov 2022, at 03:57, Aik-Siong Koh <[email protected]> wrote:
> >>>
> >>> Andre:
> >>>
> >>> You understand my Digital Twin idea perfectly. Your statement sums it
> all:
> >>> "The ideal case for using both languages together might be to explore
> uncharted terrain with Smalltalk and port to C++ after a sound architecture
> has settled."
> >>>
> >>> Anyone doing this systematically? How to promote Digital Twin? How to
> turn this Smalltalk advantage into a business?
> >>>
> >>> I am applying idea to Pharo and OpenCascade to create Digital Twins of
> CAD software. Any feedback or interest would be greatly appreciated.
> >>>
> >>> All the best,
> >>> Aik-Siong
> >>>
>
>