Earlier quoted context omitted.
By all accounts, LispM's were awesome systems to use but lost out due to heavy marketing from unix vendor companies.
They were also really expensive, and there have always been people who hated Lisp for the syntax.
Unix as IDE
21–30 of 214 posts
Re: Unix as IDE
#22Re: Unix as IDE
#23>But I think that trying to shoehorn Vim or Emacs into becoming something that it’s not isn’t quite thinking about the problem in the right way. ...Well, this is clearly a Vim user. If you're never leaving Emacs, and you're writing plugins to do everything inside it, you're using Emacs exactly as intended.
"It was all just text. Why did you need another application for it? Why should only the shell prompt be editable? Why can’t I move my cursor up a few lines to where the last command spewed out its results? All these problems simply disappear when your shell (or shells) simply becomes another Emacs buffer, upon which all of the text manipulation power of Emacs can be brought to bear."
Re: Unix as IDE
#24Earlier quoted context omitted.
They were also really expensive, and there have always been people who hated Lisp for the syntax.
Lisp's syntax is okay, but its semantics is absolutely horrendous. 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 civilized languages), Lisp is an even worse low-level systems language. In the 80's, the only way one could reasonably hope to use Lisp as a systems l…
Given, it can be unpleaseant in certain contexts, but Lisp has really good metaprogramming support, so you can add syntax for a runtime type system relatively simply. It's not optimal, and it certaibly isn't the fastest thing, but it works if you want it.
And nowadays, CL (and several of the Schemes) provide more powerful type systems, and sometimes even compile-time typing. All optional, of course.
Re: Unix as IDE
#25Earlier quoted context omitted.
Yeah, emacs would be a great operating system, if only it came with a decent text editor. (ducks)
Someone fixed that. My emacs came with good modal editing out of the box. Maybe your emacs is broken. Try spacemacs.org. (runs)
(dodges)
Re: Unix as IDE
#26>But I think that trying to shoehorn Vim or Emacs into becoming something that it’s not isn’t quite thinking about the problem in the right way. ...Well, this is clearly a Vim user. If you're never leaving Emacs, and you're writing plugins to do everything inside it, you're using Emacs exactly as intended.
:-)
Re: Unix as IDE
#27Earlier quoted context omitted.
Yeah, emacs would be a great operating system, if only it came with a decent text editor. (ducks)
Someone fixed that. My emacs came with good modal editing out of the box. Maybe your emacs is broken. Try spacemacs.org. (runs)
Re: Unix as IDE
#28At some point I realized Unix is basically a long-running IDE + REPL, and thought that was just so cool . And then I realized how horribly inefficient it is at being that. So I started longing for the days when we had some kind of OS where it actually is a IDE + REPL, like an OS based on Lisp. And then I learned that that already was done and didn't turn out as cool as people had hoped. Oh well.
The C64 was like that. Not Lisp but it booted right into a BASIC REPL. BASIC was the C64's operating system. I still think there is a niche for such a system today (mainly for developing rapidly changing business applications you'd nowadays use Excel for, as well as education).
Re: Unix as IDE
#29Earlier quoted context omitted.
They were also really expensive, and there have always been people who hated Lisp for the syntax.
Lisp's syntax is okay, but its semantics is absolutely horrendous. 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 civilized languages), Lisp is an even worse low-level systems language. In the 80's, the only way one could reasonably hope to use Lisp as a systems l…
> 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 civilized languages)
There are many more high-level features, than static semantics. Lisp is designed for runtime flexibility, not static semantics. Runtime flexibility allows lots of interesting high-level features.
> In the 80's, the only way one could reasonably hope to use Lisp as a systems language was to run it on hardware explicitly designed to run Lisp.
Lisp ran fine on five MIPS machines. Current systems have several hundred times the compute power.
The hardware was explicitly designed for Lisp in the late 70s when nothing comparable was available (single-user powerful workstations for AI/Math researchers developing large systems like Macsyma) and most development took place on time-shared mainframes with many users. The market that demanded this was a high-end market, thus the systems were developed, even though the were expensive.
Starting in the mid 80s, Common Lisp was moved to 1 to 10 MIPS workstations from SUN, SGI, Apollo, DEC, IBM, NeXT, Tectronix, and many others. The main problem at that time was that it would need 10 MByte RAM to run efficiently, which was expensive in the early 80s.
10 Mbyte. Today Lisp runs fine on an modern processor and some people tinker with Lisp-based operating systems, again.
> Of course, hardware support for features like dynamic typing and efficient dynamic allocation of lots of small objects doesn't come for free - this is what made Lisp machines expensive.
What made them expensive was the custom development for a small market, ten to twenty years ahead of their time. It was not the technology complexity of the hardware. People were buying future technology for lots of money, where comparable technology would appear 20 years later - the first Lisp Machines with object-oriented operating systems appeared in the late 70s for $100000 a piece.
Some of Lisp Machines used 8 bit ECC to provide error checking and correction, when memory wasn't that reliable. It made them even more expensive, because ECC memory was even more expensive than normal memory boards. With memory sizes from 4MB to 20MB.
Minor Lisp/Smalltalk support then went into the SPARC chips from SUN. Lisp ran quite well on those.
> dynamic typing and efficient dynamic allocation of lots of small objects
Every iPhone does that now, since Apple's Objective-C and the iOS frameworks are actually that: efficient dynamic allocation, of runtime-typed small and large objects.
If you want to see Lisp on a small machine, buy a Roomba cleaner.
http://www.irobot.com/For-the-Home/Vacuuming/Roomba.aspx
Their software was developed in Lisp already twenty years ago on tiniest hardware.
https://en.wikipedia.org/wiki/Roomba
L – A Common Lisp for Embedded Systems https://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf
It will clean your home, using Lisp on tiny hardware.
Re: Unix as IDE
#30>But I think that trying to shoehorn Vim or Emacs into becoming something that it’s not isn’t quite thinking about the problem in the right way. ...Well, this is clearly a Vim user. If you're never leaving Emacs, and you're writing plugins to do everything inside it, you're using Emacs exactly as intended.
I bet Emacs has a plugin that makes it like Vim, so Emacs is not that bad. :-)