DOS ain't dead

> > How is this limited and adhoc?
> > What is really the problem you need to solve?
> > What is it that these can't do?
>
> I was mainly just thinking out loud to myself about various things
> (portability, extensibility, maintainability).
>
> Native binary compilation is smaller and faster when you know
> exactly what you want. But it's also an unmodifiable black box, too
> specific, not generic enough. You know, the advice "Just rebuild the entire
> app!" is quite naive and not always easy. (For reasonably small DOS
> programs, maybe. But you know what I mean. It's not extensible.) So I was
> mostly wondering about a scripting tool to do the same, where only the
> script text needs changing.

Scripting vs precompiling is always a battle of freedom vs control.

Compiled binaries usually have much lower dependencies. Scripting languages are in theory portable, but platform details, interpreter versioning often also take their toll.

I've always leaned more towards compiling, with sometimes a small interpreter integrated for some minor application internal scripting.

But I'm a software developer, if you are more a systems administrator/maintainer or DBA, the tradeoffs are probably different

As a software developer and I start out with deep compiled language knowledge and installed compilers. So I do a lot in Delphi/FPC what other people would do in scripting, just to avoid having to keep up with another language for relative minor stuff. I do still use scripting, but it is fairly basic stuff in whatever the systems preinstalled interpreter is (batch or shell script). More sequencing steps than really solving problems/programming.

When I was more a sysadmin in the early 2000s, I did a lot more in scripting languages (kix and vbs mostly and a bit of shell script on Linux and Solaris).
Most were fairly small (2000 lines) system startup scripts to map drives etc.

But every time I let scripts grow too big has been a disappointment to me, usually interpreter difficulties (script X only works with Perl 5.000028 but not with 5.000030 etc), slow improvements, increasing deployment sizes of the interpreters, major version transitions that change the language quite deeply (Python 2->3, perl5->6) being the core problems. Also some scripting languages are horribly Unix centric, and real good Windows scripting languages often don't even exist for *nix.

My absolute worst programming experience ever keeping a (admittedly huge) Perl script running.

> Using inline asm is like a cheat. You can do anything. At that point you
> might as well almost use (only) raw assembly and not a HLL.

One counterpoint doesn't invalidate the argument. Why? Because on average you still mostly work in HLL and not raw assembler, so overall productivity and bugrates are more HLL than ASM.

Moreover, any direct hardware access is dangerous anyway, so doing that in assembler is not necessarily less safe or more portable than doing it in HLL. Just because it in HLL doesn't make something unsafe safe.

>(Mild
> exaggeration, obviously wrong, but you know what I mean: it's very
> vendor/OEM/machine specific, maybe OS specific, maybe even compiler
> specific. Not good. Wirth suggests separating all non-portable SYSTEM stuff
> into separate modules.)

Yes. That is related to the point above. Isolate the code with different tradeoffs from the generic code, so you have less code to review if there are problems. Or to rewrite if you change OS.

It doesn't mean that that makes porting guaranteed easy, but it is better than not having any care at all.

>
> I forgot that you could just write a simple DEBUG script or maybe a small
> (turnkey?)

One could argue that is not a script but a compiled language with debug being an assembler that merely executes.

A bit like instantfpc that allows you to run Pascal source files as script under *nix. The unix shell calls instantfpc as interpreter which simply compiles and then executes the binary from some temp dir.

> Forth
> app. That has some interactivity that I was wanting without being
> completely closed and hidden, without being huge and requiring megabytes of
> non-standard compiler bloat just to fix, extend, or rebuild.

So where are the huge Forth codebases? Afaik Forth emerged as a kind of "tighter than asm" scripting language for e.g. BIOS/firmwares (particularly Open Firmware), but with rising flash sizes than went the way of the dodo.

> P.S. This is not a complaint against TP versus other languages or
> implementations or an argument of compilers versus interpreters. If
> anything, I wonder about writing such an interpreter in TP! I'm just
> comparing various ways of doing low-level stuff for DOS. If possible, one
> should use already-available scripting languages pre-installed with the OS
> for optimal deployment, no? QBASIC at least used to be pre-installed, same
> with (DOS) DEBUG. Not sure if PC-DOS' REXX could handle such low-level
> stuff, though.

Well besides compilers vs interpreters this hits much more "general languages" vs "domain specific languages". The latter are often scripting languages for one specific purpose.

You can e.g. imagine port I/O in a scripting language that is mainly used for hardware detection on Dos. Then you can just share the detection routines as text.

But e.g. a game interpreter that requires it for vertical refresh sync, it makes much more sense to not make port I/O part of the language, but just "wait for vertical refresh".