6 ms·

Lisp ran on the first UNIX workstations too, Franz Lisp ran fine on even the earliest Sun machines. Lucid pivoted from Lisp on UNIX to C++ on UNIX, they didn't

by rjsw 9y ago

Lisp ran on the first UNIX workstations too, Franz Lisp ran fine on even the earliest Sun machines. Lucid pivoted from Lisp on UNIX to C++ on UNIX, they didn't have anything to do with Lisp Machines.

pjmlp 9y ago
Correct, but it wasn't part of the platform tooling, requiring an additional expense, with a price tag which on the 80's computing world very few companies were willing to shell out. Yep, I always get that part of Lucid's history wrong.
- lispm 9y ago
  Actually Lisp systems were no more expensive than other advanced language implementations. But one needed a bunch of expensive RAM. At that time there were already free implementations of Common Lisp for Unix: AKCL (later GCL), CMUCL, CLISP, XLISP, ... IDE for those were usualy GNU Emacs or Xemacs with ILISP. Windows had less choice for free implementations, but one used the commercial implementations anyway and some were not that expensive. On the Mac everyone used Macintosh Common Lisp - which at some point was owned and sold by Apple itself - not very expensive.
- rjsw 9y ago
  Franz Lisp was free.
- e12e 9y ago
  > wasn't part of the platform tooling I think lisp did (to a lesser extent still do) suffer from the "whole system syndrome" that also affected Smalltalk; I'm still not sure that I'd find it comfortable to marry small lisp programs with a shell pipeline, or convenient to work with sockets, files or even databases in a familiar way from within common lisp. Nor would i know how to easily share such code (although quicklisp has made strides her). That is to say, you could probably write ansible/puppet in common lisp - but I'm not sure if you should. Certain special programs, like unison (in ocaml)[1] combine breaking new ground, doing something a little complicated - and justify the use of a powerful language. Other examples might be pandoc (haskell) or gnu guix (scheme software/Os manager). Perhaps it's wrong to throw scheme under the bus, for common lisp being too full of features. But my (admittedly superficial) impression is that even "pragmatic" schemes tend to be difficult to integrate as system glue; that means both on a single platform (use for scripting, piping files, writing config files, start/stop services - Running Os commands) and as cross-platform (either distribution of artifacts for different systems, like an exe for Windows and elf binaries for Linux and bsds - or readily available run-times that work well on multiple platforms). It may well be that many of these issues are fixed today - but the impression that sbcl is a poor fit for a system language for writing parts that are easy to integrate well remain. Both if you want a deb/msi package of a gui app, and if you want to drop some binaries in /usr/local/bin to call snippets of code that work well with the shell. [ed: What is funny/sad is that java kept almost everything that was bad with lisp/smalltalk, and very few of the really good parts. But they introduced a more familiar api for files, streams etc - and managed to push for the jvm to be installed everywhere.] [0] http://www.cis.upenn.edu/~bcpierce/unison/index.html http://www.cis.upenn.edu/~bcpierce/unison/index.html
  - lispm 9y ago
    > I think lisp did (to a lesser extent still do) suffer from the "whole system syndrome There are a bunch of problems of Lisp for systems/application programming: * dynamic typing and dealing with runtime errors * garbage collection vs. real-time response * amount of memory used is usually higher for GCed systems * interoperability with C code and code in other languages * abstraction mismatch between C code and Lisp code. * the need for a foreign function interface to inter-operate with C code * the integration with C++ * the minimum size of a program and how many programs can be started * sharing much of the runtime and library When people started to write lots of Lisp code (80s) then the question of delivery came up. The were a bunch of responses to that: * don't run systems and applications in Lisp, for example rewrite the Lisp applications into C++ (smaller footprint, possibly faster execution, ...) * develop new Lisp-like programming languages, but which are more efficient to implement. Example: Apple's Dylan or see Dynace ( https://github.com/blakemcbride/Dynace ) * develop special Lisp implementations which address the above issues and are specialized in application delivery Let's look at the latter approach. Germany had for example the Apply project which for example created the CLICC compiler ( https://www.informatik.uni-kiel.de/~wg/clicc.html https://www.informatik.uni-kiel.de/~wg/clicc.html ). CLICC is a whole-program compiler for a restricted subset of Common Lisp. mocl is based on CLICC and was/is a commercial CL compiler for macOS X, Android and iOS. There are a bunch of similar compilers (Thinlisp is one https://www.cliki.net/ThinLisp https://www.cliki.net/ThinLisp ). Many years ago Oracle also bought an Lisp compiler (which was very expensive for users, IIRC in the range of $100k), which actually generated 'maintainable' C code. Another interesting system is WCL: https://github.com/wadehennessey/wcl https://github.com/wadehennessey/wcl WCL allows one to use Common Lisp as a shared library (mostly). Each Lisp application starts with tiny RAM usage and tiny application size. This allows to run possibly hundreds of smallish Lisp applications at the same time. Eclipse was a Common Lisp which has a direct integration in C and compilation to C, which made something like a Foreign Function interface unnecessary: https://github.com/blakemcbride/eclipse-lisp https://github.com/blakemcbride/eclipse-lisp Generally these tools are often 'old', not widely used and not many applications have been written with them.
    - e12e 9y ago

