4 ms·

I was plenty aware that Emacs had a crummy UI. I just don't think it matters as much as you do. I said as much. >It's not easy, but people are/were doing it...

I was plenty aware that Emacs had a crummy UI. I just don't think it matters as much as you do. I said as much. >It's not easy, but people are/were doing it... That's actually great. I'm tremendously excited by those systems. I tend to prefer Scheme to CL (less cruft), but I'm excited all the same. Those systems and environments are really cool. Although it is telling that SLIME (which is excellent, by the way) is one of the most popular ways to write Lisp code.

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 the way) is one of the most popular ways to write Lisp code. Guess where the inspiration for some of the SLIME features is coming from... Slime also does many cool new things, but it is still missing a lot of features and usability from the old environments. Part of the reason is GNU Emacs. It is what it is: a programmable editor with zillions of features. But its base, its UI, its interaction model, its integration idea is limiting in many ways. Many of the defining/leading IDEs were very different: Smalltalk 80, Interlisp-D, Symbolics Genera, ... Turbo Pascal, Visual Basic, Hypercard, ... NeXT ..., IntelliJ, ... (and a lot of others)
- qwertyuiop924 10y ago
  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 environment, or the point at which the Unix model doesn't really work, and you're going to have to go build your own little world (like Smalltalk did). They certainly aren't perfect, and could go a bit farther (something work is being done on, last I checked), but it usually works well enough, and it's so extensible, and has had so many extensions written for it, that it can beat just about any other general purpose editor, and sometimes even some of the special purpose ones.
  - 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 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, which is called a 'Listener', which is a separate application and which is not based on a Zmacs editor buffer. The Lisp Machine listener has a very different feature set and look&feel, from an ILISP/SLIME repl. The LispWorks listener is a mix of both: it is based on an Emacs substrate, but offers slightly more Lisp Machine like interaction. SLIME though adds a simple presentation system, which LispWorks does not use in the listener. > I want to be able to use on tool to edit all text. 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. Interlisp-D worked with Lisp data throughout the IDE. That's a whole different interaction. > IntelliJ is pretty rubbish It isn't. It's actually quite good at what it does.
    - deleted 10y ago
      [deleted]
    - qwertyuiop924 10y ago
      >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.

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 the way) is one of the most popular ways to write Lisp code. Guess where the inspiration for some of the SLIME features is coming from... Slime also does many cool new things, but it is still missing a lot of features and usability from the old environments. Part of the reason is GNU Emacs. It is what it is: a programmable editor with zillions of features. But its base, its UI, its interaction model, its integration idea is limiting in many ways. Many of the defining/leading IDEs were very different: Smalltalk 80, Interlisp-D, Symbolics Genera, ... Turbo Pascal, Visual Basic, Hypercard, ... NeXT ..., IntelliJ, ... (and a lot of others)

qwertyuiop924 10y ago
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 environment, or the point at which the Unix model doesn't really work, and you're going to have to go build your own little world (like Smalltalk did). They certainly aren't perfect, and could go a bit farther (something work is being done on, last I checked), but it usually works well enough, and it's so extensible, and has had so many extensions written for it, that it can beat just about any other general purpose editor, and sometimes even some of the special purpose ones.
- 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 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, which is called a 'Listener', which is a separate application and which is not based on a Zmacs editor buffer. The Lisp Machine listener has a very different feature set and look&feel, from an ILISP/SLIME repl. The LispWorks listener is a mix of both: it is based on an Emacs substrate, but offers slightly more Lisp Machine like interaction. SLIME though adds a simple presentation system, which LispWorks does not use in the listener. > I want to be able to use on tool to edit all text. 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. Interlisp-D worked with Lisp data throughout the IDE. That's a whole different interaction. > IntelliJ is pretty rubbish It isn't. It's actually quite good at what it does.
  - deleted 10y ago
    [deleted]
  - qwertyuiop924 10y ago
    >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.