George Neuner <gneuner2@comcast.net> writes:
> And now Microsoft has hired Guido and wants him to make Python more
> performant ... even if it breaks compatibility (again).

IMHO, the great failing of Python 3 was that it broke everything, degraded
performance, and didn't (really) give us anything new.

I would have forgiven MUCH bigger changes, if it had become capable of true
parallel threading within one interpreter instance.

Andy

On Saturday, July 10, 2021 at 7:45:17 PM UTC-5, BGB wrote:
> On 7/10/2021 5:41 PM, MitchAlsup wrote:
> > On Saturday, July 10, 2021 at 2:37:20 PM UTC-5, BGB wrote:
> >> On 7/10/2021 12:41 PM, MitchAlsup wrote:
> >>> On Saturday, July 10, 2021 at 12:22:03 PM UTC-5, BGB wrote:
> >
> >>>>
> >>>> *1: automatic scoped objects would be added to a linked list, and freed
> >>>> on function return.
> >>> <
> >>> Also freed when stack is walked back on Exception processing (TRY-THROW-
> >>> CATCH) But instead of placing the allocated item on the linked list, one should
> >>> place the destructor of the linked list.
> >> This is more-or-less how it is intended to work, just say with the
> >> memory object having a layout like:
> >> next pointer
> >> pointer to 'free()' function or destructor;
> >> payload data.
> >>
> >> And, the unwinder logic could see that objects were allocated via the
> >> linked list, and then process it to free or destroy any objects held in
> >> the list.
> >>
> As can be noted, the above is what I have been going with thus far.
> >>
> >> Otherwise... It would have been simpler to not bother with unwinding and
> >> instead build the exception mechanism around a linked list of
> >> setjmp/longjmp frames or similar (*1).
> >>
> >> Though, as noted:
> >> This makes try/catch slower and more expensive in the no-exception case;
> >> This doesn't allow for unwinding in child frames without them (in
> >> effect) introducing their own implicit try/catch blocks;
> >> However, it could be faster to handle a thrown exception.
> >>
> >> Doing it with unwinding tables makes "try/catch" blocks cheaper, allows
> >> for unwinding child frames with no additional overhead, ... However,
> >> with the drawback that "throw" is a lot more complicated and is
> >> significantly slower.
> >>
> >>
> >> *1: Say, for example:
> >> try { ... } catch(Exception e) { ... }
> >> Becomes, effectively something like:
> >> if(!setjmp(eh_frame))
> >> {
> >> eh_frame->eh_chain = __tbr_exception_chain;
> >> __tbr_exception_chain = eh_frame;
> >> ...
> >> __tbr_exception_chain = eh_frame->eh_chain;
> >> }else
> >> {
> >> ... catch magic ...
> >> }
> >>
> >> And:
> >> throw e;
> >> Becomes, effectively:
> >> __tbr_exception_obj = e;
> >> longjmp(__tbr_exception_chain, 1);
> > <
> > But you have not performed the destructors or the free's, unless you just made longjump
> > a lot slower.
> > <
> That is a potential major drawback:
> Unwinding could effectively cost an exception handler + rethrow frame
> for every stack frame which has destructors which need to be called, ...
>
> I thought about it, and realized this option could potentially suffer a
> lot worse in terms of both stack memory usage and code footprint
> overhead (so may not be viable in practice).
>
>
> Then also thought about it, and realized that the unwind logic could be
> made simpler and faster if, instead of reusing the main function epilog
> with an interpreter, the compiler instead emits a secondary entry point
> into the epilog.
<
Alternately, the compiler could arrange that the epilogue contains a call
to the destructor-and-free list. So the stack-unwinder could simply call
that function too.....
<
>
> This secondary entry point:
> Reloads the saved LR;
> Moves it to a special register;
> Saves the address from the unwind logic where the original LR went;
> Branches back into the original epilog.
>
> The epilog logic then functions as-normal, except that control from it
> is redirected back into the unwind logic rather than into the original
> caller function.
>
>
> Would require some fairly awkward logic though.
<
This is why making the call to the destructor-and-free list more reasonable.
All the unwinder needs is the call address and the list pointer. If destructors
are done "correctly" the could be common code across the entire compiled
application--making the address unnecessary, and only the link pointer needed.
<
You definition of "correctly" might be a bit different than mine.
<
> Chances are, in this case, the unwind logic would need to be written in
> ASM, and likely use TLS variables or similar for its internal working
> state (can't use global variables as GBR would also be in-flux).
>
> Could maybe also require that the ".pdata" table have its entries sorted
> by RVA, as this would allow for using binary search.
>
> ...
> >>>>
> >>>>
> >>>> Similarly, a language is easier if one can't pass classes by copy either
> >>>> (eg: if one uses mostly Java-style semantics here), ...
> >>>>
> > <snip>
> >>>>
> >>>> In contrast, while a macro is not a function, its behavior is well
> >>>> defined, and its handling by an implementation is relatively
> >>>> straightforward.
> >>>>
> >>>> And, if a programmer abuses preprocessor macros and the size of their
> >>>> binary explodes as a result, they have no one to blame but themselves...
> >>> <
> >>> Yet, if they exploit the preprocessor properly, their program gets smaller
> >>> and more readable.
> >>>
> >> Yes, possible as well...
> >>
> >> It can be noted that, despite my custom languages' relations to
> >> JavaScript and Java, it still retains the use of a C style preprocessor.
> >>
> >>
> >> I had generally ended up coming to the opinion that preprocessor macros
> >> ultimately help more than they hurt, and the language is meant partly
> >> more of a "get stuff done" language than a "try to nanny the programmers
> >> and force them to 'do the right thing'" language.
> >>
> >> Also it still has pointers and similar, so it is possible to use it in a
> >> C like style as well, though its typesystem is a little more restrictive
> >> when compared with C.
> >>
> >>
> >> Most of the differences though exist mostly in the frontend, and the
> >> compiler backend actually doesn't really know or care which front-end
> >> language it is dealing with.
> >>
> >> To some extent, I am trying to keep the language efficient, namely:
> >> string str = "Some String";
> >> Actually has a lot more in common with:
> >> const char *str = "Some String";
> >>
> >> Than it does with any high-level "String Object" type.
> >> And, by extension, are typically NUL terminated (or, in effect, unlike C
> >> strings they actually use a bidirectional double-ended termination
> >> scheme), ...

On Sat, 10 Jul 2021 18:14:38 -0700, Andy Valencia <vandys@vsta.org>
wrote:

>George Neuner <gneuner2@comcast.net> writes:
>> And now Microsoft has hired Guido and wants him to make Python more
>> performant ... even if it breaks compatibility (again).
>
>IMHO, the great failing of Python 3 was that it broke everything, degraded
>performance, and didn't (really) give us anything new.
>
>I would have forgiven MUCH bigger changes, ...

Yeah. I don't care much about Python, but I agree that if something
is to break compatibility then the new version had better be worth the
trouble.

>... if it had become capable of true parallel threading within one
>interpreter instance.

Parallel threading is complex in any kind of GC environment, but is
harder if you want heap compaction, and even harder if you want to
continue running mutators while compacting.

Many GC'd languages - including Python - have opted instead for CSP
(some augmented by concurrent "green" threads within processes).

>Andy
George

Marcus <m.delete@this.bitsnbites.eu> schrieb:

> When used correctly (TM), C++ is very well suited for generating tight
> code (e.g. for embedded systems etc). I generally like (small) template
> functions & classes, since:
>
> * You get type safety (unlike C macros).
> * Code is inlined -> zero overhead.
> * A lot of work can be moved from run time to compile time.
> * You avoid error-prone duplication of boiler-plate code.

I agree that templates serve an important function, and that
C++ templates can be made to do the job.

What I do not agree with is that the templates should be Turing
complete (AFAIR, somebody wrote an actual Turing machine in C++
templates). Among other problems, this means that the correctness
of C++ templates is undecidable, which is not a happy state of
affairs :-)

