Re: Digital Twin applied to Software

This
>
> ... only requirement is that the same inputs give the same desired outputs.
>

is  a typical consequence of both (and it can be extended to a large number
of languages/technologies) be Turing Complete.

In other realms, like Function Point Analysis, this is the paradigm: if two
systems are equivalent (using the definition above) then the advantages of
the approach, including cost, time to deliver, etc. can be analysed.

Your suggestion of the use of two paradigmatically different programming
languages to "discover" in one and implement in other "fast" is not
amenable to real systems, only to toy programs where the problem is chosen
carefully beforehand to "fit" both languages.

Programming shops already strive to have the right balance of technologies
in order to have "the best of the 'n' worlds".

When in one language (C++) the decision is a command, while in Smalltalk
the Boolean is an object the impedance mismatch in attempting any
reasonable problem which has conditions, loops, etc. will show that the
prototype in Smalltalk could not be used to "port" the algorithm as the
details that effectively make the program work in one language would be far
away in the other.

Besides, most of the present problems in development are less about
algorithms and more about integrate large bunches of functionality written
in several languages, different eras to solve a business problem.



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

> Digital Twins do not need any mapping within their boxes. The only
> requirement is that the same inputs give the same desired outputs. Total
> independence would enhance software quality to the max.
>
> Now, I am proposing that one twin is used for discovery of algorithms
> while the other implements the desired algorithm fast. We are porting
> algorithm not porting Smalltalk code necessarily.
> We truly want and can have the best of both worlds.
>
> Thanks,
> Aik-Siong
>
> andre 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
> >>
> >
>
>