From Newsgroup: comp.lang.misc
On 10/31/2025 10:17 AM, John Ames wrote:
On Fri, 31 Oct 2025 06:48:08 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
One mentioned COBOL (which for him was worse than Fortran), but nobody
thought of BASIC. I guess that is now so far in the past, many among
the interviewees wouldnrCOt even have any memories of using it ...
And/or that anybody using BASIC in a modern context is gonna be using something like FreeBASIC, which is a vastly improved and perfectly
reasonable little language compared to the early microcomputer BASICs.
In one project, I ended up implementing a BASIC dialect partly inspired
by early Unstructured BASIC dialects. Though, in this case, this was
more because it allowed writing an interpreter in roughly 1000 lines of C.
Though, I ended up extending it in some non-standard ways that didn't
really match up with either 80s BASIC, or the direction the language
went in the 90s.
But, the use-case I had didn't really need it to go in the 90s
direction, and keeping the interpreter small also did not favor going
that direction (where the 90s dialects more went in the direction of
trying to turn it into a more general purpose programming language).
It went from 80s style Unstructured BASIC to:
Unstructured BASIC, but with dynamic scoping and return values...
And, CSG / vector stuff.
Trying to do a clean up of the core idea of what it became, ended up
sorta like this:
https://pastebin.com/2pEE7VE8
Re: Javascript, it's true that a lot of improvements have been made to
it, but from a certain perspective it's all lipstick on a pig; there's
been so many things slapped on to paper over some poor initial design decisions or chase trends in web development over the years that at
this point it's a fossil shale of a language.
Did another recent experiment, where I tried stripping JS back to a
minimal core and implementing something "roughly kinda similar" but
trying to write the interpreter in a way that minimized line count.
Got something written in around 2700 lines of C (over around 3 days).
FWIW:
https://github.com/cr88192/bgbtech_misc/tree/master/vm_bs3l
This reuses a few ideas from the design of the BASIC dialect, in places
where it could save implementation complexity without trashing the
language design too much.
Was still lacking various language constructs (like "switch()"), but
alas. I also went with dynamic scoping, mostly because I can implement
dynamic scoping using less code than lexical scoping.
Also, absent additional analysis steps or similar, and thus code
complexity, full lexical scoping is prone to rapidly leak memory. The
main way to avoid the massive memory leak is to detect cases of
non-capture and either fall back to a C-like scoping model; or at least destroy the non-captured frames.
This is a non-issue with dynamic scoping, even if, potentially, using
dynamic scoping as the default is itself a foot gun (in terms of semantics).
Still not really well tested. I didn't have an immediate use-case so
more threw it together as a test/proof of concept.
It isn't really meant to be either well written, or particularly fast.
It parses an AST and then just sort of uses a tree-walking interpreter.
Ultimately, it is maybe kinda moot, as pretty much any language/interpreter/compiler that sees significant use is almost
invariably prone to turn into a bloated monstrosity.
There are also limits.
A while back, I had started an attempt to write a more traditional C
compiler (with a vaguely GCC like design), but also trying to keep it
under 30 kLOC (roughly a similar code footprint to the original version
of the Doom engine). Sorta stalled out the project when I noted that I
was already going to blow past this limit. I had also started to
question whether it even makes sense to use the traditional strategy
(or, using fully disjoint stages, producing native code object files,
and then running them through a linker).
My existing C compiler (that I use in my own projects) uses an approach
of first compiling to a stack-based IL, and then doing all of the native
code generation in what would-be the link stage. I am left suspecting
this may actually be a more sensible approach (with the frontend stages existing more to compile from the source language to the IL used by the backend).
I am also left to consider possible alternatives to C and C++. But, the
best idea I have at the moment (that would fit my uses) would be to make
a language sort of resembling a hybrid of C and C#. Though, some of the possible merits of such a language would be weakened if (for practical reasons) such a compiler is likely to also need to be able to accept
plain old C. The main argument in favor is that "C-like with some C#
stuff glued on" being simpler/cheaper to implement than an actual C++ compiler.
Though, some cost notable savings would be possible by the compiler
either not supporting C, or only supporting a restricted subset of C
(maybe going as far as only allowing C code which is the least common denominator of both languages).
Might be nice if one can have a compiler that:
Can generate reasonably efficient native code binaries;
Supports a more advanced OO language as well as a C like use cases;
Fits the whole compiler / "toolchain" in under 100K lines.
Where, 30K lines may be unrealistic, but at least 100K.
My existing compiler is around 250K lines, bigger than i would like.
Still pretty small though if compared with GCC or Clang, which both
weigh in in well into MLOC territory (and Clang basically wrecking my PC trying to build it). Like, even if it is good/fancy/whatever, not
inclined to try to compile something where compiling the compiler brings
my PC to its knees for multiple hours at a time.
I much prefer working on a compiler where the rebuild time is around 5
seconds or so (or, around 30 seconds if building it with GCC).
Like, seriously, we don't need the C and C++ compilers to be like "The
One Ring": "One compiler to build them all! One compiler to link them!"
Nor, the PC equivalent of "Forged in the fires of Mt. Doom", namely
multi-hour build times for said compiler...
Well, and if one is like, "Well, does your compiler generate better code
than GCC or Clang, or target all of the same types of machines?", I can
be like, "This is missing the point."
More often it matters that a compiler exists, rather than which compiler
it is, or even whether or not it is the "best" compiler (more "a
compiler exists", and "preferably not complete garbage").
But, then the problem with C++ exists, that it is too much of a pain to
write a C++ compiler, so inherently it becomes a choice-limiting issue.
Ideally, one needs a language which can serve a similar role, but for
which writing a compiler for it is less of a nightmarish undertaking.
Well, and where the choice is not also "just use C".
Well, in a similar way:
Implementing a small JS like interpreter in 2700 LOC, stands no chance
of replacing something like SpiderMonkey or V8, but expecting it would
do so would also be missing the point.
There are use-cases where one may want a small (if slow) interpreter,
and where throwing some 500 kLOC beast of a VM at the problem is not an
ideal strategy.
Anyway, there's things to dislike about most any language, but there
aren't too many that I'd universally condemn in my own assessment.
Pascal gets a frowny-face for design decisions that should never, ever
have made it past the initial draft of the first paper (making array
size part of the type specification was braindead from the start - an impediment to good design *and* a burden on performance, all in the
name of avoiding a problem that there were much better solutions for,)
and while newer iterations have improved things somewhat, it would've
been better to throw it out and re-do from scratch...*but* the FP folks
do put a lot of effort into making it a full-featured and surprisingly portable platform for development.
Another language that feels needlessly gross and tedious is Java - it's
just *unreasonably* verbose, to the point where one is tempted to
employ a macro preprocessor just to condense sesquipedalian nonsense
like System.out.println() down to furshlugginer print() and so forth.
Any language that *requires* an IDE with weapons-grade autocomplete
deserves censure...but then it's somehow still the best solution we've
got for write-once-run-anywhere development, which is maddening :/
Agreed, even as someone who had before designed/implemented a Java-like language...
Well, there are reasons my current leaning would be to start from a base
more resembling C#. In some ways, its design points make more sense
(even if seemingly some of its choices look more like "take Java and
make it look more like C++").
For API design, probably makes some sense to stick close to a C like
approach when possible. Like, try to aim for a "minimal but effective"
API design, not so much the "try to micro-manage every possible thing a
person might want to do in the language" approach that Java had used
(while at the same time making it needlessly verbose to actually use
said interfaces).
Maybe also don't try to design the language with the seeming starting assumption that all the programmers are stupid and can't figure out how
to do anything on their own; ...
Though, granted, a custom non-standard C# like language, absent
widespread adoption, would not likely achieve a WORA like goal.
...
--- Synchronet 3.21a-Linux NewsLink 1.2