lispm

LOOPS (Lisp object-oriented programming systems) is written in Interlisp for the Interlisp-D environment, was a Xerox product and is from around 1981.

CLOS (Common Lisp Object System) is a general OOP standard extension for Common Lisp. A specification was proposed in 1987/88. CLOS was included in the Common Lisp standard and widely implemented by various implementations.

Both were a "system" -> meaning that it is available and programmable also at runtime.

LOOPS is an actual piece of software with a GUI, which integrates into the Interlisp-D development environment.

LOOPS was based on message sending, classes, methods, interactive changes to the object system.

CLOS does not use message sending, but calling generic functions with multi-methods and multiple dispatch.

LOOPS supports Access-oriented Programming with Active Values. Demons can act based on access to objects. CLOS has no direct support for that. Maybe partial (-> :before & :around &:after methods in CLOS).

LOOPS includes a rule-system. CLOS systems have that as extensions. It's not a part of CLOS itself.

LOOPS includes graphical & menu tools to browse and edit objects. CLOS systems have some of that as extensions, depending on the implementation.

LOOPS was a programming system for knowledge-based systems, like Expert Systems. CLOS was not designed for that, but such programming systems were also developed for Common Lisp, some using CLOS. Example: KnowledgeWorks from LispWorks.

LOOPS was later rewritten as CommonLOOPS for Common Lisp. The software "Portable Common LOOPS" (PCL) then was further developed into a portable (and widely ported) and complete prototype implementation of CLOS + MOP.

Some more background https://larrymasinter.net/stefik-loops.pdf and https://www.markstefik.com/?page_id=334

I think LOOPS was limited by only being available on Interlisp-D related systems. Common LOOPS was supposed to be portable, but I remember it only in the context of the CLOS development as a stepping stone, but not as a product or environment like LOOPS.

The answer is mostly about CLOS and not about LOOPS.

Update: my remark was about an earlier posted content, which had an "AI" generated answer. That text has been removed.

LOOPS was one of the early frameworks for AI programming (-> for Knowledge-based Systems -> especially Expert Systems) in Lisp, which also made use of the new graphical user interface of the Interlisp-D Lisp Machine from Xerox. Interlisp-D was a combination of operating system and development environment, and was developed for the same computers, which also ran Smalltalk. Both were image-based and managed the source code in the development environment.

Remarkable is the fully interactive way of working in the REPL (Lisp's Read Eval Print Loop) and through the GUI, including live editing all classes/etc. via menus. LOOPS extended Interlisp with various ways to do object-oriented programming and a rule-system.

There is also a "friendly primer" for Xerox LOOPS, from mid 1980s. https://bitsavers.org/pdf/xerox/interlisp-d/198510_Koto/3102...

Note that LOOPS is an early OOP System, it's not a about iteration in a loop.

I would miss the in-order collects, actually collect/maximize/... features, destructuring of lists, direct type declarations, ...

I also find DO not easy to read and understand.

The code from above I would actually write in LOOP as

    (loop for a from 1 upto 5
          and b = 10 then (* b 1.5)
          collect (* a b) into c
          finally (return (list a b c)))

I find that to be readable.

LOOP has the DO functionality included.

Example:

    CL-USER 18 > (do ((a 1 (+ a 1))
                      (b 10 (* b 1.5))
                      (c nil))

                     ((> a 5) (list a b (reverse c)))

                   (push (* a b) c))

    (6 75.9375 (10 30.0 67.5 135.0 253.125))

    CL-USER 19 > (loop for a = 1 then (+ a 1)
                       and b = 10 then (* b 1.5)
                       and c = NIL then c

                       when (> a 5) do (return (list a b (reverse c)))

                       do (push (* a b) c))

    (6 75.9375 (10 30.0 67.5 135.0 253.125))

> Most people can't program. Most people can't do mathematics. Most people are not good at this stuff.

No doubt about that.

SICP is the wrong book.

SICP is for people who are good at maths. Most of the examples are maths related. That's a well known complaint about the book. Often such maths-heavy introductory courses filter out the students who are not good at maths. On purpose.

SICP is not for beginners learning Lisp programming. SICP was an university introductory course book for computer science. It was developed out of maths-heavy CS lectures. Various other books tried to improve it both to make some of the topics easier to learn or to make it more advanced in programming language technology.

Easier SICP from Brian Harvey

https://www.youtube.com/watch?v=cuTOo_Kj4U0&list=PL91cR71aKp...

or him adopting this stuff to Logo: Computer Science Logo Style. https://people.eecs.berkeley.edu/~bh/

Or his book "Simply Scheme": https://people.eecs.berkeley.edu/~bh/ss-toc2.html

But what you are looking for is a book for a software developer wanting to learn practical Lisp programming with different examples.

> I mean that using software outside from its own boundaries was the original hacker spirit

then Excel is the ultimate hacker software... ;-)

