Earlier quoted context omitted.
If it is functional(and maybe if not), you can potentially get a decent amount of money from selling that.
Well it certainly isn't imperative!
I would call Commonlisp an imperative language.
Symbolics Lisp Machine Museum
31–40 of 136 posts
Re: Symbolics Lisp Machine Museum
#32Earlier quoted context omitted.
> The superior technology is rarely the "winner" True dat. Unfortunately, as Theo de Raadt once said: "In some industry markets, high quality can be tied to making more money, but I am sure by now all of us know the computer industry is not like that." I think the only thing we can do is follow the trend. This whole industry is not perfect anyway.
We can do more than that. If everybody followed the trend, then Lisp would be dead, and we'd all just write Java. shivers
Thankfully Rich Hickey & co wrote Clojure so we can program on a modern Lisp in the Java Virtual Machine and in the browser! (ClojureScript) (even the .NET CLR is supported)
Re: Symbolics Lisp Machine Museum
#33I used to work with a number of LISP machine believers at the MIT AI Lab/CSAIL. They all had more modern computers for day to day tasks, but used the lispm for most of their programming. This wasn't that long ago (I left in 2010), and I suspect that those machines will remain in active use for as long as people can keep them running. They all believed that the loss of the lisp machine was a serious loss to society an…
It was by far the most productive programming environment I have ever used. The level of integration of the editor, debugger, IO system, and interpreted and compiled code is unparalleled. Interestingly it philosophically descended from MACLISP development on a machine (PDP-10) that was designed with Lisp in mind and that had an O/S (ITS) whose "shell" was a debugger, so you could also do pretty tightly coupled development with EMACS (in TECO) and your code in a mix of interpreted and compiled Lisp. In theory this deep level of integration need not be Lisp-specific, but I haven't seen it that often.
The closest I've used were the three environments at PARC when I was there: Smalltalk, Mesa/Cedar and Interlisp-D. When I use Xcode or Eclipse I feel removed from the machine. In these other environments I felt simultaneously able to think at a higher level and yet more tightly coupled to the hardware.
I've used various GNU Emacs modes and the coupling between them and the runtime environment is not tight enough. Today I use SLIME+SBCL and it's OK. It too lacks the tight coupling of the lispm. However for production we'll end up re-coding in C++ for performance.
PS: A good friend of mine scorns the lispm-style of development as "programming by successive approximation." There's some truth in that.
Re: Symbolics Lisp Machine Museum
#34Who actually owns the Symbolics IP these days? I still wonder if it would be possible to put a 3600 on a chip.
I heard rumor that JCMA had bought it. I'll ask him.
Re: Symbolics Lisp Machine Museum
#35Earlier quoted context omitted.
We can do more than that. If everybody followed the trend, then Lisp would be dead, and we'd all just write Java. shivers
Thankfully Rich Hickey & co wrote Clojure so we can program on a modern Lisp in the Java Virtual Machine and in the browser! (ClojureScript) (even the .NET CLR is supported) [1] http://clojure.org [2] http://clojurescript.org
Not a super fan of Clojure, but it's a good language. Shame it's still stuck in the Java ecosystem, though.
Re: Symbolics Lisp Machine Museum
#36Earlier quoted context omitted.
I am well aware of where SLIME's inspiration comes from. As for IDEs, I have a marked distaste for special purpose tools: I want to be able to use on tool to edit all text. And not all IDEs are good: IntelliJ is pretty rubbish (although that's more to do with Java than IJ itself...) Emacs's limitations tend to line up with the length you can go before you start becoming a special purpose tool, tightly tied to your en…
> I am well aware of where SLIME's inspiration comes from. Obviously not. SLIME's inspiration comes from various other integrations of Lisp into Emacs editors, especially Emacs Lisp and ILISP. SOME of its inspirations comes from the Lisp Machine, direct or indirect. SOME. Not ALL and not even MOST. For example the Lisp Machine does NOT use Zmacs as a Lisp REPL, like ILISP/SLIME/... does. The Lisp Machine has a REPL,…
[deleted]
Re: Symbolics Lisp Machine Museum
#37Earlier quoted context omitted.
I am well aware of where SLIME's inspiration comes from. As for IDEs, I have a marked distaste for special purpose tools: I want to be able to use on tool to edit all text. And not all IDEs are good: IntelliJ is pretty rubbish (although that's more to do with Java than IJ itself...) Emacs's limitations tend to line up with the length you can go before you start becoming a special purpose tool, tightly tied to your en…
> I am well aware of where SLIME's inspiration comes from. Obviously not. SLIME's inspiration comes from various other integrations of Lisp into Emacs editors, especially Emacs Lisp and ILISP. SOME of its inspirations comes from the Lisp Machine, direct or indirect. SOME. Not ALL and not even MOST. For example the Lisp Machine does NOT use Zmacs as a Lisp REPL, like ILISP/SLIME/... does. The Lisp Machine has a REPL,…
>Obviously not.
...And what makes you say that? I was actually aware, in any case.
>A Lisp system is not text-based.
>Lisp is based on data. Code is data and data can be code.
>Using an editor to work with text is only half of the story. A good Lisp IDE lets me more or less directly interact with the data.
I'm aware of that, but text is a fairly convenient representation of Lisp data. In fact, I'm unsure what you mean by directly interacting with the data, as you can't have bytes fly from your fingertips, AFAIK.
In addition, files are a pretty good metaphor as well: If you want to store your code as something textual, they're indispensible. And sure, you can use image storage and navigate in other ways, but Lisp isn't Smalltalk: The way Lisp is written isn't as unified, so that wouldn't work as well, AFAIK.
And sure, IntelliJ does what it does well, but I don't think that what it does is especially good, and most of it is just making up for Java's sins, things that don't exist in other languages: A good development environment is imperative, but if it's painful to write code in the language without the tools IDEs provide, than there's something wrong with the language.
Re: Symbolics Lisp Machine Museum
#38Earlier quoted context omitted.
I used to think likewise (you can check my previous comments). But at the end of the day, you gotta pay the bills... Nonetheless, I have huge respect for CL. I think I'm gonna learn it well once and for all. (maybe use it for back-end).
True 'nuff. I prefer Scheme to CL. The tooling isn't as developed, but Chicken and Guile are both plenty usable, and Scheme is less crufty than CL.
Chicken + some plugins they provide are almost more than enough for most people! Great project.
Re: Symbolics Lisp Machine Museum
#39Earlier quoted context omitted.
...Well, you do. And so do many other Lispers, for that matter. IIRC, I've been guilty of it myself.
I don't.
We all do, to a more or lesser degree. Lispers, in particular, are prone to it. I do it, and I've seen you do it too.
This isn't, by the way, a slight on you. Nor do I dislike you in any way. I do tend to argue with you a lot, but that's because I disagree with you, and I am of the firm belief that you can learn a lot by discussing subjects with people who disagree with you regarding them.
Re: Symbolics Lisp Machine Museum
#40Earlier quoted context omitted.
> I am well aware of where SLIME's inspiration comes from. Obviously not. SLIME's inspiration comes from various other integrations of Lisp into Emacs editors, especially Emacs Lisp and ILISP. SOME of its inspirations comes from the Lisp Machine, direct or indirect. SOME. Not ALL and not even MOST. For example the Lisp Machine does NOT use Zmacs as a Lisp REPL, like ILISP/SLIME/... does. The Lisp Machine has a REPL,…
>Obviously not. ...And what makes you say that? I was actually aware, in any case. >A Lisp system is not text-based. >Lisp is based on data. Code is data and data can be code. >Using an editor to work with text is only half of the story. A good Lisp IDE lets me more or less directly interact with the data. I'm aware of that, but text is a fairly convenient representation of Lisp data. In fact, I'm unsure what you mea…
> I'm aware of that, but text is a fairly convenient representation of Lisp data.
Some Lisp data does not have a textual representation, it might have a graphical representation or the textual representation may not be very helpful (Lisp data being a graph might be better displayed as a 2d or even 3d graph, than as a textual representation). The Symbolics UI of the REPL/Listener would allow you to interact with the 2d/3d graph as it were Lisp data, which it actually is underneath.
> In fact, I'm unsure what you mean by directly interacting with the data, as you can't have bytes fly from your fingertips, AFAIK.
GNU Emacs pushes characters around.
S-Edit manipulates S-expressions.
GNU Emacs lets you pretend that you edit s-expressions, by pushing characters in a buffer around. But you don't. All you do is push text around.
S-Edit directly manipulates the data. It's a structure editor.
Symbolics Genera uses 'presentations' to record for every output (graphical or not) the original Lisp data. When you interact with the interface, you interact with these data objects. For example in a Listener (the REPL) programs and the Listener itself display presentations, which then can be acted on. It also parses text into data objects and then runs the commands on the data objects and not on text.
SLIME provides a very simple and partial reconstruction of that - which is a nice feature.
> In addition, files are a pretty good metaphor as well: If you want to store your code as something textual, they're indispensible. And sure, you can use image storage and navigate in other ways, but Lisp isn't Smalltalk: The way Lisp is written isn't as unified, so that wouldn't work as well, AFAIK.
Smalltalk does not use data as representation for source code. It uses text as representation for source code.
Interlisp-D is more radical than Smalltalk 80. The Smalltalk editor edits text. The Interlisp-D editor S-Edit edits s-expressions as data.
Interlisp-D treats the files as a code database similar to Smalltalk, but the source code loaded remains data and you can run the program from that data directly via the Lisp interpreter. Smalltalk execution does not provide something like that. The so-called interpreter in Smalltalk executes bytecode. This is different from a Lisp interpreter, which works over the Lisp source data.
The combination of a s-expression editor with an s-expression interpreter (plus optional compilation) is very different, from what Smalltalk 80 did.
When you mark an expression in Smalltalk 80 and execute it via a menu command, then the expression gets compiled to bytecode and the bytecode interpreter then runs it.
If you mark an expression in S-Edit, the s-expression data is extracted from the data structure you edit and you can run that s-expression data with an interpreter, walking directly over that s-expression data.