Re: Portable Software (was: fledgling assembler programmer)

gah4 <gah4@u.washington.edu> schrieb:


> For system like Matlab and Octave, and I believe also for Python,
> or one of many higher math languages, programs should spend
> most of the time in the internal compiled library routines.


They should, but sometimes they don't.


If you run into things not covered by compiled libraries, but which
are compute-intensive, then Matlab and (interpreted) Python run
as slow as molasses, orders of magnitude slower than compiled code.


As far as the projects to create compiled versions with Python
go, one of the problems is that Python is a constantly evolving
target, which can lead to real problems, especially in long-term
program maintenance. As Konrad Hinsen reported, results in
published science papers have changed due to changes in the Python
infrastructure:


http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/


At the company I work for, I'm told each Python project will only
use a certain specified version of Python will never be changed for
fear of incompatibilities - they treat each version as a new
programming language :-|


To bring this back a bit towards compilers - a language definition
is an integral part of compiler writing. If


- the specification to o be implemented is unclear or "whatever
    the reference implementation does"


- the compiler writers always reserve the right for a better,
    incompatible idea


- the compiler writers do not pay careful attention to
    existing specifications


then the resuling compiler will be of poor quality, regardless of
the cool parsing or code generation that go into it.


And I know very well that reading and understanding language
standards is no fun, but I'm told that writing them is even
less fun.

Return to the comp.compilers page.
Search the comp.compilers archives again.