> Excel with VBA isn't a proper environment for scientific computing

But Excel has a user interface, documentation and help, how to solve various problems. Thus the end result is that lots of people were able to solve their practical problems.

"Common Lisp", in its current popular form, lacks an accessible user interface and more recipes how to solve problems. It's an advanced experts tool. A better tool without a handle.

> If you can't start riding a bike without stabilisers or someone holding it, then you're never going to learn to ride well.

In German: "es ist noch nie ein Meister vom Himmel gefallen". We all start somewhere, we go to school, we have teachers, we have trainers/coaches, we have mentors, ...

I don't think studying it alone will help, best is with people around. Parents and friends will help us to learn how to ride a bike. They will give an example, they will give feedback on our attempts, they will propose what and how to try to master it. After the initial basic hurdle is done, then comes a lot of practice. But again, best by being embedded in a community. Learning such skills is a social activity.

There is a lot of pedagogical material to learn programming with Lisp, Logo, Scheme. I had courses about software development, using languages like PASCAL, LISP, Scheme and others. We got exercises and feedback. We got access to computers, cpu time and an environment for coding. I looked around and setup my own tools and wrote stuff with it. I discussed this stuff (code, environment, architecture, styles, ...) with a friend.

> perhaps this stuff that's easy for me is hard for others, and I should not blame them for them finding it hard?

Lot's of people are frightened by thinking/hearing that it is hard, while in fact it actually isn't.

For example one of reads that German is very difficult for native English speakers. There are a lot of justifications given for that. The actual data says something different. German is very near to English, English even is a Germanic language: https://en.wikipedia.org/wiki/Germanic_languages

The actual ranking: https://effectivelanguagelearning.com/language-guide/languag...

Trying to learn Lisp without actually trying to write code, sounds like trying to learn a language without actually trying to speak with people. Possible, but unnecessary hard.

We need to make our brain adapt to the new language by moving into an environment, where the words connect to the real world and thus to meaning.

Maybe just allow yourself to think: Giving feedback is not "blaming". That's an early concept needed for moving forward.

> I have spent years writing about and studying Lisp, including buying several books.

The key is "writing and maintaining" Lisp software.

Lisp often won't get learned by reading or writing ABOUT it, but by reading AND writing actual Lisp code.

It's a bit like riding a bike. You can study bikes for a long time, but you will typically not be able to ride a bike. That's something which can be learned when actually practicing to ride the bike. This means also not needing to consciously think about it, but by moving tasks to internal automatisms. Lisp code is data and this wants to be "manipulated". This manipulation is a key to learn Lisp. The other key element is to work with a system which gives live feedback -> interactive programming. "Interactive" means to do things, to fail, to improve, to do it again.

It's in part the experience of actually using an interactive programming system.

> original hackers did actually that on some software like Maxima on top of MacLisp

The original hackers developed Macsyma on Maclisp.

Project MAC's SYmbolic MAnipulator and Project MAC's lisp.

Maxima is a fork, which was renamed from DOE Macsyma to Maxima in the end 1990s, converted to Common Lisp and published under a GPL license.

Macsyma (-> Computer Algebra) and Excel (Spreadsheet) are two very different applications.

