Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Medley Interlisp Project: Reviving a Historical Software System [pdf]

interlisp.org

Post reply on HN
Print view View original

21–30 of 30 posts

Re: The Medley Interlisp Project: Reviving a Historical Software System [pdf]

#21

Post by zelphirkalt »

pjmlp wrote: post #11
zelphirkalt wrote: post #7

Earlier quoted context omitted.

Same thing could probably be some 200k or more LoC in enterprise Java.

Or Objective-C, https://github.com/Quotation/LongestCocoa Or Smalltalk or C++, https://en.wikipedia.org/wiki/Design_Patterns Or even C, https://www.amazon.com/Modern-Structured-Analysis-Edward-You... Point being, people like to blame Java, while forgetting history of enterprise architecture.

Smalltalk though is famous for having blocks (closures!), a very minimal syntax, and late binding. It has had those for decades before Java got something like it.

But I think it is also at least partially a culture thing. Wanting to make every noun into a class and then going for 3 levels of design patterns, when actually a single function with appropriate types of input arguments and output would be sufficient, if it can be decided on at runtime. Then we run into issues of Java the language, which doesn't let you use the most elementary building block, a function. No, it forces you to put things into classes and that makes people think, that now they want to make objects, instead of merely have a static method. Then they complicate design more and more building on that. A culture of not being familiar with other languages, which emphasize more basic building blocks than classes. A culture of "I can do everything with Java, why learn something else?". A similar culture exists in the C++ world or among C aficionados.

Re: The Medley Interlisp Project: Reviving a Historical Software System [pdf]

#22

Post by chillpenguin »

jshaqaw wrote: post #5

Retro lisp machines are cool. Kudos to the team. Love it. That said… we need the “lisp machine” of the future more than we need a recreation.

Smalltalk was the lisp machine of the future. Of course, now even Smalltalk is a thing of the past.

Re: The Medley Interlisp Project: Reviving a Historical Software System [pdf]

#23

Post by kps »

rjsw wrote: post #20
kps wrote: post #17

~wavy lines~~ I've never used this in anger, but I owned a second-hand Xerox Daybreak for a while to play around with. Later, there was a some freely available project (I've now forgotten) that used Interlisp running on an emulator running on a DEC Alpha, and so I added some minor bits to NetBSD's Ultrix compatibility.

The Lisp Machine emulator that was tied to DEC Alpha was Symbolics OpenGenera.

Made me look: Xerox LFG Grammar Writer's Workbench: https://web.archive.org/web/20170907021542/https://www2.parc...

Interlisp screenshot: https://web.archive.org/web/20160616231118/http://www2.parc....

Evidently the emulator was later ported to Linux as well.

Re: The Medley Interlisp Project: Reviving a Historical Software System [pdf]

#24

Post by pamoroso »

kps wrote: post #23
rjsw wrote: post #20

Earlier quoted context omitted.

The Lisp Machine emulator that was tied to DEC Alpha was Symbolics OpenGenera.

Made me look: Xerox LFG Grammar Writer's Workbench: https://web.archive.org/web/20170907021542/https://www2.parc... Interlisp screenshot: https://web.archive.org/web/20160616231118/http://www2.parc.... Evidently the emulator was later ported to Linux as well.

Did you use LFG Grammar Writer's Workbench for linguistics work or research back then? Ron Kaplan is looking to revive the system and make it run on Medley Interlisp again.

Re: The Medley Interlisp Project: Reviving a Historical Software System [pdf]

#25

Post by kps »

pamoroso wrote: post #24
kps wrote: post #23

Earlier quoted context omitted.

Made me look: Xerox LFG Grammar Writer's Workbench: https://web.archive.org/web/20170907021542/https://www2.parc... Interlisp screenshot: https://web.archive.org/web/20160616231118/http://www2.parc.... Evidently the emulator was later ported to Linux as well.

Did you use LFG Grammar Writer's Workbench for linguistics work or research back then? Ron Kaplan is looking to revive the system and make it run on Medley Interlisp again.

Personally, neither — I just used it as a way to get a copy of Interlisp to play with.

Re: The Medley Interlisp Project: Reviving a Historical Software System [pdf]

#26

Post by rjsw »

amszmidt wrote: post #18
rjsw wrote: post #16

Earlier quoted context omitted.

Maybe try replacing the ALU with one written directly in Verilog, I suspect this will run a lot faster than building it up from 74181+74182 components.

From what I see -- that is not the case. The current state is _very_ fast in simulation to the point where it is uninteresting (there are other things to figure out) to write something as a behavioral model of the '181/'182. ~100 microcode instructions takes about 0.1 seconds to run.

I was thinking more of a behavioral model of the whole ALU, just so that the FPGA tools can map it onto a collection of the smaller ALUs built into each slice.