by rjsw 9y ago

Lisp ran on the first UNIX workstations too, Franz Lisp ran fine on even the earliest Sun machines. Lucid pivoted from Lisp on UNIX to C++ on UNIX, they didn't have anything to do with Lisp Machines.

pjmlp 9y ago

Correct, but it wasn't part of the platform tooling, requiring an additional expense, with a price tag which on the 80's computing world very few companies were willing to shell out. Yep, I always get that part of Lucid's history wrong.

lispm 9y ago
Actually Lisp systems were no more expensive than other advanced language implementations. But one needed a bunch of expensive RAM. At that time there were already free implementations of Common Lisp for Unix: AKCL (later GCL), CMUCL, CLISP, XLISP, ... IDE for those were usualy GNU Emacs or Xemacs with ILISP. Windows had less choice for free implementations, but one used the commercial implementations anyway and some were not that expensive. On the Mac everyone used Macintosh Common Lisp - which at some point was owned and sold by Apple itself - not very expensive.
rjsw 9y ago
Franz Lisp was free.
e12e 9y ago
> wasn't part of the platform tooling I think lisp did (to a lesser extent still do) suffer from the "whole system syndrome" that also affected Smalltalk; I'm still not sure that I'd find it comfortable to marry small lisp programs with a shell pipeline, or convenient to work with sockets, files or even databases in a familiar way from within common lisp. Nor would i know how to easily share such code (although quicklisp has made strides her). That is to say, you could probably write ansible/puppet in common lisp - but I'm not sure if you should. Certain special programs, like unison (in ocaml)[1] combine breaking new ground, doing something a little complicated - and justify the use of a powerful language. Other examples might be pandoc (haskell) or gnu guix (scheme software/Os manager). Perhaps it's wrong to throw scheme under the bus, for common lisp being too full of features. But my (admittedly superficial) impression is that even "pragmatic" schemes tend to be difficult to integrate as system glue; that means both on a single platform (use for scripting, piping files, writing config files, start/stop services - Running Os commands) and as cross-platform (either distribution of artifacts for different systems, like an exe for Windows and elf binaries for Linux and bsds - or readily available run-times that work well on multiple platforms). It may well be that many of these issues are fixed today - but the impression that sbcl is a poor fit for a system language for writing parts that are easy to integrate well remain. Both if you want a deb/msi package of a gui app, and if you want to drop some binaries in /usr/local/bin to call snippets of code that work well with the shell. [ed: What is funny/sad is that java kept almost everything that was bad with lisp/smalltalk, and very few of the really good parts. But they introduced a more familiar api for files, streams etc - and managed to push for the jvm to be installed everywhere.] [0] http://www.cis.upenn.edu/~bcpierce/unison/index.html http://www.cis.upenn.edu/~bcpierce/unison/index.html
- lispm 9y ago
  > I think lisp did (to a lesser extent still do) suffer from the "whole system syndrome There are a bunch of problems of Lisp for systems/application programming: * dynamic typing and dealing with runtime errors * garbage collection vs. real-time response * amount of memory used is usually higher for GCed systems * interoperability with C code and code in other languages * abstraction mismatch between C code and Lisp code. * the need for a foreign function interface to inter-operate with C code * the integration with C++ * the minimum size of a program and how many programs can be started * sharing much of the runtime and library When people started to write lots of Lisp code (80s) then the question of delivery came up. The were a bunch of responses to that: * don't run systems and applications in Lisp, for example rewrite the Lisp applications into C++ (smaller footprint, possibly faster execution, ...) * develop new Lisp-like programming languages, but which are more efficient to implement. Example: Apple's Dylan or see Dynace ( https://github.com/blakemcbride/Dynace ) * develop special Lisp implementations which address the above issues and are specialized in application delivery Let's look at the latter approach. Germany had for example the Apply project which for example created the CLICC compiler ( https://www.informatik.uni-kiel.de/~wg/clicc.html https://www.informatik.uni-kiel.de/~wg/clicc.html ). CLICC is a whole-program compiler for a restricted subset of Common Lisp. mocl is based on CLICC and was/is a commercial CL compiler for macOS X, Android and iOS. There are a bunch of similar compilers (Thinlisp is one https://www.cliki.net/ThinLisp https://www.cliki.net/ThinLisp ). Many years ago Oracle also bought an Lisp compiler (which was very expensive for users, IIRC in the range of $100k), which actually generated 'maintainable' C code. Another interesting system is WCL: https://github.com/wadehennessey/wcl https://github.com/wadehennessey/wcl WCL allows one to use Common Lisp as a shared library (mostly). Each Lisp application starts with tiny RAM usage and tiny application size. This allows to run possibly hundreds of smallish Lisp applications at the same time. Eclipse was a Common Lisp which has a direct integration in C and compilation to C, which made something like a Foreign Function interface unnecessary: https://github.com/blakemcbride/eclipse-lisp https://github.com/blakemcbride/eclipse-lisp Generally these tools are often 'old', not widely used and not many applications have been written with them.
  - e12e 9y ago