I do have an issue with the heap of features that C++ has become,
but I have already expressed that elsethread :-)

On 2021-07-11, Thomas Koenig wrote:
> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>
>> When used correctly (TM), C++ is very well suited for generating tight
>> code (e.g. for embedded systems etc). I generally like (small) template
>> functions & classes, since:
>>
>> * You get type safety (unlike C macros).
>> * Code is inlined -> zero overhead.
>> * A lot of work can be moved from run time to compile time.
>> * You avoid error-prone duplication of boiler-plate code.
>
> I agree that templates serve an important function, and that
> C++ templates can be made to do the job.
>
> What I do not agree with is that the templates should be Turing
> complete (AFAIR, somebody wrote an actual Turing machine in C++
> templates). Among other problems, this means that the correctness
> of C++ templates is undecidable, which is not a happy state of
> affairs :-)
>
> I do have an issue with the heap of features that C++ has become,
> but I have already expressed that elsethread :-)
>

Agree. I think that very few programmers think that C++, as a whole,
is a good/clean programming language. On the other hand, if you can
tame it to suit your needs (by using sane subsets), it can work to
your advantage - even more so than C IMO.

The things that I like and use the most in C++, compared to C, are
the non-zero-terminated strings, the stronger typing (incl. templates
over macros) and the better support for guaranteeing initialized/defined
variables and avoiding NULL.

On the topic of modern C, some talented people over at Our Machinery are
using C to create a new game engine. Have a look at some of the blog
posts: https://ourmachinery.com/post/

E.g. https://ourmachinery.com/post/defaulting-to-zero/ is an interesting
take.

/Marcus

On 11/07/2021 22:04, Thomas Koenig wrote:
> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>
>> When used correctly (TM), C++ is very well suited for generating tight
>> code (e.g. for embedded systems etc). I generally like (small) template
>> functions & classes, since:
>>
>> * You get type safety (unlike C macros).
>> * Code is inlined -> zero overhead.
>> * A lot of work can be moved from run time to compile time.
>> * You avoid error-prone duplication of boiler-plate code.
>
> I agree that templates serve an important function, and that
> C++ templates can be made to do the job.
>
> What I do not agree with is that the templates should be Turing
> complete (AFAIR, somebody wrote an actual Turing machine in C++
> templates). Among other problems, this means that the correctness
> of C++ templates is undecidable, which is not a happy state of
> affairs :-)

They are not Turing complete or undecidable in practice, because they
are finite - indeed, they are usually quite limited in recursion depth.
For gcc, the template depth is 900 by default. That's enough to write
some pretty complicated stuff (like an Ackermann function!). The
standards merely require a lower bound on the depth and set no upper
bound, so in theory they are Turing complete.

But what artificial limits would you put on templates in order to stop
them being Turing complete? What would be the point? Their Turing
completeness was accidental, as a result of giving them the features
programmers needed and wanted. The lack of recursion is a major
limitation in C macros - but once you have decided that something can be
recursive, Turing completion is just round the corner.

It turned out that you could use templates for some useful compile-time
calculations, but they are very awkward, ugly and inefficient for it.
So "constexpr" functions (and now "consteval" functions) were added to
save people using templates in that way. Templates have gone back to
their old ways, and no one cares any more that they can be used for
calculations because constexpr functions are so much easier to write and
faster to compile.

>
> I do have an issue with the heap of features that C++ has become,
> but I have already expressed that elsethread :-)
>

> But what artificial limits would you put on templates in order to stop
> them being Turing complete? What would be the point? Their Turing
> completeness was accidental, as a result of giving them the features
> programmers needed and wanted. The lack of recursion is a major
> limitation in C macros - but once you have decided that something can be
> recursive, Turing completion is just round the corner.

