After getting my Masters degree in the early 80s, I went to NYU for my Ph.D. with the intent purpose of working on SETL with Jack Schwartz. Unfortunately, by that time, Jack had moved on from SETL and onto the world of Robotics. Robert Dewar was too busy building Realia COBOL and was not taking on any additional Ph.D. students. So I floundered around NYU for a year before deciding to do my own commercial software, which was probably the best decision I ever made. Especially after seeing a lot of Ph.D. students at NYU who had been there for 10 years.
I wrote one of the first word processors for Unix, and showed it at the first UnixExpo in the Javits Center in 1984. When the company that was marketing it went out of business, I ported the word processor to the IBM PC, and it became a very popular shareware word processor (New York Word). The income from New York Word was sufficient enough that I quit my day job and formed a software company devoted to making various productivity tools.
SETL has an interesting lineage and part to play in the history of computing:
The original SETL was implemented in a language known as LITTLE, Dave Shields noted in an email: "SETL was implemented in LITTLE, a language based on FORTRAN that had fixed=length bitfields as a fundamental data type."
Early SETL was used by Robert Dewar's team to implement the first validated Ada implementation, known as NYU Ada/Ed. This implementation worked as an interpreter.
We have a printed copy of the original SETL based NYU Ada/Ed but we are still to find the original SETL implementation. Maybe somewhere in the Courant Institute or their alumni there is someone with an original magnetic tape from the DEC VAX machine that ran these implementations.
In my other reply in this thread I highlighted the lineage of SETL, I neglected to also mention that SETL was an influence on ABC that influenced Python.
I parallelized the SetL runtime for shared memory multiprocessors, with dynamic load balancing, parallel GC, and added explicit parallel constructs, at Urbana-Champaign, from fall 1988 over the next couple years. It's weird, to me, that the global interpreter lock persists in Python, 3 decades later.
> I parallelized the SetL runtime for shared memory multiprocessors, with dynamic load balancing, parallel GC, and added explicit parallel constructs, at Urbana-Champaign, from fall 1988 over the next couple years. It's weird, to me, that the global interpreter lock persists in Python, 3 decades later.
I don't think anyone thinks GvR is incapable of removing the GIL. Given the comparatively tiny base of installed SETL software, surely it's a lot easier to check that any backwards-incompatible changes to SETL won't break any important installed software based on it than it is to do the same for Python?
(And, as a follow-up, I think it's fair to say that there is no such thing as a fully backwards compatible change. My background is with Perl more than Python, where the problem is especially acute; but I imagine with Python too, it is very hard to make a change where one can be totally sure that the behaviour being 'fixed' isn't behaviour that some piece of software somewhere out there relies on being broken in exactly the historically right way.)
'As rms has kindly pointed out, the designation "GNU SETL" is incorrect until the sources have been released. I hope to correct this by making that release soon'
After getting my Masters degree in the early 80s, I went to NYU for my Ph.D. with the intent purpose of working on SETL with Jack Schwartz. Unfortunately, by that time, Jack had moved on from SETL and onto the world of Robotics. Robert Dewar was too busy building Realia COBOL and was not taking on any additional Ph.D. students. So I floundered around NYU for a year before deciding to do my own commercial software, which was probably the best decision I ever made. Especially after seeing a lot of Ph.D. students at NYU who had been there for 10 years.