What clock speed does your latest design synthesize at?

Re: The Medley Interlisp Project: Reviving a Historical Software System [pdf]

#27

Post by therealcamino »

rjsw wrote: post #26
amszmidt wrote: post #18

Earlier quoted context omitted.

From what I see -- that is not the case. The current state is _very_ fast in simulation to the point where it is uninteresting (there are other things to figure out) to write something as a behavioral model of the '181/'182. ~100 microcode instructions takes about 0.1 seconds to run.

I was thinking more of a behavioral model of the whole ALU, just so that the FPGA tools can map it onto a collection of the smaller ALUs built into each slice. What clock speed does your latest design synthesize at?

At the top of the readme it says "There will be no attempt at making this synthesizable (at this time)!".

Re: The Medley Interlisp Project: Reviving a Historical Software System [pdf]

#28

Post by pjmlp »

zelphirkalt wrote: post #21
pjmlp wrote: post #11

Earlier quoted context omitted.

Or Objective-C, https://github.com/Quotation/LongestCocoa Or Smalltalk or C++, https://en.wikipedia.org/wiki/Design_Patterns Or even C, https://www.amazon.com/Modern-Structured-Analysis-Edward-You... Point being, people like to blame Java, while forgetting history of enterprise architecture.

Smalltalk though is famous for having blocks (closures!), a very minimal syntax, and late binding. It has had those for decades before Java got something like it. But I think it is also at least partially a culture thing. Wanting to make every noun into a class and then going for 3 levels of design patterns, when actually a single function with appropriate types of input arguments and output would be sufficient, if i…

Smalltalk is a pure OOP language, even the blocks you praise are objects.

Java isn't the only language missing closures, plenty of them took their nice time getting them into the language.

Everything else about Java on your comment, applies equally well to Smalltalk, that is why famous books like Design Patters exist, were written about 5 years predating the idea of a programming language like Java, and mostly uses Smalltalk examples, with some C++ as well.

In Smalltalk image world, everything is Smalltalk, the IDE, the platform, the OS, there isn't something else.

Many Java frameworks like JUnit, or industry trends like XP and Agile, have their roots in Smalltalk consulting projects, using IDEs like Visual Age for Smalltalk.

J2EE started its life as an Objective-C framework at Sun, during their collaboration with NeXT, called Distributed Objects Everywhere.

In similar vein, NeXT ported their Web Objects framework in Objective-C to Java, even before Apple's acquisition, with pretty much the same kind of abstraction ideas.

Re: The Medley Interlisp Project: Reviving a Historical Software System [pdf]

#29

Post by lproven »

jshaqaw wrote: post #5

Retro lisp machines are cool. Kudos to the team. Love it. That said… we need the “lisp machine” of the future more than we need a recreation.

> we need the “lisp machine” of the future

Totally agree.

Here's my idea: stick a bunch of NVRAM DIMMs into a big server box, along with some ordinary SDRAM. So, say, you get a machine with the first, say, 16GB of RAM is ordinary RAM, and then the 512GB or 1TB of RAM above that in the memory map is persistent RAM. It keeps its contents when the machine is shut off.

That is it. No drives at all. No SSD. All its storage is directly in the CPU memory map.

Modify Interim or Mezzano to boot off a USB key into RAM and store a resume image in the PMEM part of the memory map, so you can suspend, turn off the power, and resume where you were when the power comes back.

https://github.com/froggey/Mezzano

https://github.com/mntmn/interim

Now try to crowbar SBCL into this, and as many libraries and frameworks as can be sucked in. All of Medley/Interlisp, and some kind of convertor so SBCL can run Interlisp.

You now have an x86-64 LispM, with a whole new architectural model: no files, no disks, no filesystem. It's all just RAM. Workspace at the bottom, disposable. OS and apps higher up where it's nonvolatile.

I fleshed this out a bit here:

https://archive.fosdem.org/2021/schedule/event/new_type_of_c...

And here...

https://www.theregister.com/2024/02/26/starting_over_rebooti...

Re: The Medley Interlisp Project: Reviving a Historical Software System [pdf]

#30

Post by rjsw »

therealcamino wrote: post #27
rjsw wrote: post #26

Earlier quoted context omitted.

I was thinking more of a behavioral model of the whole ALU, just so that the FPGA tools can map it onto a collection of the smaller ALUs built into each slice. What clock speed does your latest design synthesize at?

At the top of the readme it says "There will be no attempt at making this synthesizable (at this time)!".

There was already a design of CADR for FPGAs [1] that does synthesize (and boot), I don't know why amszmidt needed to start again from scratch or if his design is a modification of the earlier one.

A similar comment applies to lm-3. Maybe it is built on a fork of the previous repo, it is hard to tell.

[1] https://github.com/lisper/cpus-caddr

Post reply on HN