Re: Digital Twin applied to Software

On Mon, Dec 5, 2022 at 6:14 AM andre <[email protected]> wrote:

> Eliot,
>
> I didn't mean to start a flame war.


Me neither.  Pleas forgive my full stop sentence :-/

> I'm as passionate a Smalltalker as probably everyone on the list. And
> Smalltalk is my platform of choice for many reasons. My point is that C++
> has a lot of powerful things to offer that Smalltalk can't do and vice
> versa. And since the topic is Digital Twin, it's worth pointing out the
> differences.
>
> The only issues I am still encountering with Smalltalk after 30 years are
> of the kind that could be caught at compile time with strong typing. So
> maybe I'm biased.
>

Well, Strongtalk should have fixed that.  We should be using advisory type
systems in Smalltalk, but no one has stood up to provide a good open source
implementation for the Squeak community.  Of which more below...

> I agree with what you say about teams and culture. The challenges of
> safely refactoring and maintaining a complex system however don't go away
> for a single developer either, no matter how experienced and disciplined
> they are.
>

Indeed.  High-level analysis tools are needed.  Just today I tried to write
code to find "all" assignments to Transcript in Squeak. THis is tricky
because one can write "Transcript := <expr>" or "Smalltalk at: #Transcript
put: <expr>", ignoring exotic ways such as "(Smalltalk associationAt:
#Transcript) value: <expr>" and it wasn't easy:
| tb sb |
sb := Smalltalk bindingOf: #Smalltalk.
tb := Smalltalk bindingOf: #Transcript.
self sn browseAllSelect:
      [:m|
      ((m hasLiteral: tb)
        and: [m methodNode anySatisfy:
                  [:n| n isAssignmentNode and: [n variable key == tb]]])
      or: [(m hasLiteral: #Transcript)
            and: [m methodNode anySatisfy:
                        [:n|
                        n isMessageNode
                        and: [n selector key == #at:put:
                        and: [n receiver
                                    ifNil: [false] "cascades..."
                                    ifNotNil:
                                          [:r|
                                          r isVariableNode
                                          and: [r key == sb
                                          and: [n arguments first
isLiteralNode
                                          and: [n arguments first key ==
#Transcript]]]]]]]]]]

and this is a trivial micro-analysis. Doing meaningful
representation-independent analyses appears to me to be in the realms of
skilled craft, not tractable mathematics/code.  Visualization is good.  But
nothing out there that I'm aware of extracts architectural meaning from
low-level code.  We don't even have good mathematical languages for
algorithmic or data-centric representations that differs meaningfully in
level of abstraction from the code itself.

> Fact is, every issue that can be caught at compile time lowers the burden
> of changing and maintaining large systems.
>

I agree.  I'm not against compile-time checking.  I am against systems that
provide me with compile-time checking and nothing else :-)

> Think LEGO (this modern LEGO that actually no longer resembles blocks).
> With C++ you get LEGO items that are impossible to combine in ways not
> intended and supported by the designers. This limits creativity but makes
> sure the final thing sticks together.
>

That's an interesting trade-off. I'll have to take a look at C++ '20's
collections.

> > we don’t have the analysis tools to identify inconsistency of duplication
>
> Eliminating duplication with tools was not my point. It was that Smalltalk
> doesn't enforce almost anything (typing, interfaces, mutability, etc). So,
> because it is convenient, developers feel encouraged to add new things on
> top and in between instead of streamlining and refactoring an existing
> system. They don't want to risk silently breaking things and losing
> backwards compatibility.
>

Again I come back to good team culture.  I think this is something I've
done with colleagues and without in various Smalltalk VMs I've worked on,
especially in the opensmalltalk-vm.  And I learnt a huge ammount in getting
to work on and evolve the HPS VM (ObjectWorks 4, VisualWorks).  This VM was
written in five big chunks, JIT, stack/glue, mem/gc, ext, plat/platpc, with
well-documented interfaces, assertions, and rather beautiful technical
essays on the overall architecture, and the architecture of each major
component.  You can see these in the src/doc/{vi,vm} directories in the
VisualWorks distribution (if it includes VM source).  But HPS was written
by a small team, essentially 5 people. [And Adele would say "if it isn't
documented it doesn't exist"]

Sometimes I think I don't ever want to work on a single piece of code that
requires a team larger than 20, and that already feels uncomfortably big to
me.  The way to scale being modularise the solution/code base so that small
teams can develop independently.  But then I realise I work with many more
people than that in the Squeak community and it seems to work well. That's
because there are well-defined components one can work with and we strive
to minimise "bleed", e.g. policing the UI-creep into the compiler, etc.

If a team gets too big, or is too weak, to maintain a culture in which "the
source code" is broadly understood and navigable by most members then
either the project needs splitting up, the skill levels of members raised,
or the project abandoned [I'm being hyperbolic here].

But your last point is very important.  If one doesn't have tests then one
is really screwed.  This is Gilad Bracha's key argument for the
real-world-use idea of Newspeak, that one should never have legacy.  Legacy
kills you unless you have tests.  Gilad's idea was to have all programs be
updatable in the field, so one can always upgrade the core language
libraries, maintaining backward compatibility only with the set of
applications that exist.  I think this is a little glib, but attractive,
and I understand where he's coming from; he was burnt by Java specification.

Alan Kay and I discussed something interesting on Quora a couple of years
ago which I think has potential, and that is to try and write tests as
programming manuals, or at least specifications.  So that the tests are
designed to be read by humans as examples.  That should extend to
architectures.  But IME TDD is limited by the difficulty of constructing
whole system tests.  It's easy to do TDD on library-level components.  It's
much harder to do it on system-level components. At the least, one needs to
extend the framework out of the current system and into the cloud to be
able to assemble networks of machines/programs/computational-elements.

Breaking things with sweeping changes is not that much a creeping issue
> with C++, because incompatible code won't compile until you have worked
> your way through the required changes, one compiler error message at a
> time. This doesn't eliminate semantic errors, but at least the LEGO blocks
> fit. And yes, this is a big deal if you have to maintain thousands of
> classes with limited human resources.
>
> > Tests run automatically
>
> Writing the tests and making sure they are complete is the burden, not
> running them. Tests also can't prevent developers from accidentally passing
> the wrong type of argument, or a new method from returning an unexpected
> type of object. Systems can and do break between the tested modules, not
> only within. Many things also cannot be tested in advance, especially user
> behavior and UI.
>

If the granularity of tests is too small to allow these kinds of errors
then one is doing TDD wrong.  Of course one should be testing in such a way
that module interfaces are covered.

> > I’m using 2017
>
> Using the compiler is one thing. Leveraging new language capabilities to
> facilitate more abstraction, safety and readability requires wide ranging
> changes to existing code that most developers usually avoid (or are not
> paid for).
>

Amen.  Any any institution that values the longevity of its software must
incorporate a culture that evolves the code base.  Squeak trunk is one such
development process.

> Why did StrongTalk never gain tracktion, by the way?
>

Arguably it has.  PHP and Dart both includer advisory type systems, and
there are probably more.  Why we don't have Strongtalk in Smalltalk is a
good question.  I did ask Gilad if he would release the code as opensource
and he claimed he was too embarrassed by the quality of the code.
Strongtalk, the Smalltalk system, exists.  IOt would be great to see a
project to extract Strongtalk, the type system, from it and port it to
Squeal/Pharo/Cuis/VisualWorks/gemstone.

Does Smalltalk/X still compile to C/C++ ?
>

Ask Jan.  Not sure.

_,,,^..^,,,_
best, Eliot