Sujet : Re: Command Languages Versus Programming Languages
De : bc (at) *nospam* freeuk.com (Bart)
Groupes : comp.lang.miscDate : 12. Nov 2024, 15:50:26
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vgvpvh$1kkgv$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14
User-Agent : Mozilla Thunderbird
On 12/11/2024 14:05, Janis Papanagnou wrote:
On 12.11.2024 10:53, Muttley@DastartdlyHQ.org wrote:
>
In which case I'd go with a statically typed language like C++ every time
ahead of a dynamic one like python.
Definitely!
I'm using untyped languages (like Awk) for scripting, though, but
not for code of considerable scale.
Incidentally, on of my children recently spoke about their setups;
they use Fortran with old libraries (hydrodynamic earth processes),
have the higher level tasks implemented in C++, and they do the
"job control" of the simulation tasks with Python. - A multi-tier
architecture. - That sounds not unreasonable to me. (But they had
built their system based on existing software, so it might have
been a different decision if they'd have built it from scratch.)
My last major app (now over 20 years ago), had such a 2-language solution.
It was a GUI-based low-end 2D/3D CAD app, written in my lower level systems language.
But the app also had an embedded scripting language, which had access to the app's environment and users' data.
That was partly so that users (both OEMs and end-users) could write their own scripts. To this end it was moderately successful as OEMs could write their own add-on applications (for example, to help design lighting rigs).
But I also used it exclusively for the GUI side of the application: menus, dialogs, cursor control, layouts, the simpler file conversions (eg. export my data models to 3DS format) while the native code parts dealt with the critical parts: the 3D maths, managing the 3D models the display drivers, etc.
The whole thing was perhaps 150-200Kloc (not including OEM or user programs), which was about half static/compiled code and half dynamic/interpreted.
(One of the original motivations, when it had to run on constrained systems, was to allow a lot of the code to exist as standalone scripts, which resided on floppy disks, and which ere only loaded as needed.)