FWIW, I remember reading an article that compiled a non-trivial subset
of Haskell to CPP macros. While CPP macros do not allow recursion, you
can circumvent the limitation by limiting the recursion depth to a fixed
number (and by duplicated macro definitions, e.g. you replace
a recursive call of FOO to FOO by a call from FOO##n to FOO##n+1).
Impractical when coding by hand, but much less so when your macro
definitions are written by a compiler.

Also, in practice all our machines a finite state machines rather than
Turing machines (we don't have an *infinite* tape).

So in practice the distinction between Turing complete and FSM is
sometimes much less clear cut than one might think.

This is related to a pet theme of mine which is the issue of "decidable
type checking": on the one hand you have C++'s type checking which is
(in theory) undecidable (as a consequence of the template's Turing
completeness) yet people use it quit happily, OTOH you can have a type
system that's decidable but is prohibitively costly in practice, where
knowing that it will *eventually* terminate is not relevant because your
computer (or you) will die before that happens.

Stefan

On 7/8/2021 12:02 PM, George Neuner wrote:
> On Thu, 8 Jul 2021 08:57:42 -0700, Stephen Fuld
> <sfuld@alumni.cmu.edu.invalid> wrote:
>
>> On 7/8/2021 7:13 AM, Thomas Koenig wrote:
>>
>>> There is also the illusion, harbored by too many people, that they
>>> need a certain programming language that is cool, or that this is
>>> what everybody else does.
>>>
>>> And this is where the danger lies with C++, especially when it is
>>> used by scientists with little CS experience and background.
>>>
>>> Although, I admit it, Python is far worse than C++ in that respect.
>>
>> This statement surprises me. What language do you suggest for such people?
>
> A couple of years ago, /I/ would have said Racket. Unfortunately, the
> Racket development team now appears determined to change the language
> from being Scheme-like to being Python-like ... some nonsense about
> "parentheses" and "prefix notation" scaring people.

I had heard of Racket, but didn't know anything about it, so I did a
little reading.

I think the issue to which you are referring is that Racket comes from
the Lisp, Scheme family of languages, this has more parentheses and uses
prefix notation when compared to the Fortran/C type syntax.

For the record, my undergraduate degree was in Chemistry, so I have some
sympathy for the scientists/engineers.

Without deprecating Racket in any way (I don't know enough to do that),
I disagree with you and agree with the "too many parentheses/prefix
notation" people.

These people are not computer scientists, and while they are usually
smart people, they want to get some job in science/engineering done, and
want the easiest tool to use to do that. They don't particularly care
about some arcane aspects of the language they are using.

They are familiar with formulas. They use them all the time in their
classes and in their work. Remember, Fortran is short for Formula
Translator. So a language that is similar to that is easier for them to
learn, thus a better choice. In that context, I don't regard their
disdain for Lisp style language syntax as "nonsense". They want to do
some job and not be distracted by unfamiliar syntax, etc.

Thus I think Python is a good choice (not counting the 2-3 mess).

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Monday, July 12, 2021 at 2:39:16 PM UTC-5, Stephen Fuld wrote:
> On 7/8/2021 12:02 PM, George Neuner wrote:
> > On Thu, 8 Jul 2021 08:57:42 -0700, Stephen Fuld
> > <sf...@alumni.cmu.edu.invalid> wrote:
> >
> >> On 7/8/2021 7:13 AM, Thomas Koenig wrote:
> >>
> >>> There is also the illusion, harbored by too many people, that they
> >>> need a certain programming language that is cool, or that this is
> >>> what everybody else does.
> >>>
> >>> And this is where the danger lies with C++, especially when it is
> >>> used by scientists with little CS experience and background.
> >>>
> >>> Although, I admit it, Python is far worse than C++ in that respect.
> >>
> >> This statement surprises me. What language do you suggest for such people?
> >
> > A couple of years ago, /I/ would have said Racket. Unfortunately, the
> > Racket development team now appears determined to change the language
> > from being Scheme-like to being Python-like ... some nonsense about
> > "parentheses" and "prefix notation" scaring people.
> I had heard of Racket, but didn't know anything about it, so I did a
> little reading.
>
> I think the issue to which you are referring is that Racket comes from
> the Lisp, Scheme family of languages, this has more parentheses and uses
> prefix notation when compared to the Fortran/C type syntax.
>
> For the record, my undergraduate degree was in Chemistry, so I have some
> sympathy for the scientists/engineers.
>
> Without deprecating Racket in any way (I don't know enough to do that),
> I disagree with you and agree with the "too many parentheses/prefix
> notation" people.
>
> These people are not computer scientists, and while they are usually
> smart people, they want to get some job in science/engineering done, and
> want the easiest tool to use to do that. They don't particularly care
> about some arcane aspects of the language they are using.
>
> They are familiar with formulas. They use them all the time in their
> classes and in their work. Remember, Fortran is short for Formula
> Translator. So a language that is similar to that is easier for them to
> learn, thus a better choice. In that context, I don't regard their
> disdain for Lisp style language syntax as "nonsense". They want to do
> some job and not be distracted by unfamiliar syntax, etc.
>
> Thus I think Python is a good choice (not counting the 2-3 mess).
<
For most of these kinds of "let us figure out how to solve the problem"
eXcel is a far better language than any std language.
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 7/8/2021 12:53 PM, Thomas Koenig wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> On 7/8/2021 7:13 AM, Thomas Koenig wrote:
>>
>> snip
>>
>>> There is also the illusion, harbored by too many people, that they
>>> need a certain programming language that is cool, or that this is
>>> what everybody else does.
>>>
>>> And this is where the danger lies with C++, especially when it is
>>> used by scientists with little CS experience and background.
>>>
>>> Although, I admit it, Python is far worse than C++ in that respect.
>>
>> This statement surprises me.
>
> Konrad Hinsen explained it better than I can, in
>
> http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/
>
> His major point is that frequent changes in Python make science
> unreproducable, especially the graphics changes.

I read that post, and has several reactions. One is that the author
seems worked up about it particularly as he has a Python package that
was hurt by the Python2-3 mess.

Second, if you regard Python 3 as a new language, and Python 2 as a
no-longer-actively-supported language, it puts things in a better context.

In that context, he raises some interesting questions about the
reproducablily of science over long periods (decades).

The obvious answer is to archive all the software he used, but that has
issues too. On what media? 40 years ago, the answer might have been 8
inch floppy disks. How would you read those now? Is it the scientists
responsibility to update the archives to newer media at an institution
where he may no longer? And what if he ran his program and got his
results on a Cray 1? Is it reproduceable now?

There are issues about language/package choice over the long term. What
if the language is no longer supported and the existing compilers won't
run on any currently supported hardware?

Even not counting computers, what if I got my results on a Model X
Spectrometer, which is no longer made, the company that made it is out
of business, and all the ones sold are long gone? If the results on the
current Model Y spectrometer are different, did I mess up, or was it the
instrument?

So, in summary, I think he is making too big a deal about the Python 2-3
mess, though it certainly is a problem, and it is one of a set of
potential problems much larger than what he is talking about.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Monday, July 12, 2021 at 3:09:15 PM UTC-5, Stephen Fuld wrote:
> On 7/8/2021 12:53 PM, Thomas Koenig wrote:
> > Stephen Fuld <sf...@alumni.cmu.edu.invalid> schrieb:
> >> On 7/8/2021 7:13 AM, Thomas Koenig wrote:
> >>
> >> snip
> >>
> >>> There is also the illusion, harbored by too many people, that they
> >>> need a certain programming language that is cool, or that this is
> >>> what everybody else does.
> >>>
> >>> And this is where the danger lies with C++, especially when it is
> >>> used by scientists with little CS experience and background.
> >>>
> >>> Although, I admit it, Python is far worse than C++ in that respect.
> >>
> >> This statement surprises me.
> >
> > Konrad Hinsen explained it better than I can, in
> >
> > http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/
> >
> > His major point is that frequent changes in Python make science
> > unreproducable, especially the graphics changes.
> I read that post, and has several reactions. One is that the author
> seems worked up about it particularly as he has a Python package that
> was hurt by the Python2-3 mess.
>
> Second, if you regard Python 3 as a new language, and Python 2 as a
> no-longer-actively-supported language, it puts things in a better context.
>
> In that context, he raises some interesting questions about the
> reproducablily of science over long periods (decades).
>
> The obvious answer is to archive all the software he used, but that has
> issues too. On what media? 40 years ago, the answer might have been 8
> inch floppy disks. How would you read those now? Is it the scientists
> responsibility to update the archives to newer media at an institution
> where he may no longer? And what if he ran his program and got his
> results on a Cray 1? Is it reproduceable now?
<
My first job was as a technician at a NMR facility, and once a year we copied
all the 9 track tapes onto a new tape just to preserve the readability of data
over time. Other than the change in media--nothing has changed in that if you
want something preserved for very long periods of time, maintenance is involved.
>
> There are issues about language/package choice over the long term. What
> if the language is no longer supported and the existing compilers won't
> run on any currently supported hardware?
<
You archive the compilers, run time, and may have to mothball entire machines
in order to be able to "go back" and check the results.
>
> Even not counting computers, what if I got my results on a Model X
> Spectrometer, which is no longer made, the company that made it is out
> of business, and all the ones sold are long gone? If the results on the
> current Model Y spectrometer are different, did I mess up, or was it the
> instrument?
<
You (Y O U) messed up by not keeping the original samples, and data from
the original spectrometers. It is not the instrument's fault that you did not
leave a trail.......
>
>
> So, in summary, I think he is making too big a deal about the Python 2-3
> mess, though it certainly is a problem, and it is one of a set of
> potential problems much larger than what he is talking about.
<
I think the problem was choosing Python in the first place............................
But that is a story for another time..........
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

> In that context, he raises some interesting questions about the
> reproducablily of science over long periods (decades).

We're slowly learning how to deal with this, yes.
In my field (compilers), the standards of publications in the past were
to only describe the results in the text, with literally no way to
reproduce the results.
While many articles are still following this model, more and more
articles come with "artifacts" which let the reader try out the code and
potentially reproduce the results. AFAICT the "artifacts" typically
take the shape of a VM image. This is needed not just "over long
periods" but so that the reviewers don't need to install the
corresponding OS and tools (and with compatible versions, and
configured just the way they need to be). It's still far from ideal,
tho:
- You need to be able to run those VMs, so in the long run you need an
emulator (most of those VMs are for the amd64 ISA).
- For this to have any value for science, it's important that
the binary/binaries can be reproducibly reconstructed from source, so
you basically need access to all the source code, including that of
the tools needed to compile and run that code, and all of that be
reproducible. The closest we have for that right now is NixOS/GuixOS.

> The obvious answer is to archive all the software he used, but that has
> issues too. On what media? 40 years ago, the answer might have been 8 inch
> floppy disks. How would you read those now? Is it the scientists
> responsibility to update the archives to newer media at an institution where
> he may no longer?

Archival of the actual bits is done by libraries, and they have
developed (and keep updating) protocols for archiving digital media.
That's "old news" by now for them, AFAIK.

Stefan

> I think the problem was choosing Python in the first place............................

48 byte integers anyone?

Stefan

On 7/12/2021 1:49 PM, MitchAlsup wrote:
> On Monday, July 12, 2021 at 3:09:15 PM UTC-5, Stephen Fuld wrote:
>> On 7/8/2021 12:53 PM, Thomas Koenig wrote:
>>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> schrieb:
>>>> On 7/8/2021 7:13 AM, Thomas Koenig wrote:
>>>>
>>>> snip
>>>>
>>>>> There is also the illusion, harbored by too many people, that they
>>>>> need a certain programming language that is cool, or that this is
>>>>> what everybody else does.
>>>>>
>>>>> And this is where the danger lies with C++, especially when it is
>>>>> used by scientists with little CS experience and background.
>>>>>
>>>>> Although, I admit it, Python is far worse than C++ in that respect.
>>>>
>>>> This statement surprises me.
>>>
>>> Konrad Hinsen explained it better than I can, in
>>>
>>> http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/
>>>
>>> His major point is that frequent changes in Python make science
>>> unreproducable, especially the graphics changes.
>> I read that post, and has several reactions. One is that the author
>> seems worked up about it particularly as he has a Python package that
>> was hurt by the Python2-3 mess.
>>
>> Second, if you regard Python 3 as a new language, and Python 2 as a
>> no-longer-actively-supported language, it puts things in a better context.
>>
>> In that context, he raises some interesting questions about the
>> reproducablily of science over long periods (decades).
>>
>> The obvious answer is to archive all the software he used, but that has
>> issues too. On what media? 40 years ago, the answer might have been 8
>> inch floppy disks. How would you read those now? Is it the scientists
>> responsibility to update the archives to newer media at an institution
>> where he may no longer? And what if he ran his program and got his
>> results on a Cray 1? Is it reproduceable now?
> <
> My first job was as a technician at a NMR facility, and once a year we copied
> all the 9 track tapes onto a new tape just to preserve the readability of data
> over time. Other than the change in media--nothing has changed in that if you
> want something preserved for very long periods of time, maintenance is involved.
>>
>> There are issues about language/package choice over the long term. What
>> if the language is no longer supported and the existing compilers won't
>> run on any currently supported hardware?
> <
> You archive the compilers, run time, and may have to mothball entire machines
> in order to be able to "go back" and check the results.

Easier now, but do you blame anyone for not mothballing a Cray 1?

>> Even not counting computers, what if I got my results on a Model X
>> Spectrometer, which is no longer made, the company that made it is out
>> of business, and all the ones sold are long gone? If the results on the
>> current Model Y spectrometer are different, did I mess up, or was it the
>> instrument?
> <
> You (Y O U) messed up by not keeping the original samples, and data from
> the original spectrometers. It is not the instrument's fault that you did not
> leave a trail.......

No, I kept the samples and the data, but when run on the new Model Y
spectrometer, it gets different results. (Of course, all of this is
hypothetical. I am not recounting my or anyone else's specific experience).

>> So, in summary, I think he is making too big a deal about the Python 2-3
>> mess, though it certainly is a problem, and it is one of a set of
>> potential problems much larger than what he is talking about.
> <
> I think the problem was choosing Python in the first place............................
> But that is a story for another time..........

OK, but that was the topic of this sub-thread.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Monday, July 12, 2021 at 4:26:32 PM UTC-5, Stephen Fuld wrote:
> On 7/12/2021 1:49 PM, MitchAlsup wrote:
> > On Monday, July 12, 2021 at 3:09:15 PM UTC-5, Stephen Fuld wrote:
> >> On 7/8/2021 12:53 PM, Thomas Koenig wrote:
> >>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> schrieb:
> >>>> On 7/8/2021 7:13 AM, Thomas Koenig wrote:
> >>>>
> >>>> snip
> >>>>
> >>>>> There is also the illusion, harbored by too many people, that they
> >>>>> need a certain programming language that is cool, or that this is
> >>>>> what everybody else does.
> >>>>>
> >>>>> And this is where the danger lies with C++, especially when it is
> >>>>> used by scientists with little CS experience and background.
> >>>>>
> >>>>> Although, I admit it, Python is far worse than C++ in that respect.
> >>>>
> >>>> This statement surprises me.
> >>>
> >>> Konrad Hinsen explained it better than I can, in
> >>>
> >>> http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/
> >>>
> >>> His major point is that frequent changes in Python make science
> >>> unreproducable, especially the graphics changes.
> >> I read that post, and has several reactions. One is that the author
> >> seems worked up about it particularly as he has a Python package that
> >> was hurt by the Python2-3 mess.
> >>
> >> Second, if you regard Python 3 as a new language, and Python 2 as a
> >> no-longer-actively-supported language, it puts things in a better context.
> >>
> >> In that context, he raises some interesting questions about the
> >> reproducablily of science over long periods (decades).
> >>
> >> The obvious answer is to archive all the software he used, but that has
> >> issues too. On what media? 40 years ago, the answer might have been 8
> >> inch floppy disks. How would you read those now? Is it the scientists
> >> responsibility to update the archives to newer media at an institution
> >> where he may no longer? And what if he ran his program and got his
> >> results on a Cray 1? Is it reproduceable now?
> > <
> > My first job was as a technician at a NMR facility, and once a year we copied
> > all the 9 track tapes onto a new tape just to preserve the readability of data
> > over time. Other than the change in media--nothing has changed in that if you
> > want something preserved for very long periods of time, maintenance is involved.
> >>
> >> There are issues about language/package choice over the long term. What
> >> if the language is no longer supported and the existing compilers won't
> >> run on any currently supported hardware?
> > <
> > You archive the compilers, run time, and may have to mothball entire machines
> > in order to be able to "go back" and check the results.
> Easier now, but do you blame anyone for not mothballing a Cray 1?
> >> Even not counting computers, what if I got my results on a Model X
> >> Spectrometer, which is no longer made, the company that made it is out
> >> of business, and all the ones sold are long gone? If the results on the
> >> current Model Y spectrometer are different, did I mess up, or was it the
> >> instrument?
> > <
> > You (Y O U) messed up by not keeping the original samples, and data from
> > the original spectrometers. It is not the instrument's fault that you did not
> > leave a trail.......
> No, I kept the samples and the data, but when run on the new Model Y
> spectrometer, it gets different results. (Of course, all of this is
> hypothetical. I am not recounting my or anyone else's specific experience).
<
So with different results, either the new spectrometer or the old spectrometer
was in error*. Does the new spectrometer have greater/lesser resolution ?
than the old one.
<
(*) then there is always the case where BOTH spectrometers are presenting
the best answer they can achieve. Why is this not good enough for your
test ? Are you OVERREADING the output of the spectrometers ? seeing
patterns that are not really there ? Should you be using a different spectrometer
with greater resolution and sensitivity when the old/new spectrometers disagree ?
<
> >> So, in summary, I think he is making too big a deal about the Python 2-3
> >> mess, though it certainly is a problem, and it is one of a set of
> >> potential problems much larger than what he is talking about.
> > <
> > I think the problem was choosing Python in the first place............................
> > But that is a story for another time..........
> OK, but that was the topic of this sub-thread.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 7/12/2021 3:01 PM, MitchAlsup wrote:
> On Monday, July 12, 2021 at 4:26:32 PM UTC-5, Stephen Fuld wrote:
>> On 7/12/2021 1:49 PM, MitchAlsup wrote:
>>> On Monday, July 12, 2021 at 3:09:15 PM UTC-5, Stephen Fuld wrote:

snip

>>>> Even not counting computers, what if I got my results on a Model X
>>>> Spectrometer, which is no longer made, the company that made it is out
>>>> of business, and all the ones sold are long gone? If the results on the
>>>> current Model Y spectrometer are different, did I mess up, or was it the
>>>> instrument?
>>> <
>>> You (Y O U) messed up by not keeping the original samples, and data from
>>> the original spectrometers. It is not the instrument's fault that you did not
>>> leave a trail.......
>> No, I kept the samples and the data, but when run on the new Model Y
>> spectrometer, it gets different results. (Of course, all of this is
>> hypothetical. I am not recounting my or anyone else's specific experience).
> <
> So with different results, either the new spectrometer or the old spectrometer
> was in error*. Does the new spectrometer have greater/lesser resolution ?
> than the old one.
> <
> (*) then there is always the case where BOTH spectrometers are presenting
> the best answer they can achieve. Why is this not good enough for your
> test ? Are you OVERREADING the output of the spectrometers ? seeing
> patterns that are not really there ? Should you be using a different spectrometer
> with greater resolution and sensitivity when the old/new spectrometers disagree ?

All good questions. Which is why I tried to say that the issue of
Python 2 vs 3 was a small part of a much larger question.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:

> In that context, he raises some interesting questions about the
> reproducablily of science over long periods (decades).
>
> The obvious answer is to archive all the software he used, but that has
> issues too. On what media? 40 years ago, the answer might have been 8
> inch floppy disks. How would you read those now? Is it the scientists
> responsibility to update the archives to newer media at an institution
> where he may no longer? And what if he ran his program and got his
> results on a Cray 1? Is it reproduceable now?

The problem that he describes with Python are much more pressing than
that :-)

> There are issues about language/package choice over the long term. What
> if the language is no longer supported and the existing compilers won't
> run on any currently supported hardware?

Absolutely, there are no absolutes, but this is a question
of degree.

But you can chose a deliberately moving platform like Python,
or you can chose something inherently stable which is slow
to introduce incompatibilities.

In passing, Hingsen mentions a Fortran program written in 1994
which "just runs". That matches my own experience with a couple
of Fortran programs that I maintain at work.

Or look at Netlib - these programs still work today on a modern
Fortran compiler, many of them go back to the 1970s.

I recently had occastion to need a reliable (and efficient) root
finder. So I took an implementation of Brent's algorithm from
Netlib, ran it through Nag Toolpack, itself a program from 1979,
to bring its control structures up the to Fortran 77 standard
including IF/THEN/ELSE, and started using it. Works flawlessly.

The same could be said about C, although the compatibility going
I would probably put the compatibility level at Ansi C - not
sure what gotchas were introduced in the transition between
K&R and Ansi. So, compatibility since the 1990s.

> Even not counting computers, what if I got my results on a Model X
> Spectrometer, which is no longer made, the company that made it is out
> of business, and all the ones sold are long gone? If the results on the
> current Model Y spectrometer are different, did I mess up, or was it the
> instrument?

No need to go back into the past for that - especially when things
are used for analytics, the results can be plain wrong.

About 10 years ago, I was involved in a project where analytical
results of a product made in the lab had some properties that were
wery strange, and not what we wanted. We discussed this again
and again in the meetings, tried to change the way the product
was made. We saw changes, but the basic problem remained.

Next thing, the external company told us that they had made a
mistake in their analytic procedure, and suddenly things looked
much more like what we expected.

So, we had filled up all the tables with values which basically
worthless. Avoiding cross-contamination of old and new data proved
almost impossible. "Fortunately", what we had tried up to that
point yielded worthless product properties anyway, so this was no
big loss.

> So, in summary, I think he is making too big a deal about the Python 2-3
> mess, though it certainly is a problem,

The other points are also important - for example scripts working
for two to three years even in the absence of a major update.

Again, this should be a reason not to use Python.

> and it is one of a set of
> potential problems much larger than what he is talking about.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Monday, July 12, 2021 at 2:39:16 PM UTC-5, Stephen Fuld wrote:

>> Thus I think Python is a good choice (not counting the 2-3 mess).

Like I wrote, Python has far too much instability even in the
absence of major revision changes. Each version is slightly
incompatible to the last one, and it adds up.

><
> For most of these kinds of "let us figure out how to solve the problem"
> eXcel is a far better language than any std language.

Personally, I find Excel horrible because you cannot see the
formulas, and unit conversion almost always bites me.

For engineering-style work (simple formulas with a root finding
or integration thrown in) I absolutely prefer MathCad, where you
can see the formulas clearly and evaluate them immediately.

Before distribuging a complicated Excel sheet to colleagues,
I usually develop the formulas in MathCad, and then translate
them to Excel step by step.

MathCad, by the way, had its own version of the Python 2/Python 3
fiasco going from MathCad 15 to MathCad Prime, where they introduced
a lot of incompatibility, but I still use the old one.

There doesn't seem to be a free version of it anywhere,
unfortunately.

On Mon, 12 Jul 2021 12:57:31 -0700 (PDT), MitchAlsup
<MitchAlsup@aol.com> wrote:

>On Monday, July 12, 2021 at 2:39:16 PM UTC-5, Stephen Fuld wrote:
>
>> These people are not computer scientists, and while they are usually
>> smart people, they want to get some job in science/engineering done, and
>> want the easiest tool to use to do that. They don't particularly care
>> about some arcane aspects of the language they are using.
>>
>> They are familiar with formulas. They use them all the time in their
>> classes and in their work. Remember, Fortran is short for Formula
>> Translator. So a language that is similar to that is easier for them to
>> learn, thus a better choice. In that context, I don't regard their
>> disdain for Lisp style language syntax as "nonsense". They want to do
>> some job and not be distracted by unfamiliar syntax, etc.
>>
>> Thus I think Python is a good choice (not counting the 2-3 mess).
><
>For most of these kinds of "let us figure out how to solve the problem"
>eXcel is a far better language than any std language.

Or Mathematica, or SciLab, or some such.

As Mitch notes, there is a big difference between exploration figuring
out how to solve a problem, and writing an application that implements
the solution.

George

On Mon, 12 Jul 2021 12:39:14 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

>I had heard of Racket, but didn't know anything about it, so I did a
>little reading.
>
>I think the issue to which you are referring is that Racket comes from
>the Lisp, Scheme family of languages, this has more parentheses and uses
>prefix notation when compared to the Fortran/C type syntax.
>
>For the record, my undergraduate degree was in Chemistry, so I have some
>sympathy for the scientists/engineers.
>
>Without deprecating Racket in any way (I don't know enough to do that),
>I disagree with you and agree with the "too many parentheses/prefix
>notation" people.
>
>These people are not computer scientists, and while they are usually
>smart people, they want to get some job in science/engineering done, and
>want the easiest tool to use to do that. They don't particularly care
>about some arcane aspects of the language they are using.
>
>They are familiar with formulas. They use them all the time in their
>classes and in their work. Remember, Fortran is short for Formula
>Translator. So a language that is similar to that is easier for them to
>learn, thus a better choice. In that context, I don't regard their
>disdain for Lisp style language syntax as "nonsense". They want to do
>some job and not be distracted by unfamiliar syntax, etc.
>
>Thus I think Python is a good choice (not counting the 2-3 mess).

A little off-topic, but ...

Python is great for scripting - but I do /not/ think it is great for
application programming. Particularly for science or engineering.

One of the biggest tells is that most of its data processing libraries
are written in C - not in Python. Whether simply for performance, or
for the inability of the language to express the solution, many people
have decided to bypass the language.

So what happens when there is no library for what you want to do. Can
you express your solution in Python? Yeah, probably ... but will it
perform well enough when you point it at large amounts of data?
Probably not.

In contrast, most of Racket's libraries are written in Racket. In
fact, most of Racket is written in Racket - there is only a small
bootstrap core that still is C/asm.

There is a portable bytecode interpreter, but on most platforms Racket
applications are compiled: either JIT (long time), or in more recent
versions with an AOT compiler.

No disputing, Racket has a steeper learning curve than Python - but if
there is no existing code that does what you want, you probably can
write it in Racket and /still/ get good performance without dropping
into a different langauge (which you can, Racket has a full featured
FFI if you need it).

And if you don't like the default Lisp/Scheme-like syntax or behavior,
Racket is a perfect transpile target for DSLs. Racket provides a YACC
work-alike, and a number of other parsers (LL and LR) are available as
libraries. You can create a language using any syntax you like.
Transpiled languages can be freely intermixed in the same program.

There are a number of such DSLs already: Prolog, Java, Algol-60, ML,
even Python [though I don't know which version or how complete it is].
And many others.

For all that, Racket's developers are concerned that Lisp and/or
Scheme has negative connotations and that people will avoid trying
Racket simply because of the relationship. They are seriously
considering creating a new language, with similar features but with an
infix syntax, and deprecating the existing prefix/sexpr syntax.

The problem is, this (IMO bad) idea has been tried before: Lisp
itself was intended to have an infix syntax, but McCarthy backed off
when existing Lisp programmers balked at using it. Apple's Dylan
language had a lot to offer, but died tragically when it changed from
a Scheme-like to an Algol-like syntax.

YMMV,
George

On 7/13/2021 1:03 AM, George Neuner wrote:
> On Mon, 12 Jul 2021 12:39:14 -0700, Stephen Fuld
> <sfuld@alumni.cmu.edu.invalid> wrote:
>
>> I had heard of Racket, but didn't know anything about it, so I did a
>> little reading.
>>
>> I think the issue to which you are referring is that Racket comes from
>> the Lisp, Scheme family of languages, this has more parentheses and uses
>> prefix notation when compared to the Fortran/C type syntax.
>>
>> For the record, my undergraduate degree was in Chemistry, so I have some
>> sympathy for the scientists/engineers.
>>
>> Without deprecating Racket in any way (I don't know enough to do that),
>> I disagree with you and agree with the "too many parentheses/prefix
>> notation" people.
>>
>> These people are not computer scientists, and while they are usually
>> smart people, they want to get some job in science/engineering done, and
>> want the easiest tool to use to do that. They don't particularly care
>> about some arcane aspects of the language they are using.
>>
>> They are familiar with formulas. They use them all the time in their
>> classes and in their work. Remember, Fortran is short for Formula
>> Translator. So a language that is similar to that is easier for them to
>> learn, thus a better choice. In that context, I don't regard their
>> disdain for Lisp style language syntax as "nonsense". They want to do
>> some job and not be distracted by unfamiliar syntax, etc.
>>
>> Thus I think Python is a good choice (not counting the 2-3 mess).
>
> A little off-topic, but ...
>
> Python is great for scripting - but I do /not/ think it is great for
> application programming. Particularly for science or engineering.
>
> One of the biggest tells is that most of its data processing libraries
> are written in C - not in Python. Whether simply for performance, or
> for the inability of the language to express the solution, many people
> have decided to bypass the language.

I took the existence of fast data processing libraries as a plus. :-)
That is, you use Python proper as glue to do minor minor formatting,
selection, etc. of data, but the "hard work" is done quickly in proven
library functions. I thought that was a typical use case for Python.

> So what happens when there is no library for what you want to do. Can
> you express your solution in Python? Yeah, probably ... but will it
> perform well enough when you point it at large amounts of data?
> Probably not.

Doesn't Python provide an option to output a C program, which is then
compiled and run? I view this as sort of an intermediate solution.
Faster than pure Python though not as fast as purpose written say C, but
easier to develop and test.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Tuesday, July 13, 2021 at 1:27:22 AM UTC-5, George Neuner wrote:
> On Mon, 12 Jul 2021 12:57:31 -0700 (PDT), MitchAlsup
> <Mitch...@aol.com> wrote:
>
> >On Monday, July 12, 2021 at 2:39:16 PM UTC-5, Stephen Fuld wrote:
> >
> >> These people are not computer scientists, and while they are usually
> >> smart people, they want to get some job in science/engineering done, and
> >> want the easiest tool to use to do that. They don't particularly care
> >> about some arcane aspects of the language they are using.
> >>
> >> They are familiar with formulas. They use them all the time in their
> >> classes and in their work. Remember, Fortran is short for Formula
> >> Translator. So a language that is similar to that is easier for them to
> >> learn, thus a better choice. In that context, I don't regard their
> >> disdain for Lisp style language syntax as "nonsense". They want to do
> >> some job and not be distracted by unfamiliar syntax, etc.
> >>
> >> Thus I think Python is a good choice (not counting the 2-3 mess).
> ><
> >For most of these kinds of "let us figure out how to solve the problem"
> >eXcel is a far better language than any std language.
> Or Mathematica, or SciLab, or some such.
>
> As Mitch notes, there is a big difference between exploration figuring
> out how to solve a problem, and writing an application that implements
> the solution.
>
And eXcel is ideal because of the ease of graphing the data, instant
updates, and exploring boundary conditions to see if your "math"
actually handles the extreme cases well.
>
> George

On 7/13/2021 3:03 AM, George Neuner wrote:
> On Mon, 12 Jul 2021 12:39:14 -0700, Stephen Fuld
> <sfuld@alumni.cmu.edu.invalid> wrote:
>
>> I had heard of Racket, but didn't know anything about it, so I did a
>> little reading.
>>
>> I think the issue to which you are referring is that Racket comes from
>> the Lisp, Scheme family of languages, this has more parentheses and uses
>> prefix notation when compared to the Fortran/C type syntax.
>>
>> For the record, my undergraduate degree was in Chemistry, so I have some
>> sympathy for the scientists/engineers.
>>
>> Without deprecating Racket in any way (I don't know enough to do that),
>> I disagree with you and agree with the "too many parentheses/prefix
>> notation" people.
>>
>> These people are not computer scientists, and while they are usually
>> smart people, they want to get some job in science/engineering done, and
>> want the easiest tool to use to do that. They don't particularly care
>> about some arcane aspects of the language they are using.
>>
>> They are familiar with formulas. They use them all the time in their
>> classes and in their work. Remember, Fortran is short for Formula
>> Translator. So a language that is similar to that is easier for them to
>> learn, thus a better choice. In that context, I don't regard their
>> disdain for Lisp style language syntax as "nonsense". They want to do
>> some job and not be distracted by unfamiliar syntax, etc.
>>
>> Thus I think Python is a good choice (not counting the 2-3 mess).
>
> A little off-topic, but ...
>
> Python is great for scripting - but I do /not/ think it is great for
> application programming. Particularly for science or engineering.
>
> One of the biggest tells is that most of its data processing libraries
> are written in C - not in Python. Whether simply for performance, or
> for the inability of the language to express the solution, many people
> have decided to bypass the language.
>
> So what happens when there is no library for what you want to do. Can
> you express your solution in Python? Yeah, probably ... but will it
> perform well enough when you point it at large amounts of data?
> Probably not.
>

Python performance tends to be relatively poor, even among dynamic
languages, from what I have seen...

>
>
> In contrast, most of Racket's libraries are written in Racket. In
> fact, most of Racket is written in Racket - there is only a small
> bootstrap core that still is C/asm.
>
> There is a portable bytecode interpreter, but on most platforms Racket
> applications are compiled: either JIT (long time), or in more recent
> versions with an AOT compiler.
>
> No disputing, Racket has a steeper learning curve than Python - but if
> there is no existing code that does what you want, you probably can
> write it in Racket and /still/ get good performance without dropping
> into a different langauge (which you can, Racket has a full featured
> FFI if you need it).
>
> And if you don't like the default Lisp/Scheme-like syntax or behavior,
> Racket is a perfect transpile target for DSLs. Racket provides a YACC
> work-alike, and a number of other parsers (LL and LR) are available as
> libraries. You can create a language using any syntax you like.
> Transpiled languages can be freely intermixed in the same program.
>
> There are a number of such DSLs already: Prolog, Java, Algol-60, ML,
> even Python [though I don't know which version or how complete it is].
> And many others.
>

Using a Scheme variant as a transpile target actually works reasonably
well. Writing code in it directly is usually less enjoyable though,
unless one is using the language in a way which can leverage its features.

It does suffer an disadvantage in that the syntax hinders putting in
various types of side-channel metadata, such as things like source file
and line number information, ... It also doesn't deal as well with
structures where a lot of members may be optional.

And, by the time one addresses the above issue, it has lost most of what
advantage it would have had over a more flexible format.

>
>
> For all that, Racket's developers are concerned that Lisp and/or
> Scheme has negative connotations and that people will avoid trying
> Racket simply because of the relationship. They are seriously
> considering creating a new language, with similar features but with an
> infix syntax, and deprecating the existing prefix/sexpr syntax.
>
> The problem is, this (IMO bad) idea has been tried before: Lisp
> itself was intended to have an infix syntax, but McCarthy backed off
> when existing Lisp programmers balked at using it. Apple's Dylan
> language had a lot to offer, but died tragically when it changed from
> a Scheme-like to an Algol-like syntax.
>

It is a tradeoff.

A more traditional syntax is generally easier to work with, but granted
a lot of Lisp style features will not work nearly as well with a
different syntax.

One of the main things it has going for it is the ability to work with
S-Expressions as data and then eval them or similar, or use them as part
of a procedural macro system, but this ability is quickly lost, and
doesn't map out nearly as well to a more opaque AST format.

This means that in a language with a more conventional syntax, an eval
mechanism generally needs to work with strings, and then often ends up
restricted (frequently a target of exploits; some of the major use-cases
for eval often adding glaring security holes).

In statically compiled versions of a language, eval is often either
unavailable, or operates within an interpreter with its own environment
often separate from that of the parent.

....

One could, in theory, have a language which uses a more familiar syntax
natively, but then switches over to a Lisp style syntax for
metaprogramming and eval, but this would be kinda wonky and weird.

>
> YMMV,
> George
>

On 7/13/2021 12:43 AM, Thomas Koenig wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>
>> In that context, he raises some interesting questions about the
>> reproducablily of science over long periods (decades).
>>
>> The obvious answer is to archive all the software he used, but that has
>> issues too. On what media? 40 years ago, the answer might have been 8
>> inch floppy disks. How would you read those now? Is it the scientists
>> responsibility to update the archives to newer media at an institution
>> where he may no longer? And what if he ran his program and got his
>> results on a Cray 1? Is it reproduceable now?
>
> The problem that he describes with Python are much more pressing than
> that :-)
>

It has been around long enough that one might have expected it would
have reached a certain level of "maturity", but alas...

>> There are issues about language/package choice over the long term. What
>> if the language is no longer supported and the existing compilers won't
>> run on any currently supported hardware?
>
> Absolutely, there are no absolutes, but this is a question
> of degree.
>
> But you can chose a deliberately moving platform like Python,
> or you can chose something inherently stable which is slow
> to introduce incompatibilities.
>
> In passing, Hingsen mentions a Fortran program written in 1994
> which "just runs". That matches my own experience with a couple
> of Fortran programs that I maintain at work.
>
> Or look at Netlib - these programs still work today on a modern
> Fortran compiler, many of them go back to the 1970s.
>
> I recently had occastion to need a reliable (and efficient) root
> finder. So I took an implementation of Brent's algorithm from
> Netlib, ran it through Nag Toolpack, itself a program from 1979,
> to bring its control structures up the to Fortran 77 standard
> including IF/THEN/ELSE, and started using it. Works flawlessly.
>
> The same could be said about C, although the compatibility going
> I would probably put the compatibility level at Ansi C - not
> sure what gotchas were introduced in the transition between
> K&R and Ansi. So, compatibility since the 1990s.
>

It varies, for 90s era C, I generally end up using a 2-stage porting
process:
First, get it working on MSVC;
Then get it working on GCC and Clang.

Porting 16-bit code (full of "far pointers" and the like) is often a
little more work, more so if it depends on hardware memory addresses and
working with IO ports. Then one has to largely rewrite this stuff.

Or, other wonky/fun features, like using the VGA in planar mode, where
the bits held in certain registers would modify which addresses map to
which bytes in video RAM, ...

Another source of annoyance is if the program was written to use EMS or
similar, ...

Bonus points is if it also has lots of out-of-bounds memory accesses,
which the program actually depends on in order to work correctly, ...

Though, it is possible that "code written for MS-DOS" is its own category.

A lot of late 90s code (32-bit flat model) is a lot easier to port.

>> Even not counting computers, what if I got my results on a Model X
>> Spectrometer, which is no longer made, the company that made it is out
>> of business, and all the ones sold are long gone? If the results on the
>> current Model Y spectrometer are different, did I mess up, or was it the
>> instrument?
>
> No need to go back into the past for that - especially when things
> are used for analytics, the results can be plain wrong.
>
> About 10 years ago, I was involved in a project where analytical
> results of a product made in the lab had some properties that were
> wery strange, and not what we wanted. We discussed this again
> and again in the meetings, tried to change the way the product
> was made. We saw changes, but the basic problem remained.
>
> Next thing, the external company told us that they had made a
> mistake in their analytic procedure, and suddenly things looked
> much more like what we expected.
>
> So, we had filled up all the tables with values which basically
> worthless. Avoiding cross-contamination of old and new data proved
> almost impossible. "Fortunately", what we had tried up to that
> point yielded worthless product properties anyway, so this was no
> big loss.
>
>> So, in summary, I think he is making too big a deal about the Python 2-3
>> mess, though it certainly is a problem,
>
> The other points are also important - for example scripts working
> for two to three years even in the absence of a major update.
>
> Again, this should be a reason not to use Python.
>
>> and it is one of a set of
>> potential problems much larger than what he is talking about.

> Python performance tends to be relatively poor, even among dynamic
> languages, from what I have seen...

Indeed, the main Python implementation is explicitly designed to be
"clean" rather than "fast", IIUC. Hence the 48bytes for a plain
old integer.

> Using a Scheme variant as a transpile target actually works reasonably
> well. Writing code in it directly is usually less enjoyable though, unless
> one is using the language in a way which can leverage its features.
>
> It does suffer an disadvantage in that the syntax hinders putting in various
> types of side-channel metadata, such as things like source file and line
> number information, ...

Might be true for Scheme, but Racket specifically addresses this issue
because instead of having your transpiler output a text file with
Scheme/Racket code in it (which loses the file&line info), it outputs
"syntax objects" (exactly like Scheme/Racket's macros) which preserve
the original source info. That also avoids the need to print only to
have the backend parse it back.

Of course, this only works if your transpiler is itself a Racket program.

Stefan