yes, the early SPIKE software for Hubble was on TI Explorers.

Besides all the animation stuff, a prominent application was for the Space Shuttle. NASA bought a bunch of Symbolics XL Lisp machines, to process HDTV video feeds to monitor the Space Shuttle launches. From 1990:

"Recently the National Aeronautical and Space Administration (NASA) used Symbolics' high-definition technology to analyze HDTV video images of the Discovery launch in real-time. This high-definition system enabled NASA engineers to get an instant replay of critical launch systems. The engineers were able to enhance and enlarge high-resolution images of the lift-off in order to analyze the condition of and spot potential problems with space shuttle tiles."

> That said, it seemed to me that longer cabling was less in use with G- and I-machines, but that's just me looking over scraps that went onto internet.

The XL400 and XL1200 were large & loud beasts. You would not want to have them near you.

> Symbolics also definitely had an edge in graphical processing, though I've seen mentions suggesting that for pure CAD works that didn't require high-definition video output Explorers sold quite well?

Symbolics was also widely used in HDTV quality productions.

For CAD work I have no idea how big the market was. But for example iCAD was probably one of the applications that were making new stuff possible via parametric CAD. Then there was CAD in electronics and chip design...

It's to keep the dream alive.

Why wouldn't one be able to implement this in JavaScript, Python, Smalltalk or even BASIC ?

Look at the list of Emacs-type editors. Plenty of them were not written in Lisp.

> Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command with the same level of granularity as the advising mechanism of GNU Emacs, I would love to know about it.

Zmacs did that before GNU Emacs existed. It also allowed ALL parts of the editor to be changed, not just the ones written in Emacs Lisp for GNU Emacs. Remember, the core of GNU Emacs - both the core Lisp implementation and some core editor and UI functionality - is written in C.

Btw., on a real Lisp Machine the editor (Zmacs) was not the main user interface. For example on a Symbolics (but also in Interlisp-D), the listener and a file browsers were their own applications. Zmacs in Genera has a Dired mode, but no listener. Also Genera can run multiple Zmacs windows in the same Lisp, running concurrently -> the Lisp supports multiple threads and the applications use that feature.. Something which GNU Emacs can't easily do. It's mostly blocking and single threaded. Something which can't be easily fixed in Emacs Lisp.

Run Lisp code in GNU Emacs in the REPL (m-x ielm) and it blocks the UI. That can't trivially fixed and is a major implementation fail of GNU Emacs.

Other Emacs-like editors can run multiple things, without blocking the user interface.

Especially since many compiler-only implementations can evaluate Lisp code at runtime, just fine, even though they don't execute s-expressions in an Interpreter. Thus an compiler-only Lisp can be used to implement Emacs just fine. I used for many years an Emacs on top of a compiler-only Common Lisp.

There are two open source emulators of actual Lisp Machines I would recommend:

Interlisp-D/Medley: https://interlisp.org

MIT CADR: https://tumbleweed.nu/lm-3/

These run an actual Lisp operating system.

A Lisp REPL is a user interface, not an implementation.

The first Emacs wasn't using Lisp at all. Wasn't it literally the Emacs?

> It's rather a Lisp REPL that has a text-editor built on top of it.

Just write an Emacs without a Lisp REPL. It can have the same Dired, just written in Python. There is nothing in Dired, which requires Lisp.

Right, Open Genera uses ONLY an X11 console, and thus requires TCP/IP.

But that was the case on other machines, too. The embedded UX400/1200 machines and the headless NXP1000 use an X11 console, too.

Lots of TV software does not run on these machines, because they don't have a framebuffer.

If you say only Lisp can be used to implement Emacs, would you mean a specific Emacs or an editor belonging to the larger family of Emacs-like editors? When I would speak about how to implement "an Emacs", I would include the option to use different programming languages. For example I could imagine that C and Python is a valid combination, even Python alone would be an option. Python can be used interactively, which would be sufficient for an interactive extension language.

Here is an old Emacs timeline:

