40 ms·

> Unikernels are entirely undebuggable Funky, the Lisp Machine uni-kernel OS was probably one of the most debuggable OS ever... with the most sophisticated err

by lispm 11y ago

> Unikernels are entirely undebuggable Funky, the Lisp Machine uni-kernel OS was probably one of the most debuggable OS ever... with the most sophisticated error handling system, processes, backtraces, self-descriptive descriptive data-structures, full source code integration, seamless switching between compiled and interpreted code, run-time type checking, runtime bounds checking, inspectors, integrated IDE, ...

pjmlp 11y ago
I would add Mesa/Cedar and Smalltalk to the list, but I only seen the original ones from Xerox documents. Oberon was also quite good, but I guess less than Lisp Machines.
- nickpsecurity 11y ago
  Did you see my list in reply to that comment? Genera and Oberon are on it. I'll consider Mesa/Ceder and Smalltalk. The former was in the Hansen overview I started with. Might deserve individual mention, might not. Throw in your opinion on why if so as I just can't recall its traits. Smalltalk, too. Especially as the topic is stuff that's still better than UNIX in some attribute. I haven't studied it enough to know what you like about it past probably safety and great component, architecture.
  - pjmlp 11y ago
    Yeah I read it. It is a very nice overview. I just didn't knew what comment was better to reply to. As for Smalltalk, I loved its expressioness, specially since my experience with it was in the mid-90's with VisualWorks at the university, before Java was introduced to the world. But back then one still needed to code the VM primitives in Assembly. Meanwhile with Pharo and Squeak it is turtles all the way down. Still waiting for a Dynabook though.
    - nickpsecurity 11y ago
      re language Ahh. I believe it was VisualWorks mentioned when I last looked at it. The impression I had from that description was that it was the ultimate, component language. They said you don't have a main function and directives like most languages. You really just have a pile of objects that you glue together with the glue being the main application. And that this was highly integrated into the IDE's to make that easy to manage. Was that the experience you had? re VM primitives in assembly I'm actually fine with that. I'm not like other people that think language X's runtime must always be written in X. Maybe a version of that for testing and reference implementation. People can understand it. Yet, I'll throw the best ASM coder I can at a VM or even its critical paths if I have to get highest performance that way. Can't let C++ win so easily over the dynamic languages. ;)
      - pjmlp 11y ago
        I learned OOP with Turbo Pascal 5.5, and already used a few other versions up to Delphi 1.0, C++ and VB, before I got to use Smalltalk. So I was already comfortable with the concepts as such. But playing with one of the foundations of OOP concepts had some fun to it, the environment fully dynamic that you could explorer and change anything (better save the image before). Also it was my first contact with FP, given the Lisp influence on Smalltalk blocks and collection methods. The original LINQ if you wish. Then the mind blogging idea of meta-classes and the interesting things one could do with them. Smalltalk given its Language OS didn't had any main as such, you were supposed to use the Transcript (REPL) or the class browser to launch applications. As an IDE, you could prune the image and select a specific class as entry point to create a production executable. But after that semester, I lost access to it, so eventually I spent more time reading those wonderful Xerox PARC books about Smalltalk-80 than using Visual Works. As for the VM primitives in Assembly, I also liked it, but many people see that as a disadvantage, like you mention.
        nickpsecurity 11y ago
        Thanks for the detailed reply. Yeah, that is interesting. Closer to the LISP machines than most development environments. Might make me revisit Smalltalk just because it's so hard to get people to try LISP.

by lispm 11y ago

pjmlp 11y ago

I would add Mesa/Cedar and Smalltalk to the list, but I only seen the original ones from Xerox documents. Oberon was also quite good, but I guess less than Lisp Machines.

nickpsecurity 11y ago
Did you see my list in reply to that comment? Genera and Oberon are on it. I'll consider Mesa/Ceder and Smalltalk. The former was in the Hansen overview I started with. Might deserve individual mention, might not. Throw in your opinion on why if so as I just can't recall its traits. Smalltalk, too. Especially as the topic is stuff that's still better than UNIX in some attribute. I haven't studied it enough to know what you like about it past probably safety and great component, architecture.
- pjmlp 11y ago
  Yeah I read it. It is a very nice overview. I just didn't knew what comment was better to reply to. As for Smalltalk, I loved its expressioness, specially since my experience with it was in the mid-90's with VisualWorks at the university, before Java was introduced to the world. But back then one still needed to code the VM primitives in Assembly. Meanwhile with Pharo and Squeak it is turtles all the way down. Still waiting for a Dynabook though.
  - nickpsecurity 11y ago
    re language Ahh. I believe it was VisualWorks mentioned when I last looked at it. The impression I had from that description was that it was the ultimate, component language. They said you don't have a main function and directives like most languages. You really just have a pile of objects that you glue together with the glue being the main application. And that this was highly integrated into the IDE's to make that easy to manage. Was that the experience you had? re VM primitives in assembly I'm actually fine with that. I'm not like other people that think language X's runtime must always be written in X. Maybe a version of that for testing and reference implementation. People can understand it. Yet, I'll throw the best ASM coder I can at a VM or even its critical paths if I have to get highest performance that way. Can't let C++ win so easily over the dynamic languages. ;)
    - pjmlp 11y ago
      I learned OOP with Turbo Pascal 5.5, and already used a few other versions up to Delphi 1.0, C++ and VB, before I got to use Smalltalk. So I was already comfortable with the concepts as such. But playing with one of the foundations of OOP concepts had some fun to it, the environment fully dynamic that you could explorer and change anything (better save the image before). Also it was my first contact with FP, given the Lisp influence on Smalltalk blocks and collection methods. The original LINQ if you wish. Then the mind blogging idea of meta-classes and the interesting things one could do with them. Smalltalk given its Language OS didn't had any main as such, you were supposed to use the Transcript (REPL) or the class browser to launch applications. As an IDE, you could prune the image and select a specific class as entry point to create a production executable. But after that semester, I lost access to it, so eventually I spent more time reading those wonderful Xerox PARC books about Smalltalk-80 than using Visual Works. As for the VM primitives in Assembly, I also liked it, but many people see that as a disadvantage, like you mention.
      - nickpsecurity 11y ago
        Thanks for the detailed reply. Yeah, that is interesting. Closer to the LISP machines than most development environments. Might make me revisit Smalltalk just because it's so hard to get people to try LISP.