4 ms·

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 impossibi

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".

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".