3 ms·

I think it's past time that we started working on hardware machines that more closely resemble higher level languages than C/C++. It's sometimes said that C/C+

I think it's past time that we started working on hardware machines that more closely resemble higher level languages than C/C++. It's sometimes said that C/C++ are so performant because they are close to the metal, but I think often at this point we're seeing the reverse causal arrow: C/C++ remain so performant because that's still the "virtual machine" most modern processor/computer architectures are targeting. C/C++ ideas of memory management. C/C++ ideas of process/thread concurrency. No current processor architect would dare to break that model and do something in a new "modern" mold at the risk of sabotaging the performance of C/C++ apps that don't/can't/won't migrate to new paradigms/abstractions. (Arguably that's part of the "betrayal" of the Meltdown and Spectre CPU timing bugs/hacks: the CPU doing too many things to mimic a C/C++ "machine" even though the raw details of the underlying concurrency model at the hardware have needed to vastly change and that abstraction break bleeding into a vulnerability. What if the hardware didn't have to work so hard to pretend to be a very fast C/C++ "strictly in order" machine? Could it be a faster machine if the abstractions it was targeting themselves were more concurrent and more secure?) Lisp machines in the 70s had hardware memory garbage collectors. We've advanced the state of the art of memory garbage collectors quite a bit in the decades after, but few since have thought to again try to express that in hardware. There have been dalliances with chipsets designed to more closely mimic the JVM (Java Virtual Machine) or CLR (Common Language Runtime; .NET's VM) that got some play in embedded design spaces, but the common echo was that they ran C/C++ code too slowly and were themselves labeled as "slow" and "not very useful for general purposes" (because we've tautologically defined C/C++ as "for general purposes"). It's easy to wonder if we could escape this trap of building our hardware machines to resemble our least capable, lowest common denominator "virtual machine" like the C/C++ model and push towards higher level concepts deep in hardware. Lisp machines and JVM/CLR machines all have more interesting reflectivity over live objects than C/C++ machines. There's at the very least component model benefits to being able to get general information about the live object states. There's roads to more "Actor" based types of designs. More "object-oriented" possibility spaces than "files". If you are talking about true, "clean slate", no concerns about backwards compatibility whatsoever, no concerns that interoperating with older software might need to be truly emulated and might possibly be slower in trade-off for better software design of new, non-emulated stuff, I think you might start at basic hardware assumptions and architectures. There's so much more to experiment there that we don't have the budget to explore if we have to continue to keep up the illusion that "C/C++ apps are fast and close to the hardware" for backwards compatibility's sake.

eimrine 4y ago
I think Lisp machines have a serious drawback. It means that OS will be totally open-source with no compilation-as-obfuscation ceremony, that leads to impossibility to show users ads and to lobby non-free software. Our bosses aren't ready for that paradigm shift and most of the people are O.K. to be useds.
- lispm 4y ago
  The actually existing Lisp Machines from the past typically run compiled code. The instructions generated usually were a bit higher level (more dynamic) than that of a typical CPU. The obfuscation is not that strong then. I saw commercial software which came only in a compiled version.
- WorldMaker 4y ago
  There were open source ad networks. Displaying ads doesn't require closed source at all. In some cases it is as simple as a dynamic IMG tag with an API driven SRC. Tracking ads is where most of the grossest proprietary/closed source would be that ad networks wouldn't trust users to see, and arguably its much more user friendly to at least force more tracking to be open source (if not disable it entirely). But as the other comment points out, open source was never a goal nor a requirement of historic Lisp machines. They were big expensive commercial ventures with tons of their own commercial and proprietary code. My understanding was that a lot of their software shipped as "live images" rather than "S-Expressions". Live images are a directly memory mappable binary code and like most binary machine codes still have multiple layers of necessary obfuscation. Even if you are designing a processor to resemble S-expressions, disassembling machine code isn't necessarily going to give you clean source back out. Even building a processor with the goal of being "a Lisp", it's still going to be lower level than the Lisp you'd want to write as a developer. High level functions will still expand into lots of little low level instructions. That expansion process might be "macros" rather than "compilation", but it is still a similarly obfuscating process and shrinking patterns of low level operations back into their original macro definitions still relatively hard. That's where the name "Live images" especially comes into play: they are often captured some time after the program has been running. They are captured after most or all macros have finished expanding. They are captured long after most initialization steps have completed and are no longer needed in memory. That's stronger than the obfuscation afforded by compilation: entire sections of initialization code don't even exist in the final binary. You can't disassemble it at all because it ran on someone else's machine and was shipped pre-baked. Same too that reflectivity does not mean "open source": Lisps still have "API boundaries" and most Lisps have robust object systems with all of the usual benefits of object-oriented programming. That includes encapsulation and private fields. You may have a very easy time inspecting the public API of objects, but the private internals are sometimes just as obfuscated blocks of binary data as any other not publicly documented structures in any other OO languages. In short, building higher level processors does not mean building "highest level" processors where the processors understand 100% of the higher level language and disassembly looks exactly like their assembly language. Open source isn't "required".

eimrine 4y ago

I think Lisp machines have a serious drawback. It means that OS will be totally open-source with no compilation-as-obfuscation ceremony, that leads to impossibility to show users ads and to lobby non-free software. Our bosses aren't ready for that paradigm shift and most of the people are O.K. to be useds.

lispm 4y ago
The actually existing Lisp Machines from the past typically run compiled code. The instructions generated usually were a bit higher level (more dynamic) than that of a typical CPU. The obfuscation is not that strong then. I saw commercial software which came only in a compiled version.
WorldMaker 4y ago
There were open source ad networks. Displaying ads doesn't require closed source at all. In some cases it is as simple as a dynamic IMG tag with an API driven SRC. Tracking ads is where most of the grossest proprietary/closed source would be that ad networks wouldn't trust users to see, and arguably its much more user friendly to at least force more tracking to be open source (if not disable it entirely). But as the other comment points out, open source was never a goal nor a requirement of historic Lisp machines. They were big expensive commercial ventures with tons of their own commercial and proprietary code. My understanding was that a lot of their software shipped as "live images" rather than "S-Expressions". Live images are a directly memory mappable binary code and like most binary machine codes still have multiple layers of necessary obfuscation. Even if you are designing a processor to resemble S-expressions, disassembling machine code isn't necessarily going to give you clean source back out. Even building a processor with the goal of being "a Lisp", it's still going to be lower level than the Lisp you'd want to write as a developer. High level functions will still expand into lots of little low level instructions. That expansion process might be "macros" rather than "compilation", but it is still a similarly obfuscating process and shrinking patterns of low level operations back into their original macro definitions still relatively hard. That's where the name "Live images" especially comes into play: they are often captured some time after the program has been running. They are captured after most or all macros have finished expanding. They are captured long after most initialization steps have completed and are no longer needed in memory. That's stronger than the obfuscation afforded by compilation: entire sections of initialization code don't even exist in the final binary. You can't disassemble it at all because it ran on someone else's machine and was shipped pre-baked. Same too that reflectivity does not mean "open source": Lisps still have "API boundaries" and most Lisps have robust object systems with all of the usual benefits of object-oriented programming. That includes encapsulation and private fields. You may have a very easy time inspecting the public API of objects, but the private internals are sometimes just as obfuscated blocks of binary data as any other not publicly documented structures in any other OO languages. In short, building higher level processors does not mean building "highest level" processors where the processors understand 100% of the higher level language and disassembly looks exactly like their assembly language. Open source isn't "required".