Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #11470 > unrolled thread

What’s Your Least Favourite Programming Language?

Back to article view | Back to comp.lang.misc

Contents

  What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-31 06:48 +0000
    Re: What’s Your Least Favourite Programming Language? David Brown <david.brown@hesbynett.no> - 2025-10-31 13:28 +0100
    Re: What’s Your Least Favourite Programming Language? John Ames <commodorejohn@gmail.com> - 2025-10-31 08:17 -0700
      Re: What’s Your Least Favourite Programming Language? bart <bc@freeuk.com> - 2025-10-31 22:47 +0000
      Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-01 06:26 +0000
      Re: What’s Your Least Favourite Programming Language? BGB <cr88192@gmail.com> - 2025-11-03 14:05 -0600
        Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-03 20:29 +0000
          Re: What’s Your Least Favourite Programming Language? BGB <cr88192@gmail.com> - 2025-11-03 14:55 -0600
            Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-03 23:10 +0000
              Re: What’s Your Least Favourite Programming Language? BGB <cr88192@gmail.com> - 2025-11-04 12:02 -0600
                Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-04 20:32 +0000
        Re: What’s Your Least Favourite Programming Language? John Ames <commodorejohn@gmail.com> - 2025-11-03 15:56 -0800
      Re: What’s Your Least Favourite Programming Language? Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-27 21:11 -0300
        Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 04:42 +0000
          Write Once, Run Anywhere (was Re: What’s Your Least Favourite Programming Language?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-28 16:43 -0300
            Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 22:37 +0000
              the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-28 20:27 -0300
                Re: the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 01:30 +0000
                  Re: the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-29 15:24 -0300
                    Re: the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 21:57 +0000
              Python deliberately breaking backward compatibility (was Re: What’s Your Least Favourite Programming Language?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-28 21:03 -0300
                Re: Python deliberately breaking backward compatibility (was Re: What’s Your Least Favourite Programming Language?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-28 18:10 -0700
                  [meta] Date-formats in postings (was Re: Python deliberately breaking backward compatibility (was Re: What’s Your Least Favourite Programming Language?)) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-29 06:39 +0200
                Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 01:42 +0000
        Re: What’s Your Least Favourite Programming Language? John Ames <commodorejohn@gmail.com> - 2026-08-28 09:59 -0700
    Re: What’s Your Least Favourite Programming Language? Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-27 20:09 -0300

Page 1 of 2  [1] 2  Next page →

#11470 — What’s Your Least Favourite Programming Language?

As their soundcheck question for 2024, Computerphile asked their
interviewees what their least favourite programming language was
<https://www.youtube.com/watch?v=03lRzf7iSiU>.

The most popular answer was JavaScript, with 4 votes. There were 2
votes for PHP, and one each for Lisp and Python.

The Python-hater didn’t like dynamic typing. Given how many
dynamically-typed languages there are (including lots older than
Python), how come Python was the first one he thought of?

As for JavaScript, I think it’s misunderstood. The only one who gave a
reason for his dislike gave an outdated reason -- scope hoisting. That
doesn’t have to apply any more, if you avoid “var” declarations, and
also use strict mode to avoid implicit globals.

I imagine PHP would have got more votes, if more people had had to use
it.

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 wouldn’t even have any memories of using it ...

[toc] | [next] | [standalone]

#11473

On 31/10/2025 07:48, Lawrence D’Oliveiro wrote:
> As their soundcheck question for 2024, Computerphile asked their
> interviewees what their least favourite programming language was
> <https://www.youtube.com/watch?v=03lRzf7iSiU>.
> 
> The most popular answer was JavaScript, with 4 votes. There were 2
> votes for PHP, and one each for Lisp and Python.
> 
> The Python-hater didn’t like dynamic typing. Given how many
> dynamically-typed languages there are (including lots older than
> Python), how come Python was the first one he thought of?
> 
> As for JavaScript, I think it’s misunderstood. The only one who gave a
> reason for his dislike gave an outdated reason -- scope hoisting. That
> doesn’t have to apply any more, if you avoid “var” declarations, and
> also use strict mode to avoid implicit globals.
> 
> I imagine PHP would have got more votes, if more people had had to use
> it.
> 
> 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 wouldn’t even have any memories of using it ...

I suppose it is all about which languages people know and use.  It would 
be unreasonable to answer "Brainfuck", given that very few people have 
written code in it.  (I expect more people have written Brainfuck 
interpreters than programs in Brainfuck.)

So for the Python-hater, Python was presumably the only dynamically 
typed language they used.  And very few people these days have much 
experience with COBOL.

Did you have a "least favourite" language yourself?

[toc] | [prev] | [next] | [standalone]

#11474

On Fri, 31 Oct 2025 06:48:08 -0000 (UTC)
Lawrence D’Oliveiro <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 wouldn’t 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.

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.

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 :/

[toc] | [prev] | [next] | [standalone]

#11475

On 31/10/2025 15:17, John Ames wrote:
> On Fri, 31 Oct 2025 06:48:08 -0000 (UTC)
> Lawrence D’Oliveiro <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 wouldn’t 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.
> 
> 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.
> 
> 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.

Zig is worse ('i' is an integer):

   const std = @import("std");

   std.debug.print("{} {}\n", .{i, @sqrt(@as(f64, @floatFromInt(i)))});


This is the equivalent of this in mine:

   println i, sqrt(i)

[toc] | [prev] | [next] | [standalone]

#11477

On Fri, 31 Oct 2025 08:17:42 -0700, John Ames wrote:

> 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.

I don’t think it is. It has lexical binding, and functions as
first-class objects! So has Python, but what else can you name that
has that? Strict mode and let/const-in-place-of-var lets you get rid
of a lot of the boneheadedness. The statement-continuation rule is
weird, but manageable.

My main use of it has been in web pages, where I maybe write a few
hundred lines of it at a time, commonly less. From a recent bit of
fun I did for a friend, here is the setup of column headings for
a table of data that are clickable to set the table sort order:

    const row = document.createElement("tr")
    const cell = document.createElement("th")
    cell.textContent = ""
    row.appendChild(cell)
    let fieldindex = 0
    for (const name of fieldnames)
      {
        const cell = document.createElement("th")
        const sortbut = document.createElement("button")
        sortbut.setAttribute("onclick", "mymod.set_sort_order(" + fieldindex.toString() + ")")
        sortbut.textContent = name
        cell.appendChild(sortbut)
        row.appendChild(cell)
        ++fieldindex
      } /*for*/
    thead.appendChild(row)

Here’s the function that sets the sort order (note the use of lexical
binding):

    function set_sort_order(fieldindex)
      /* Note that each change of sort order is applied on top of
        the previous sort order. To start again from the default
        ordering, refresh the page. */
      {
        if (sortcol != fieldindex)
          {
            sortcol = fieldindex
            fieldvalues.sort
              (
                function (a, b)
                  {
                    const fieldtype = fieldtypes[fieldindex]
                    const conv = sort_conv[fieldtype]
                    const key_a = conv(a[fieldindex])
                    const key_b = conv(b[fieldindex])
                    return key_a < key_b ? -1 : key_a > key_b ? 1 : 0
                  } /*function*/
              )
            load_page()
          } /*if*/
      } /*set_sort_order*/

See the reference to that “sort_conv” table? It is keyed off a column
type, to define the appropriate sort order for that column. For
example, a column of quarterly dates has values like “Q3'23” and
“Q1'24”, and you want the former to sort before the latter. In a
column of numbers with units, you want a value beginning “2G” to sort
before one beginning “100M”. And so on.

[toc] | [prev] | [next] | [standalone]

#11496

On 10/31/2025 10:17 AM, John Ames wrote:
> On Fri, 31 Oct 2025 06:48:08 -0000 (UTC)
> Lawrence D’Oliveiro <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 wouldn’t 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.

...

[toc] | [prev] | [next] | [standalone]

#11498

On Mon, 3 Nov 2025 14:05:12 -0600, BGB wrote:

> Also, absent additional analysis steps or similar, and thus code
> complexity, full lexical scoping is prone to rapidly leak memory.

You mean, you need to put call frames on the heap, not the stack? And
that will expose any lack of robustness in your memory-management
scheme?

By the way, Python is clever enough to only put referenced outer-level
variables within the closure.

> 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).

This sounds like a “I could implement it much more efficiently if I
didn’t have to do it correctly” kind of argument ...

[toc] | [prev] | [next] | [standalone]

#11500

On 11/3/2025 2:29 PM, Lawrence D’Oliveiro wrote:
> On Mon, 3 Nov 2025 14:05:12 -0600, BGB wrote:
> 
>> Also, absent additional analysis steps or similar, and thus code
>> complexity, full lexical scoping is prone to rapidly leak memory.
> 
> You mean, you need to put call frames on the heap, not the stack? And
> that will expose any lack of robustness in your memory-management
> scheme?
> 

Yes.

Minimal memory management: Don't bother with GC;
Minimal handling of lexical closures: Just put the frames of the heap, 
capture them if a closure is created, don't bother with case of closure 
not being created.

But, this is a bad scenario, as it results in an explosively bad memory 
leak...


> By the way, Python is clever enough to only put referenced outer-level
> variables within the closure.
> 

Yes, but:
Detecting which variables are captured, or whether or not there is 
capture or non-capture, is the "additional analysis steps" thing...


Likewise, the cheaper option is using a per-frame flag for 
capture-vs-non-capture (frame is freed if the "frame was captured" flag 
is not set). Still though, this is more code complexity than not using 
lexical scoping in the first place.


Like, dynamic scoping doesn't need frames that may or may not be 
captured, can just put all of the variables onto a stack and push/pop 
this stack position per-frame.


>> 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).
> 
> This sounds like a “I could implement it much more efficiently if I
> didn’t have to do it correctly” kind of argument ...

It is cheap and simple...

But, one thing it is not, is semantically equivalent to lexical scoping.


Some of my past languages had both lexical and dynamic scoping (with 
lexical as the default). This can make more sense.

But, as noted, the goal in the case of this interpreter was to use less 
code, and probably would have needed to spend maybe an additional 300 
lines of code or similar to have added support for lexical scoping (that 
wouldn't just immediately leak all the RAM).

...

[toc] | [prev] | [next] | [standalone]

#11503

On Mon, 3 Nov 2025 14:55:31 -0600, BGB wrote:

> Some of my past languages had both lexical and dynamic scoping (with 
> lexical as the default). This can make more sense.

Dynamic binding simply isn’t that useful. Lexical binding just works more 
naturally the way people expect.

[toc] | [prev] | [next] | [standalone]

#11521

On 11/3/2025 5:10 PM, Lawrence D’Oliveiro wrote:
> On Mon, 3 Nov 2025 14:55:31 -0600, BGB wrote:
> 
>> Some of my past languages had both lexical and dynamic scoping (with
>> lexical as the default). This can make more sense.
> 
> Dynamic binding simply isn’t that useful. Lexical binding just works more
> naturally the way people expect.


I am not saying that Dynamic is preferable to Lexical by any means, from 
a semantics POV, but if the goal is to implement a semi-practical 
interpreter while also using less code (and with less risk of memory 
leaks), it can make sense.


There are a few contexts where dynamic scoping can be useful as well, 
just usually not as the default.

Say, for example, if you had something analogous to stdin/stdout as 
dynamically scoped variables, then it makes IO redirection easy. 
Likewise for other sorts of state that (in C) are often held in global 
variables.


They can also serve a similar role as TLS variables (though, in a more 
advanced compiler, they were usually implemented as an additional local 
save/restore mechanism on top of TLS variables). In this case, the role 
of dynamic variables can be overloaded to that of TLS variables.

One can debate how to best specify it.
   dynvar x;             //one possibility for a language like this
                         //if 'var' became lexically scoped
   dynamic var x;        //my original script language
   dynamic int x;        //BS2
   __dynamic int x;      //In C mode in BGBCC
   _Thread_local int x;  //does basically same thing as __dynamic here

Can note that C normally uses a 2-level scope scheme:
   Global variables;
   Local Variables;
   In this case, lambdas could either capture by-reference or by value.

In this case, a C-like scoping model could also be implemented in 
relatively little additional code (probably with lambdas just bulk 
copying all the captured local variables; could ignore both dynamic and 
global variables if going to a C-like model).

At the moment, "function()" doesn't capture anything.



Though, if I get around to it, lexical scoping and "switch()" would 
probably be pretty high on the "makes sense to add" list.

Though, the handling of switch would probably also be "kinda crap":
Just walk downwards, skipping lines until the correct case label is 
encountered, then start running until a "break;" or "return();" is 
encountered.


May also need to implement some form of memory management. Most likely 
options ATM are slabs and zone allocation. A traditional garbage 
collector would be asking too much here, and reference counting is a pain.

In a zone allocator, likely any newly created objects would be initially 
in an "eval" zone, and when assigned to a global variable (or into an 
object in the "global" zone) would be re-tagged as global (with a 
graph-walk to also re-assign any pointed to objects). Once eval 
terminates, any variables still in the eval zone are destroyed.

Would likely use a zone tagging scheme similar to that used in the Doom 
engine, where lower-numbered zones are "more global" (so zone promotion 
merely sets it to the lowest number).


Still, TBD.

...

[toc] | [prev] | [next] | [standalone]

#11526

On Tue, 4 Nov 2025 12:02:22 -0600, BGB wrote:

> Say, for example, if you had something analogous to stdin/stdout as
> dynamically scoped variables, then it makes IO redirection easy.

A better technique would be to save the current values of stdin and 
stdout, substitute different I/O streams during the execution of the inner 
code, then restore the outer values before returning. Offers better 
control and generalizes more readily.

> They can also serve a similar role as TLS variables (though, in a more
> advanced compiler, they were usually implemented as an additional local
> save/restore mechanism on top of TLS variables). In this case, the role
> of dynamic variables can be overloaded to that of TLS variables.

Now you’re trying to justify one mechanism by mixing it up with a 
different one.

[toc] | [prev] | [next] | [standalone]

#11505

On Mon, 3 Nov 2025 14:05:12 -0600
BGB <cr88192@gmail.com> wrote:

> > 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).

Yeah, there've been a number of odd little one-off BASICs over the
years. ASIC was one that struck me as particularly kooky - a shareware
implementation that could compile to COM/EXE, but which lacked a number
of operators/control structures :/

https://en.wikipedia.org/wiki/ASIC_programming_language

[toc] | [prev] | [next] | [standalone]

#11835

John Ames <commodorejohn@gmail.com> writes:
> Another language that feels needlessly gross and tedious is Java -
> (...) but then it's somehow still the best solution we've got for
> write-once-run-anywhere development, which is maddening :/

I think that may have been true around 02001, when J2ME could run more
or less normal Java code on *all kinds* of fairly small feature phones.
But it never made the leap to smaller microcontrollers like the AVR,
feature phones evaporated, feature-phone-sized microcontrollers never
acquired J2ME support, and now in 02026 we have a number of better
solutions: C under Unix, portable C, Rust, Python, JavaScript, Wasm,
Godot, and Golang.

(In the following, by “Unix” I mean GNU/Linux, FreeBSD, and similar
systems, but not Android, Microsoft Windows, macOS, iOS, or System/360.)

- C under Unix, because you can run QEMU on just about anything that
  runs Java.  If you run Microsoft Windows, it ships with WSL2, so this
  works out of the box.  Unless you want a GUI, in which case you still
  probably want to run QEMU.

  Android might be the main exception; it ships with an incompatible
  implementation of Java (without, for example, AWT), and although you
  may be able to recompile Unix software for it, it can be difficult.
  I’m currently trying out the “Limbo x86 PC Emulator” QEMU package from
  F-Droid, and I’ve gotten SeaBIOS to complain that it can’t find an OS
  image, but I haven’t gotten Linux to boot in it yet.

  Unix doesn’t run on small microcontrollers, but C sure does.  With
  sdcc you can even run it on a PIC or an 8051, though you wouldn’t want
  to.

- Portable C, for example with wxWindows or Qt.  For libraries rather
  than applications, this has historically been a much better choice
  than Java, because you can call it through FFIs from other languages.
  Of course, you can also write nonportable C, but you don’t have to.

  WORA applications written this way (and in portable C++) historically
  vastly outnumbered WORA applications written in any other way,
  including Java, but now JS has taken the crown.

- Rust seems as easy as C to call through FFIs, and it’s almost as
  portable, and significantly less error-prone.  It seems uglier and
  clumsier, though, and its support on microcontrollers is rocky and
  unpredictable.

- Python, which ships with somewhat adequate web server support, and
  Tkinter, which is a somewhat adequate GUI library.  It’s relatively
  easy to write a Python program (GUI, command-line, or HTTP server) and
  have it run consistently on Unix, Microsoft Windows, or macOS; and
  lots of Python libraries can also run on microcontrollers with
  MicroPython/CircuitPython.

  As with C, you can write nonportable Python, but there’s much less
  temptation to do so, because the portable standard-library API is
  significantly more complete, including things like filesystem access,
  multithreading, asynchronous I/O, and Tkinter.

  This is a much less compelling choice in the last several years since
  the Python maintainers have adopted a policy of deliberately breaking
  standard library backward compatibility in every point release.

  WORA GUI applications written in Python include Calibre, and there are
  a vast number of WORA applications that run as web services.

- JavaScript reduces the barrier for running your software on any
  cellphone or other personal computer about as far as possible — just
  click on a link, and your JavaScript application starts running.  The
  performance isn’t as bad as you’d expect, although JS authors
  habitually squander performance, and the text handing isn’t nearly as
  bad as Python’s or C’s.

  This has been the overwhelmingly most popular choice for WORA for the
  last 15 years.

  JS has the unique advantage that you get portable access to not just a
  basic GUI library, but platform features like 3-D acceleration,
  multitouch, cameras, audio input and output, a form of internet access
  (though not plain sockets), the clipboard, and NFC (except on iOS).

  The browser console and inspector also represent a kind of live
  interactivity and debuggability that is really lacking in Java, C,
  Rust, or even Python (though a Jupyter-style notebook interface would
  improve the browser console further.)  This is a huge advantage for JS
  in my book.

  Microcontroller-capable JS engines include Moddable (XS) and
  MicroQuickJS; maybe also Duktape, JerryScript, MuJS, and Hermes, but
  I’m not sure.  And JS is maybe the most popular language for writing
  HTTP server apps in with Node and Deno.  I don’t think there’s a
  Tkinter-like option for writing non-browser GUI apps, unless you count
  Electron, which is basically just a browser without an address bar.

  People who hate dynamic typing will appreciate TypeScript, a
  statically-typed dialect of JS.

- Wasm (WebAssembly) also runs in all the mainstream browsers, as well
  as some non-browser runtimes, and it’s a much easier compilation
  target for things like C than JS is, and gets much better performance
  as well, like, double-digit percent overhead rather than
  small-integer-multiple overhead.  It doesn’t support multithreading
  (or, it sort of supports multithreading if you bend over backwards
  enough — Godot 4 supports this option, but you have to configure your
  web server specially).

  You can compile just about anything to Wasm that you can compile to
  native code, using Emscripten, which uses LLVM.  But, when it’s
  running in browsers, you rely on JavaScript for access to any platform
  APIs.  This can be annoying, but it isn’t really that restrictive,
  since JS has access to 53 tonnes of platform APIs, as mentioned above.

- The Godot game engine, like C, Rust, and Python, doesn’t have any
  artificial sandbox limitations like Wasm, JS, and Java, and games
  written in it tend to run unchanged across Unix, macOS, Android, iOS,
  Wasm, and even Microsoft Windows, even when they use advanced
  graphical capabilities like custom 3-D shaders.  The development
  environment is also “live” in a way that exceeds even JS’s liveness.

  (There’s also very limited support for something called “visionOS”.)

  Godot 3 can export to single-threaded Wasm that can be run from any
  web server, but Godot 4 requires you to configure the web server in a
  weird way so that Wasm can implement a sort of multithreading.

- Golang, like Python, has an API that’s significantly more stable
  across platforms than C’s, and unlike Python, it isn’t totally
  screwing the pooch when it comes to text handling and library API
  stability.  It has much better performance than Python or JS, and is,
  to my eyes anyway, more readable.  Because of its Plan9 heritage,
  cross-compiling for multiple platforms is trivial, but I don’t think
  it supports small microcontrollers at all.

  I’ve never heard of a successful Golang GUI app (it’s used almost
  exclusively on web servers) but apparently there’s a Golang widget
  toolkit now called Fyne, which supports Android, iOS, Unix, and
  Microsoft Windows.

The above probably isn’t news to most people reading this post, unless I
got something wrong, in which case please correct me in the traditional
Usenet fashion.

Kragen

[toc] | [prev] | [next] | [standalone]

#11839

On Thu, 27 Aug 2026 21:11:55 -0300, Kragen Javier Sitaker wrote:

> I think that may have been true around 02001, when J2ME could run
> more or less normal Java code on *all kinds* of fairly small feature
> phones.

Google didn’t use J2ME for Android because it had an inadequate
protection model, and also Oracle were demanding too much money for
it.

But J2SE was available in an open-source form, namely OpenJDK. So they
adapted that instead.

> Android might be the main exception; it ships with an incompatible
> implementation of Java (without, for example, AWT), and although you
> may be able to recompile Unix software for it, it can be difficult.

You can run regular Linux distros under Android now.

> Unix doesn’t run on small microcontrollers, but C sure does. With
> sdcc you can even run it on a PIC or an 8051, though you wouldn’t
> want to.

How about a Unix-like system that runs on a Z80 microprocessor:
<https://www.dougbraun.com/uzi.html>.

> This is a much less compelling choice in the last several years
> since the Python maintainers have adopted a policy of deliberately
> breaking standard library backward compatibility in every point
> release.

In what way?

[toc] | [prev] | [next] | [standalone]

#11844 — Write Once, Run Anywhere (was Re: What’s Your Least Favourite Programming Language?)

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Thu, 27 Aug 2026 21:11:55 -0300, Kragen Javier Sitaker wrote:
>> I think that may have been true around 02001, when J2ME could run
>> more or less normal Java code on *all kinds* of fairly small feature
>> phones.
>
> Google didn’t use J2ME for Android because it had an inadequate
> protection model, and also Oracle were demanding too much money for
> it.

Yes, although J2ME is notable for what it *did* achieve, there were
excellent reasons for Google not to use it.

> But J2SE was available in an open-source form, namely OpenJDK. So they
> adapted that instead.

With respect, I think you may have gotten this wrong.  Originally they
used Apache Harmony (presumably they preferred its non-copyleft
licensing) but switched to OpenJDK in 02016 in response to the Oracle
lawsuit
<https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/>

>> Android might be the main exception; it ships with an incompatible
>> implementation of Java (without, for example, AWT), and although you
>> may be able to recompile Unix software for it, it can be difficult.
>
> You can run regular Linux distros under Android now.

I have to admit I badly blurred the clear distinction I was trying to
draw between “portable C” and “C under GNU/Linux [as opposed to Android,
which is also Linux], FreeBSD, and similar”.

What I was trying to say is that Android is not, itself, a “Unix” — in
the sense that you cannot realistically recompile Inkscape, Blender,
Audacity, or KiCad for it; you have to either do a port, or use some
kind of emulation layer, like Limbo, or like Google’s new carpetbagger
thing.

>> Unix doesn’t run on small microcontrollers, but C sure does. With
>> sdcc you can even run it on a PIC or an 8051, though you wouldn’t
>> want to.
>
> How about a Unix-like system that runs on a Z80 microprocessor:
> <https://www.dougbraun.com/uzi.html>.

Have you tried porting things like Emacs, GCC, ircII, or Inkscape to
UZI?  How do you do fork() without an MMU — write the entire contents of
memory out to disk, like PDP-7 Unix did?

There have been some Z80-compatible small microcontrollers, but
surprisingly few.  The Z80 itself didn’t include any on-chip RAM or ROM,
disqualifying it from the “microcontroller” moniker, and also required
some 500mW and had no low-power sleep, disqualifying it from
battery-powered handheld applications.  Even the TRS-80 Model 100 ended
up using the Intel 80C85 instead.

Dmitry Grinberg did boot GNU/Linux on an 8-bit AVR
<https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit> by
writing an ARM emulator for the AVR, but he said that it “was too slow
to be practical” with a boot time of 6 hours.  The AVR is roughly 50
times faster than a Z80.

(He also built a Linux-running business card around a 48MHz ARM
<https://dmitry.gr/?r=05.Projects&proj=33.%20LinuxCard> and booted Linux
even more slowly on a 4004 emulating a MIPS CPU
<https://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004>.)

Contiki is closer, but not very Unix-like.

>> This is a much less compelling choice in the last several years
>> since the Python maintainers have adopted a policy of deliberately
>> breaking standard library backward compatibility in every point
>> release.
>
> In what way?

They call it “removing dead batteries from the standard library”,
PEP 594 <https://peps.python.org/pep-0594/#rationale>, a document which
struggles to make sense as anything other than satire.  I wrote a longer
comment about this last year at
<https://news.ycombinator.com/item?id=44477966>.  Historically, you
could write apps for Python and run them in a pretty wide range of OSes
without touching the source code, but, since the adoption of this
planned-obsolescence policy, now you can’t even reliably run them on
consecutive releases of the same OS.

This makes it easy to encounter situations like this poster about
KittenTTS did, who says all of their Python versions on their various
machines are either too old or too new:
<https://news.ycombinator.com/item?id=44808718>

Contrast the stance of the Golang development team:
<https://go.dev/doc/go1compat>

Kragen

[toc] | [prev] | [next] | [standalone]

#11845

On Fri, 28 Aug 2026 16:43:56 -0300, Kragen Javier Sitaker wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>
>> But J2SE was available in an open-source form, namely OpenJDK. So
>> they adapted that instead.
>
> With respect, I think you may have gotten this wrong. Originally
> they used Apache Harmony (presumably they preferred its non-copyleft
> licensing) but switched to OpenJDK in 02016 in response to the
> Oracle lawsuit
> <https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/>

You are mixing up the language implementation with the library
implementation.

>> On Thu, 27 Aug 2026 21:11:55 -0300, Kragen Javier Sitaker wrote:
>>>
>>> This is a much less compelling choice in the last several years
>>> since the Python maintainers have adopted a policy of deliberately
>>> breaking standard library backward compatibility in every point
>>> release.
>>
>> In what way?
>
> They call it “removing dead batteries from the standard library” ...

So they don’t want to keep accumulating legacy baggage that just adds
to the ongoing support burden. Every open-source project does that.
The key is to support the important stuff that people care about.

Does anybody still want to use the “cgi” module? Sun “au” file format?
A Unix password encryption library that doesn’t keep up with current
password encryption formats?

> This makes it easy to encounter situations like this poster about
> KittenTTS did, who says all of their Python versions on their various
> machines are either too old or too new:
> <https://news.ycombinator.com/item?id=44808718>

I would like to know what code exactly they are referring to.

> Contrast the stance of the Golang development team:
> <https://go.dev/doc/go1compat>

Quote: “it is impossible to guarantee that no future change will break
any program”.

Not really a different stance at all.

[toc] | [prev] | [next] | [standalone]

#11849 — the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?)

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Fri, 28 Aug 2026 16:43:56 -0300, Kragen Javier Sitaker wrote:
>> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>> But J2SE was available in an open-source form, namely OpenJDK. So
>>> they adapted that instead.
>>
>> With respect, I think you may have gotten this wrong. Originally
>> they used Apache Harmony (presumably they preferred its non-copyleft
>> licensing) but switched to OpenJDK in 02016 in response to the
>> Oracle lawsuit
>> <https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/>
>
> You are mixing up the language implementation with the library
> implementation.

Your statement, “So [the Android team] adapted [OpenJDK] instead [when
they could have chosen J2ME],” is not true of *either* the language
implementation (Dalvik) *or* the library implementation (initially they
adapted Harmony, and many years later they adapted OpenJDK).

Kragen

[toc] | [prev] | [next] | [standalone]

#11853 — Re: the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?)

On Fri, 28 Aug 2026 20:27:04 -0300, Kragen Javier Sitaker wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>
>> On Fri, 28 Aug 2026 16:43:56 -0300, Kragen Javier Sitaker wrote:
>>>
>>> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>>>
>>>> But J2SE was available in an open-source form, namely OpenJDK. So
>>>> they adapted that instead.
>>>
>>> With respect, I think you may have gotten this wrong. Originally
>>> they used Apache Harmony (presumably they preferred its non-copyleft
>>> licensing) but switched to OpenJDK in 02016 in response to the
>>> Oracle lawsuit
>>> <https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/>
>>
>> You are mixing up the language implementation with the library
>> implementation.
>
> Your statement, “So [the Android team] adapted [OpenJDK] instead [when
> they could have chosen J2ME],” is not true of *either* the language
> implementation (Dalvik) *or* the library implementation (initially they
> adapted Harmony, and many years later they adapted OpenJDK).

“Dalvik” was the original bytecode interpreter that Google came up
with for Android. That was not a “language implementation” for any
particular “language”.

By “language implementation” I was talking about SunJDK versus
OpenJDK.

[toc] | [prev] | [next] | [standalone]

#11858 — Re: the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?)

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Fri, 28 Aug 2026 20:27:04 -0300, Kragen Javier Sitaker wrote:
>> Your statement, “So [the Android team] adapted [OpenJDK] instead [when
>> they could have chosen J2ME],” is not true of *either* the language
>> implementation (Dalvik) *or* the library implementation (initially they
>> adapted Harmony, and many years later they adapted OpenJDK).
>
> “Dalvik” was the original bytecode interpreter that Google came up
> with for Android. That was not a “language implementation” for any
> particular “language”.
>
> By “language implementation” I was talking about SunJDK versus
> OpenJDK.

We've agreed that they weren’t using the Sun JDK’s class library;
instead they used Apache Harmony.  We've agreed that they weren’t using
the Sun JDK’s bytecode interpreter; instead they used Dalvik.  I'm
pretty sure they weren’t using the Sun JDK’s compiler from Java source
to Java bytecode, because Dalvik couldn’t interpret the standard
stack-oriented JVM bytecode.  Was there some other part of the Sun JDK
that they *were* using?  If so, what part?  What does the JDK contain,
other than the class library, the virtual machine, and the compiler to
that virtual machine?

Kragen

[toc] | [prev] | [next] | [standalone]

#11859 — Re: the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?)

On Sat, 29 Aug 2026 15:24:51 -0300, Kragen Javier Sitaker wrote:

> I'm pretty sure they weren’t using the Sun JDK’s compiler from Java
> source to Java bytecode, because Dalvik couldn’t interpret the
> standard stack-oriented JVM bytecode.

The whole point about using Sun’s JDK was precisely to get its
compiler.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.misc

csiph-web