Though I haven't programmed in Qi (which runs atop a Common Lisp environment), I have read up about its extensible type system. It looks powerful and might be useful for what you're doing.
You also have to worry about memory usage and runtime determinism - When restarting an engine at 10,000 feet or on takeoff[1] some things MUST happen at certain times as quickly as possible. GC isn't an option, and "oops out of memory" isn't an option either.
It comes down to it that lisp doesn't have the ecosystem behind it for life-crtical applications. I doubt it ever will.
What it is useful for though is analysis tools - helping keep people out of those life endangering situations.
While I have personally never programed life critical stuff, I interacted closely (on the algorithmic side) with people who did. This was in the railroad industry.
They used a subset of C (no malloc...) and had a safety certified compiler. If you crash two trains because of a compiler bug at least you can pass the bunk. They did not use formal proof methods.
The documentation was massive, substantially longer than the code, to the extent that doing the actual implementation from the documentation seemed relatively trivial. Writing and analyzing the documentation on the other hand... I had the impression that writing documentation to that level of detail must have taken substantially longer than implementing it directly in code. And this was probably a good thing as it forced people to think more about every details.
Once a system was written it had to be certified. Any changes, no matter how trivial, meant you had to go through the whole certification process again: slow, painful and expensive.
Doesn't the documentation have to then become as rigorous as code --- effectively a high-level language in its own right? So writing the documentation becomes, well, just like writing a program without testing it as you go, without benefit of tests or (if desired) static type checking. If so, then the development process turns the programmer into a kind of human compiler: translating the specs into a dialect of C for the safety-certified compiler.
Actually the formal document languages have type checking and consistency analysis systems/tools.
Tools like Alloy[1] allow you to write your documentation/definition and check its consistency. These languages are always limited so you don't get into Gödel incompleteness problems.
I do avionics and am personally working slowly on an aviation startup (I hate the word!) in the experimental/homebuilt space.
Ada is used in the realtime life critical stuff because of the huge ecosystem from tools to paperwork behind it supporting safety. I could use C I suppose, but I simply am not smart enough to not miss a pointer dereference now and then.
Chiming in to the chorus: what do you use for that type of programming? How does it support the kinds of formal proofs you mentioned? Although I have proven the correctness of some simple code, I have found that the proof and the code can diverge too much to mean much. (Some of people interviewed in Coders at Work said the same thing.) Do your tools unify the proof and the code somehow?
Er. Doing a very quick search on Google for "real time lisp" and "embedded real time lisp" returned quite a few links and papers showing that people have and continue to be interested in such developments.
I mostly do client-side Web development - JavaScript and Flash - and prefer to write in the native languages of the platform to leave less space for bugs to hide. (Even MTASC, the very good indie Flash compiler, turned out to contain obscure bugs after I abused it for a couple years.) And my server-side stuff is simple enough that Lisp wouldn't be a big win space-wise over the handful of PHP one-pagers that I tend to write. Lisp also loses to PHP on maturity, documentation and support - whenever I stumble on some exotic webapp-specific problem, chances are it's already covered in detail on php.net. It looks like Perl and Python have ecosystems of similar quality, and some of my friends swear by the Microsoft tech stack, but unfortunately I can't trust Lisp to the same degree.
If I ever encounter a problem where cleverness of programming is the limiting factor, I'll probably use some advanced language (yep, I can handle Lisps, ML/Haskell or even APL/K passably well). But such problems just aren't very common. On most projects I spend most of the time figuring out how to solve this user problem on that programming platform as directly as possible, not solving mathy type puzzles.
Lisp also loses to PHP on maturity, documentation and support
Lisp is 50 years old and standardized for 15 years. Has both an ANSI and ISO standard, freely available books and manuals written by the best and the brightest of the Art. There are 4 commercial Lisp companies and a total of 8 standard-compliant implementations.
There is absolutely no comparison, and it's both telling and sad you would utter them in the same sentence. Take it back.
A better way of stating it, is that while Lisp is older, there is a lack of real world experience, documentation, and support for using Lisp as a language for web development. The volume of material, understanding, and optimization strategy for PHP is far and away greater than Lisp.
As an example, search for a simple question on how to do some developmental task on google for both PHP and Lisp. PHP will have more informative pages.
(also available in 7-8 other languages). Note all useful string concepts are one click away, and the documentation allows user commentary (much of which is quite helpful).
In Common Lisp, strings are a subtype of Sequences :-) The PHP String library you linked to is appalling. It includes a lot of stuff that shouldn't be squashed together in one "section"; strings, characters, locale management, i18n, cryptography, sequences, generic formatter, currency parsing and formatting, uu(en|de)coding, even fuzzy string matching!
Who does this appeal to? no abstraction, no modularity, no visible type hierarchy or any sense of order.
I wasn't commenting pro-php; the php api design isn't going to win any awards other than popularity.
You're not really responding to the point I was raising: poorly-designed or not, php's official site has easily-findable and easily-accessible documentation (which it needs given the quality of the api design); its official central documentation site is well within the range of modern best practices.
There's not to my knowledge a comparable common lisp online reference (reference, not tutorial) that's anywhere near as accessible to the beginner or intermediate user (that nebulous phase between getting through a few tutorials and having deep knowledge).
...which I'd say is probably the best of the online manuals.
But more to the point:
There are minor issues with the formatting of the hyperspec no one's bothered fixing. Aside from the lack of a pretty stylesheet and the lack of wiki-style user comments
The most obvious is that if I eg go to the Strings or Array section it just gives me a page with a sub-table of contents; it'd be a lot friendlier to have all the Array or String docs on a single html page.
This wouldn't even be that hard to implement, and the "moar docs on one page" approach to online docs keeps winning out for a reason (it's easier to find what you're looking for if you only know approximately where it is if you can get everything that might be related on a single page and ctrl-f your way through it; having deeply-nested content is far unfriendlier).
I do think the hyperspec is not very well-thought-through as end-user documentation.
It mixes levels of concerns that ought to be separate; someone reading documentation with the goal of finding out if there's a built-in function for "split a string delimited by a particular character into a list of strings?" has very different requirements from someone who needs to know how strings are implemented, for example.
IMHO the hyperspec tries to do both; it's fine as a nitty-gritty reference but could be improved as a day-to-day programmer's reference.
Python's docs are a good example of end-user documentation done right. They have a clearly-delineated split between the language specification ( http://docs.python.org/reference/index.html ) and the standard library specification ( http://docs.python.org/library/index.html ) and additional, separate documentation over lower-level aspects of implementation.
Each body of documentation is organized for the convenience of its typical user.
Yes all of this I know; you claimed common lisp has superior documentation to php and I've consistently shown you ways in which even php's documentation is superior to that possessed by common lisp at this time (at least in any sense that matters to me).
I should clarify: there certainly is documentation for common lisp, some of it quite good; the situation is that in many ways common lisp's documentation is outclassed by even php's documentation.
Let's turn this around: take a good look at php.net; put aside your disdain for the language (blech!) and just look at how the documentation is structured, in terms of organization (high level and low-level, like in what size chunks it's presented in).
Do you really think there is nothing to be learned from how the php people have assembled their official documentation?
I'd additionally argue that as nice as in-environment documentation is it's a sub-optimal approach to accessibility.
Part of the issue is for the abject beginner it multiplies the things to learn: everyone knows how to work firefox and google and can google something to see what turns up; having to learn how to work the in-environment documentation takes you from one problem ("how do i shot web?") to two problems ("how do i shot web?" and "how is docs found?"). A serious student will pick it up pretty quickly but .
The larger issue is that the lack of a central documentation + discussion hub means that there's no system taking the informal knowledge possessed by discrete practitioners -- stuff like what implementations of what functions on which platforms have unanticipated quirks, or what function non-newbies typically use instead of the function you're currently reading the docs for -- and capturing it for posterity in an easily-searchable format.
Some of that information can be gleaned from usenet and mailing list archives if you know to search there and have time to wade through flames and trolls and other gunk, but the rest of it is stuck in the minds of individuals and is therefore largely inaccessible.
The php approach (which is used by other projects, like eg mysql and pgsql) of having a central online documentation area with integrated user comments is that it provides a natural place for such informal knowledge to wind up; once it's there once it's there for everyone (and can be googled and so on).
You could create an in-environment system that had most of these advantages -- some "social" version of the docs, essentially a wiki-ish system -- but that's hypothetical, and I'm talking concretely, and concretely the available common lisp documentation is largely outclassed by the documentation available for php (and for python, and java, and c#, and many others).
As a parting note you really shouldn't underestimate the advantage of dumping more information into a single page.
Much of the useful knowledge about a language and its core libraries is knowing the logical structure of how everything fits together; much of this is never documented in any formal way, but can be inferred from an overview of the larger-scale organization.
When you present stuff all on one page it's pretty easy to take this in: notice how quickly you could tell the php strings api was poorly designed? That's b/c you could at a glance see everything that was relevant and infer the entire structure (or lack thereof).
When you present things in tiny little atomized chunks it requires much more effort for the reader to get the birds-eye view of the system, as the reader is not provided the convenience of seeing it all laid out in one place.
Aaaaaannnd... this is the number two reason Lisp's are not more successful (number one being the syntax, although that is somewhat related). Instead of helping to solve your problem, advocates (and the reference documents, "tutorials") want to engage in academic chest beating exercises.
How hard is it just to acknowledge, just a teeny bit, that PHP is more successuful than Lisp for real reasons -- not just because everyone but you is an idiot. That's nice that you think the string library is appalling. Perhaps it is -- but jesus, how do you even get work done with an attitude like that? Do you write everything you do from scratch?
Go write a graduate paper on the perfect string library and others can get real work done.
You're thrown a typical webdev task, like setting the filesize limit for user uploads. Quick, how much time will it take in CL? Connect to MySQL and store some data. How many minutes, how many lines of code, how many libraries downloaded? Now determine the dimensions of a jpeg image. And parse some JSON from a file. Faster! (In PHP we haven't even left the standard library yet. It's that perfectly tailored for what web people do.) A weird problem arises, what's the chance that some PHP user had it before and wrote it up, compared to CL user? Something more complex: HTTP request goes in, ping to payment system goes out, file starts downloading with correct mimetype, where do you go for working code examples? You need to move your app to another webhost, how much hassle will it take? Client needs a CMS, which one do you pick, and how often does it get security updates? You make your app open source and people want to install it, what instructions do you give them?
Yes dammit, let's get practical. Let's get our hands dirty. I love this stuff.
You are showing a complete misunderstanding of software engineering. You don't go running around looking for examples and installing 3rd party packages willy nilly. Weird problems don't just "arise" out of the blue, and although there is some urgency to things there is never any chaos. Things are a bit more controlled, and you are assumed to know what you're doing, Lisp or otherwise.
I use lisp and every time I tell another programmer that I use lisp their face morphs into a mask of shock and horror.
They're all like 'how do you use lisp all the time' and I'm like 'well lisp is very powerful', and they say 'yeah it is, but how can you stand to use lisp all the time!' and I really don't know how to respond because using lisp seems more natural than something like C or Java where I have to be very explicit about everything that I want and put in very specific syntax.
That's the easiest and most superficial rationalization for not bothering to try a Lisp (any Lisp), but also the least compelling argument against it, and likely not even the most significant actual reason you haven't bothered to learn it.
I was joking about the syntax and the way how I just can't wrap my brain around reading lisp and matching parentheses.
I was not joking about the recursive and functional nature of Lisp, both of which I'm finding very interesting (and my coworker is, in fact, a big fan of Haskell)
He dismisses "lack of support for modern programming practice" far, far too easily. Clojure is modern. CL is not. That lack of modernity is a serious reason not to use it.
Except that the answer would simply be nonsense if applied to Clojure. It does too have safe, fairly lightweight concurrency, FP and immutable persistent data, both a standard library with all the trimmings and scads of add-ons (via Java), yadda yadda, modernity out the wazoo. What's it missing?
(I think the actual answer here is: mindshare. Respondents heard Lisp and assumed CL, maybe Scheme.)
You are a programmer: your primary responsibility is problem understanding, searching the solution-space and evaluating your options.
Even an automaton like the Google algorithm can search data and correlate them. When I type "Common" it auto-completes "Lisp". You should be able to search, find, and compare technologies on their own merit.
The entire programming fora are burning with altruistic recommendations for free Lisp books, some of them classics of the field.
A very convenient "have you stopped beating your wife" type poll. Isn't it funny how one can create a movement from ether by just setting up a loaded questionnaire online?
Instead of an anonymous and questionable poll setup by someone with an axe to grind[1] I give you The Road to Lisp. Real names, real people:
[1] The author of that blog is a NewLisp user who made it a habit to troll comp.lang.lisp and other Lisp fora, demanding people treat NewLisp as an equal/real Lisp.
45 comments
[ 3.2 ms ] story [ 107 ms ] threadFor offline analysis and general cocking about though, it's the bee's knees.
It comes down to it that lisp doesn't have the ecosystem behind it for life-crtical applications. I doubt it ever will.
What it is useful for though is analysis tools - helping keep people out of those life endangering situations.
1. See Diamond da-42 takeoff crashes.
They used a subset of C (no malloc...) and had a safety certified compiler. If you crash two trains because of a compiler bug at least you can pass the bunk. They did not use formal proof methods.
The documentation was massive, substantially longer than the code, to the extent that doing the actual implementation from the documentation seemed relatively trivial. Writing and analyzing the documentation on the other hand... I had the impression that writing documentation to that level of detail must have taken substantially longer than implementing it directly in code. And this was probably a good thing as it forced people to think more about every details.
Once a system was written it had to be certified. Any changes, no matter how trivial, meant you had to go through the whole certification process again: slow, painful and expensive.
Tools like Alloy[1] allow you to write your documentation/definition and check its consistency. These languages are always limited so you don't get into Gödel incompleteness problems.
1. http://alloy.mit.edu/alloy4/
Ada is used in the realtime life critical stuff because of the huge ecosystem from tools to paperwork behind it supporting safety. I could use C I suppose, but I simply am not smart enough to not miss a pointer dereference now and then.
Also quite famously: http://www.flownet.com/gat/jpl-lisp.html
If I ever encounter a problem where cleverness of programming is the limiting factor, I'll probably use some advanced language (yep, I can handle Lisps, ML/Haskell or even APL/K passably well). But such problems just aren't very common. On most projects I spend most of the time figuring out how to solve this user problem on that programming platform as directly as possible, not solving mathy type puzzles.
Lisp is 50 years old and standardized for 15 years. Has both an ANSI and ISO standard, freely available books and manuals written by the best and the brightest of the Art. There are 4 commercial Lisp companies and a total of 8 standard-compliant implementations.
There is absolutely no comparison, and it's both telling and sad you would utter them in the same sentence. Take it back.
As an example, search for a simple question on how to do some developmental task on google for both PHP and Lisp. PHP will have more informative pages.
http://www.php.net/manual/en/book.strings.php
(also available in 7-8 other languages). Note all useful string concepts are one click away, and the documentation allows user commentary (much of which is quite helpful).
Common Lisp Hyperspec landing page for Strings:
http://www.lispworks.com/documentation/HyperSpec/Body/16_.ht...
CMUCL string documentation:
http://common-lisp.net/project/cmucl/doc/cmu-user/unicode.ht...
SBCL's manual has no "table of contents" item that even mentions strings.
Stuff like this matters if you care about accessibility.
It should be trivial to google yourself a well-documented list of a given language's standard string functions without a lot of work.
Who does this appeal to? no abstraction, no modularity, no visible type hierarchy or any sense of order.
You're not really responding to the point I was raising: poorly-designed or not, php's official site has easily-findable and easily-accessible documentation (which it needs given the quality of the api design); its official central documentation site is well within the range of modern best practices.
There's not to my knowledge a comparable common lisp online reference (reference, not tutorial) that's anywhere near as accessible to the beginner or intermediate user (that nebulous phase between getting through a few tutorials and having deep knowledge).
These are all excellent resources:
http://java.sun.com/javase/6/docs/api/
http://docs.python.org/
http://www.ruby-lang.org/en/documentation/
http://www.php.net/manual/en/
http://clojure.org/Reference
...etc., where is the common lisp equivalent that won't look out of place (in terms of contents + organization)?
Stuff like this matters for accessibility and usability.
Please tell me which part of it is "inaccessible".
I thought you'd link to this, which is better:
http://www.franz.com/support/documentation/8.1/doc/contents....
...which I'd say is probably the best of the online manuals.
But more to the point:
There are minor issues with the formatting of the hyperspec no one's bothered fixing. Aside from the lack of a pretty stylesheet and the lack of wiki-style user comments
The most obvious is that if I eg go to the Strings or Array section it just gives me a page with a sub-table of contents; it'd be a lot friendlier to have all the Array or String docs on a single html page.
This wouldn't even be that hard to implement, and the "moar docs on one page" approach to online docs keeps winning out for a reason (it's easier to find what you're looking for if you only know approximately where it is if you can get everything that might be related on a single page and ctrl-f your way through it; having deeply-nested content is far unfriendlier).
I do think the hyperspec is not very well-thought-through as end-user documentation.
It mixes levels of concerns that ought to be separate; someone reading documentation with the goal of finding out if there's a built-in function for "split a string delimited by a particular character into a list of strings?" has very different requirements from someone who needs to know how strings are implemented, for example.
IMHO the hyperspec tries to do both; it's fine as a nitty-gritty reference but could be improved as a day-to-day programmer's reference.
Python's docs are a good example of end-user documentation done right. They have a clearly-delineated split between the language specification ( http://docs.python.org/reference/index.html ) and the standard library specification ( http://docs.python.org/library/index.html ) and additional, separate documentation over lower-level aspects of implementation.
Each body of documentation is organized for the convenience of its typical user.
There are at least two dead-tree manuals other than the hyperspec; CLtL2 and the book by Franz.
Nearly all your documentation reading will be done within your development environment anyway.
I should clarify: there certainly is documentation for common lisp, some of it quite good; the situation is that in many ways common lisp's documentation is outclassed by even php's documentation.
Let's turn this around: take a good look at php.net; put aside your disdain for the language (blech!) and just look at how the documentation is structured, in terms of organization (high level and low-level, like in what size chunks it's presented in).
Do you really think there is nothing to be learned from how the php people have assembled their official documentation?
I'd additionally argue that as nice as in-environment documentation is it's a sub-optimal approach to accessibility.
Part of the issue is for the abject beginner it multiplies the things to learn: everyone knows how to work firefox and google and can google something to see what turns up; having to learn how to work the in-environment documentation takes you from one problem ("how do i shot web?") to two problems ("how do i shot web?" and "how is docs found?"). A serious student will pick it up pretty quickly but .
The larger issue is that the lack of a central documentation + discussion hub means that there's no system taking the informal knowledge possessed by discrete practitioners -- stuff like what implementations of what functions on which platforms have unanticipated quirks, or what function non-newbies typically use instead of the function you're currently reading the docs for -- and capturing it for posterity in an easily-searchable format.
Some of that information can be gleaned from usenet and mailing list archives if you know to search there and have time to wade through flames and trolls and other gunk, but the rest of it is stuck in the minds of individuals and is therefore largely inaccessible.
The php approach (which is used by other projects, like eg mysql and pgsql) of having a central online documentation area with integrated user comments is that it provides a natural place for such informal knowledge to wind up; once it's there once it's there for everyone (and can be googled and so on).
You could create an in-environment system that had most of these advantages -- some "social" version of the docs, essentially a wiki-ish system -- but that's hypothetical, and I'm talking concretely, and concretely the available common lisp documentation is largely outclassed by the documentation available for php (and for python, and java, and c#, and many others).
As a parting note you really shouldn't underestimate the advantage of dumping more information into a single page.
Much of the useful knowledge about a language and its core libraries is knowing the logical structure of how everything fits together; much of this is never documented in any formal way, but can be inferred from an overview of the larger-scale organization.
When you present stuff all on one page it's pretty easy to take this in: notice how quickly you could tell the php strings api was poorly designed? That's b/c you could at a glance see everything that was relevant and infer the entire structure (or lack thereof).
When you present things in tiny little atomized chunks it requires much more effort for the reader to get the birds-eye view of the system, as the reader is not provided the convenience of seeing it all laid out in one place.
How hard is it just to acknowledge, just a teeny bit, that PHP is more successuful than Lisp for real reasons -- not just because everyone but you is an idiot. That's nice that you think the string library is appalling. Perhaps it is -- but jesus, how do you even get work done with an attitude like that? Do you write everything you do from scratch?
Go write a graduate paper on the perfect string library and others can get real work done.
What problem are you trying to solve? Look at the manual and search Cliki to find what you need.
http://www.cliki.net/index
I really wish programmers would stop acting so helpless and fetch for themselves.
You're thrown a typical webdev task, like setting the filesize limit for user uploads. Quick, how much time will it take in CL? Connect to MySQL and store some data. How many minutes, how many lines of code, how many libraries downloaded? Now determine the dimensions of a jpeg image. And parse some JSON from a file. Faster! (In PHP we haven't even left the standard library yet. It's that perfectly tailored for what web people do.) A weird problem arises, what's the chance that some PHP user had it before and wrote it up, compared to CL user? Something more complex: HTTP request goes in, ping to payment system goes out, file starts downloading with correct mimetype, where do you go for working code examples? You need to move your app to another webhost, how much hassle will it take? Client needs a CMS, which one do you pick, and how often does it get security updates? You make your app open source and people want to install it, what instructions do you give them?
Yes dammit, let's get practical. Let's get our hands dirty. I love this stuff.
That's a web server configuration, not a programming issue.
Connect to MySQL and store some data.
With CLSQL. http://clsql.b9.com/documentation.htmlNow determine the dimensions of a jpeg image.
CL-GD has image-width and image-height functions. http://weitz.de/cl-gd/
And parse some JSON from a file.
In my world, json is rarely read from disk files. It's passed around between client and server. At any rate.
http://common-lisp.net/project/cl-json/You are showing a complete misunderstanding of software engineering. You don't go running around looking for examples and installing 3rd party packages willy nilly. Weird problems don't just "arise" out of the blue, and although there is some urgency to things there is never any chaos. Things are a bit more controlled, and you are assumed to know what you're doing, Lisp or otherwise.
They're all like 'how do you use lisp all the time' and I'm like 'well lisp is very powerful', and they say 'yeah it is, but how can you stand to use lisp all the time!' and I really don't know how to respond because using lisp seems more natural than something like C or Java where I have to be very explicit about everything that I want and put in very specific syntax.
SCNR
I was not joking about the recursive and functional nature of Lisp, both of which I'm finding very interesting (and my coworker is, in fact, a big fan of Haskell)
Rainbow parens are really helpful and so is automatic paren matching....
It is also specifically noted that Lisp programmers who use Lisp part time have right to write why they do not use Lisp - when they do not use it.
There is a huge variety of reasons and ways people think.
(I think the actual answer here is: mindshare. Respondents heard Lisp and assumed CL, maybe Scheme.)
Even an automaton like the Google algorithm can search data and correlate them. When I type "Common" it auto-completes "Lisp". You should be able to search, find, and compare technologies on their own merit.
The entire programming fora are burning with altruistic recommendations for free Lisp books, some of them classics of the field.
Instead of an anonymous and questionable poll setup by someone with an axe to grind[1] I give you The Road to Lisp. Real names, real people:
http://wiki.alu.org/The%20Road%20To%20Lisp%20Survey
--
[1] The author of that blog is a NewLisp user who made it a habit to troll comp.lang.lisp and other Lisp fora, demanding people treat NewLisp as an equal/real Lisp.
I can't vote on / use something that I don't know.