[hnlmorg]

Indeed however to be analogous with the submission those consoles would still need to be running on a time sharing system like I described.

Time sharing systems also pre-date UNIX and Multics, which is why I exampled them as being operating systems that use the time sharing metaphor.

[lispm]

Right, Time sharing wasn't implemented yet at that time, when Lisp was having its first interactive console in 1960. It was then also implemented on the first time sharing operating systems.

[hnlmorg]

ok, let's put it another way, a LISP console is all well and good but systems in 1960 weren't yet multi-tasking (or at least multi-tasking systems in 1960 were still rare) so you couldn't have a LISP process running as one thread and query it's running state from another.

The reason I keep hammering on about time sharing is because they largely came hand in hand, time sharing systems needed to support multi-tasking whereas single user systems didn't (you still see echoes of this in the 80s with CP/M, DOS and 8-bit micros running BASIC). In fact if you look at the history of multi-tasking it roughly follows the same time line and lineage as the uptake of time sharing systems (around mid '60s IIRC). Before then you'd have to stop the execution of one program before you could start execution on another.

I know some "LISPians" like to think everything in computing eventually leads back to LISP but that's not always the case (and I say that as a big fan of the language myself).

[lispm]

One might just write a main loop, which takes Lisp expressions (or other input) from two or more different terminals and executes each expression interleaved. Those were not 'concurrent programs' which shared some state, but function calls within the same Lisp system, using an interactive execution loop serving several I/O devices. An early (mid 60s) application domain would be multi-player games over terminals controlled from a single process.

Lisp also has the idea of break loops, which halt the current execution (for example triggered by some kind of interrupt), allow interaction with the program state and then let one continue the program in some way. Thus one would not need to attach a debugger I/O loop from another process, but the debugger repl would be a part of the running program and could be called on demand.

That you 'know some "LISPians" like to think everything in computing eventually leads back to LISP but that's not always the case' doesn't invalidate the fact that Lisp systems were running on many of the early computers & operating systems from 1960 onwards and followed their evolution. Thus at least some interesting stuff has been done very early in Lisp, too.

[hnlmorg]

> One might just write a main loop, which takes Lisp expressions (or other input) from two or more different terminals and executes each expression interleaved.

Pre-time sharing systems weren't multi-terminal. Hence why I keep coming back to time sharing.

Also your main loop example could be done in assembly, FORTRAN, BASIC, Pascal and C, two of which also pre-date LISP. There's nothing uniquely LISP about writing a polling loop.

Job control et al and multi-terminal mainframes are something very much born out of time sharing. You could use LISP to write your application that would run atop of that time sharing system if you wanted but you could also write that same application in a bunch of other languages too (assuming you had a compiler for that machine). And bare in mind around this time you could still physically inspect the state of paused program on a fair amount of single process systems (and those you couldn't would often punch out verbose log of its running state to tape).

> An early (mid 60s) application domain

By the mid 60s you had time sharing systems. Your argument was that LISP was doing this before then.

> That you 'know some "LISPians" like to think everything in computing eventually leads back to LISP but that's not always the case' doesn't invalidate the fact that Lisp systems were running on many of the early computers & operating systems from 1960 onwards and followed their evolution. Thus at least some interesting stuff has been done very early in Lisp, too.

I completely agree but you're attributing credit to LISP for something that isn't a language-specific feature. At least the OP was referencing a computing platform.

Anyway, this whole conversation was ridiculous from the outset and a massive distraction to the submission that sparked it. It doesn't really matter what came first; the only reason I even commented was to illustrate that we're all standing on the shoulders of giants so it's pointless mocking a submission for being similar in design to tech that pre-dates it. It's ironic that post lead to an argument about what came first.

[lispm]

> main loop example could be done in assembly

'Could' is the word. My example was that it was actually done to have built-in command loops and the building blocks for those (so that they could be used in programs), which could be invoked on demand while a program was running.

> it's pointless mocking a submission for being similar in design

I'm not mocking the submission. The feature is quite valuable and interacting with running software via command loops is great.

[hnlmorg]

> 'Could' is the word.

Ok, "was" then. Operating systems were originally written in assembly and you can't write an operating system without some kind of hardware polling and command loops (even in the days before multi-tasking systems).

Even earlier computers in the days before operating systems would have command loops written in giant rings of punched sheets that would slowly spin round on reels like a cambelt. So this isn't even an innovation that was born from assembly, let alone any high level language.

I honestly do get what you're saying and I'm not trying to dismiss your point that people did this kind of stuff in LISP but what you need to understand is that people did this in a great number of different ways, in different languages and even mechanically too.