lispm

1598 ms·

3601.
by lispm 10y ago
The second Lisp OS at Apple was called Bauhaus.
3602.
by lispm 10y ago
http://www.textfiles.com/bitsavers/pdf/xerox/interlisp/31012... Chapter 16 describes DEdit, the display oriented structure editor of Interlisp-D. ALso see for general philosophy of interactive Lisp syste
3603.
by lispm 10y ago
Apple did that once upon a time, while Steve Jobs wasn't there. In a 'perfect' world you would use an iPhone which runs a Lisp OS. Before the iPhone and before the Newton MessagePad, Apple had an ARM-based Newton-like machine
3604.
by lispm 10y ago
It feels very different. Imagine the editor and the runtime work on the same data: EDIT <-> data <-> EVAL In GNU Emacs it looks like this: Emacs EDIT -> text -> Emacs SAVE FILE SBCL LOAD FILE -> SBCL
3605.
by lispm 10y ago
> 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
3606.
by lispm 10y ago
> 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 fr
3607.
by lispm 10y ago
I don't.
3608.
by lispm 10y ago
> I just don't think it matters as much as you do. I said as much. There is a lot of software out there which needs powerful and/or different IDEs to be written. > Although it is telling that SLIME (which is excellent, by th
3609.
by lispm 10y ago
Nobody does that. But for certain areas this is true and you should not ignore that. Grady Booch once at an Eclipse conference: "For those of you looking at the future of development environments, I encourage you to go back and review
3610.
by lispm 10y ago
You would not know that GNU Emacs has a shitty UI, if people would not tell you. > Take the energy you would use doing that, and put it into making your system that much better. It's not easy, but people are/were doing it: CMUC
3611.
by lispm 10y ago
For a very early overview of the technology I would recommend the 3600 Technical Summary. The 3600 was the first machine which was mostly designed by Symbolics. It was followed by three more generations (gate array processor, micro-processo
3612.
by lispm 10y ago
> If that's really your major issue with it... You seem to be misinterpreting me quite often. It's ONE issue. A development environment which is not multithreaded, is not very advanced. > it's quite rare for me to actua
3613.
by lispm 10y ago
YOu can extend GNU Emacs as much as you want, it is always single threaded. For a start. The UI is interestng, but fucked in many ways. That's how it is.
3614.
by lispm 10y ago
Symbolics Genera is so far ahead Emacs, it's not even funny. Even though it is unmaintained since 20 years. Xerox Interlisp-D was similar mind-blowing.
3615.
by lispm 10y ago
Sussman is a Schemer.
3616.
by lispm 10y ago
His name is Pitman. Kent Pitman. > Many of the same people were involved in the standardization effort, and the creation of both. I doubt that this is the case for R7RS. > The thing is, the Scheme community may not be able to share co
3617.
by lispm 10y ago
It's not my definition. I just happen to agree with a lot of others, many who don't post here. It's also not new. I just remind people of a view, you might never heard of, because you never were involved in Lisp meetings, Lis
3618.
by lispm 10y ago
> Despite what the CLers say, we all have an equal claim to the name. Only actual Lisp dialects have a claim to the name. That's why Scheme is called Scheme and not Lexical Lisp. That's why Logo is called Logo and not Simple Li
3619.
by lispm 10y ago
Scheme was earlier developed than Common Lisp. But that's not the whole picture. The mainline of Lisp, which Common Lisp and the early Scheme (partly) is based on, existed earlier: Lisp 1.5 and then Maclisp. Scheme was then developed o
3620.
by lispm 10y ago
> Runtime performance degradation is unacceptable Requirements like these are not grounded in real software use. In economic terms: a cheaper/slower software can be acceptable over a more expensive/faster software. Example: Jav
3621.
by lispm 10y ago
> Why can't I get my computer to perform 1600 times as much concurrent work as back then? Is that a real question? > But the amount of work computers do for us hasn't grown proportionally to the amount of computing power. I
3622.
by lispm 10y ago
Nice rant, but mostly wrong. > Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civ
3623.
by lispm 10y ago
> However, it keeps a lot of ideas from 1.5 that were later dropped by CL and others. Names don't matter: ideas do. That's what I say: vague ideas don't matter much when forming language families. Code does. Books. Librari
3624.
by lispm 10y ago
> Not considering them to be Lisp is ridiculous. Calling them to be Lisp is wrong. > Not considering them to be Lisp is ridiculous. Picolisp is closer to Lisp 1.5 than CL is. How so? CL runs a lot Lisp 1.5 code unchanged. Picolisp not
3625.
by lispm 10y ago
> Well, then, if you don't have macros, then you don't have procedural macros, which was my point. Trivially. Anyway, I don't consider them to be Lisp dialects anyway. They are new languages, Scheme dialects, scripting lan
3626.
by lispm 10y ago
> Well, then it's slowing down compilation. My five MIPS Lisp Machine did not care. My Lisp implementations on a several hundred times faster processor don't care either. These languages you list don't have macros.
3627.
by lispm 10y ago
> AFAICT, splicing unquote has to traverse the entire result list. Not super relevant in this case. Especially since it is usually done once at compile time. > Some Lisps don't even have them. Even most Scheme implementations hav
3628.
by lispm 10y ago
Procedural macros were introduced to Lisp twenty years before CL existed and quasiquotation around ten years before CL existed. > and the splicing unquote is less efficient than cons in this case Not sure why that should be the case and
3629.
by lispm 10y ago
That's not too far away from Lisp. But in Lisp we would be using some quasiquote templates for this simple macro: (defmacro debug-it (&body expressions) `(progn ,@(mapcar (lambda (expression)
3630.
by lispm 10y ago
> Ugh, when you say "Lisp" you're talking about "Common Lisp"? When I say Lisp, I mean Lisp dialects: Maclisp, Interlisp, Standard Lisp, Franz Lisp, EULisp, Euslisp, LeLisp, ISLisp, Common Lisp, ... But not Schem

More ›