https://www.jwz.org/doc/emacs-timeline.html

The actual historic Emacs wasn't written in Lisp and was not extensible in Lisp. It was written on top of TECO and assembly. It was extensible.

The second and third Emacs were both written in Lisp (Zetalisp and Maclisp) and they were completely written in Lisp.

At some point Gosling wrote an Emacs in C and Mocklisp. Stallman took that one and rewrote it into GNU Emacs.

We have lots of Emacs variants written in languages like TECO, C, Fortran, ...

Craig A. Finseth wrote "The Craft of Text Editing: Emacs For The Modern World"

http://www.finseth.com/craft/

Chapter Ten of above book describes what Emacs-type means: http://www.finseth.com/craft/#c10

Extensibility is a general feature and not tied to Lisp or GNU Emacs.

The book contained a list of Emacs implementations. An newer list is here: http://www.finseth.com/emacs.html

You can see that there is a multitude of editors in the Emacs category. The list also mentions the implementation and the extension language.

> GNU Emacs is what people usually mean when they speak about Emacs

That's a bit sad. It's like saying "Linux" and think that its the same as "Debian Linux". Similar there are a lot of different Emacs-like editors. Claiming that there is only a single way to implement Emacs goes against the evidence that there are a lot of Emacs-like editors, which are not implemented in C + Emacs Lisp, including the original first Emacs.

I would think that by far the most important Emacs is GNU Emacs, but I don't think its implementation language choice (C + Lisp) is necessary to implement an extensible Emacs-like editor. Also be aware even though GNU Emacs is a popular Emacs editor, there are some people who are using different Emacs-like editors instead. I typically use a Hemlock variant written in Common Lisp and Zmacs, written in ZetaLisp. Both core designs date back many decades, actually even before GNU Emacs existed.

> Emacs is specifically tied to Lisp

GNU Emacs is tied to Elisp. But Emacs is a much wider family of editors written in a multitude of languages.

> Yet somehow, in over forty years nobody has succeeded in dethroning Elisp from ruling Emacs

That might have several reason. Maybe few people are interested to reimplement GNU Emacs in a different language. Like nobody has succeeded in dethroning C from the Linux kernel, using Lisp.

> if you want to build something like Emacs - a REPL that has a built-in text editor, you need a Lisp, because non-homoiconic languages DO NOT HAVE exactly same REPLs.

I don't think it makes sense. One can build programmable editors in many interactive languages. The language for an editor doesn't need to be Lisp. It could be Python, JavaScript, Ruby, PERL, Forth, ... Typically a form of EVAL or compile/load is enough to do so.

GNU Emacs is a Lisp implementation with an abstraction layer over the hardware and OS. I would like to reserve "Lisp Machine" to computers with an actual Lisp operating system or emulations of those.

> Lisp can evaluate the s-expressions directly.

Not generally: in compiler-only implementations this is not provided.

Good luck with that. I don't think that's possible.

> Nobody will use Genera without Zmacs or the error handler (aka Debugger)…

Nobody will run Genera without TCP/IP and a lot of other stuff.

The error handler is not the same anymore.

> you can take the Dynamic listener or even DW and have it running on a MIT system without much work

I think that's pure fantasy.

> Genera was carefully designed to keep compatibility with the MIT system.

I don't think that was a goal, given that the MIT system was not relevant anymore and the vendors all had their own forks. TI converted much of the old code to Common Lisp with a translator. Symbolics wrote most new code in Common Lisp.

Without an extensive implementation of Common Lisp incl. CLOS, basically nothing runs on the old system.

The times of a few conditional reader macros was soon over.

Does Portable Common LOOPS (PCL) run on the MIT Lisp Machine?

https://github.com/binghe/PCL/tree/master/impl

It lacks a port, but there are ports to TI and Symbolics. That should be simple.

Racket now gets a new, non-s-expression, syntax. The Lisp syntax is said to be a problem hindering wider adoption.

A Symbolics MacIvory or a TI MicroExplorer would typically sit at/under/on the desk.