Future of lisp?
István Lakatos
http://blog.8thlight.com/steven-degutis/2011/08/15/future-of-lisp.html
Is Clojure really the most popular Lisp today? Common Lisp is C++ with more parantheses? Nu useless?... I have so many problems with this article I don't know where to start.
What do you guys think of what he wrote?
Raffael Cavallaro
> I report, you decide :P
> http://blog.8thlight.com/steven-degutis/2011/08/15/future-of-lisp.html
from the article:
"The fact is, no other platform out there right now can provide the
standard libraries, third-party support, extensibility, well-rounded
featureset, community support, and portability like the jvm can.
Clojure is currently the best incarnation of Lisp we have, and will
remain for the foreseeable future."
The JVM doesn't ship with the current version of either Mac OS X or
iOS, so two of the most influential platforms out there cannot run
clojure code out of the box (and one of them, iOS, can't run clojure
code at all).
So much for widespread portability. I think people who work in the
server world have a wildly distorted view of the importance of the jvm.
No one who had a clear eyed view of the client space would have
targetted a langauge at the jvm (microsoft and apple are both working
hard to ensure that the jvm will die). This was clojure's biggest
strategic mistake.
They're trying to make up for it now by bypassing the native client
altogether and targetting javascript (the usual html5 universal client
idea). But I think Apple's iOS SDK is the definitive existence proof
that the native client wins - web-apps are always a second rate client
user experience, and users do actually care about this.
OTOH, gambit scheme can run on *nix, Mac OS X, iOS, android, etc.
Clozure Common lisp can run on Windows, linux, Mac OS X, and there's an
ARM port in progress for iOS and android. Racket is very portable
across clients as well.
warmest regards,
Ralph
--
Raffael Cavallaro
Pascal J. Bourguignon
writes:
> The JVM doesn't ship with the current version of either Mac OS X or
> iOS, so two of the most influential platforms out there cannot run
> clojure code out of the box (and one of them, iOS, can't run clojure
> code at all).
> [...]
> OTOH, gambit scheme can run on *nix, Mac OS X, iOS, android,
> etc. Clozure Common lisp can run on Windows, linux, Mac OS X, and
> there's an ARM port in progress for iOS and android. Racket is very
> portable across clients as well.
What's more, there are at least(*) two Common Lisp implementations running
on the JVM, therefore Common Lisp can do all that Clojure can do there.
(*) IIRC, there are C compilers targetting the JVM, therefore it should
be possible to compile a CL implementation written in C (eg. ecl or
clisp) to target the JVM.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
D Herring
I agree with some of his sentiment, have been contemplating a similar
set of questions, but am converging on a different set of conclusions.
Look at the TIOBE index.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
I wouldn't put complete confidence in their numbers, but I do think
they are fairly accurate. Java took a big lead ten years ago, but it
is showing a long-term decline. C is almost on par, add in C++...
Clojure does a lot of things right. Look up the old CL bindings to
Java (e.g. jfli) and you'll see Rich took a few iterations before
writing his own lisp.
Lisp is a great language (family). However, it has become a minor
player. Programming languages traditionally targeted hardware (and
vice versa). Today, they need to target existing code. Easy interop
with C, C++, and Java would result in a language that could leverage
half the code on the planet (and C is a common extension language for
many others).
CL has bindings like CFFI for importing C; but there is minimal
support for C++, and minimal support for embedding lisp in other
languages. Tools like Clang could help change that.
Look at the mess added in the latest C++ spec. Look at the
fundamental flaws in java (jvm is much better). Look at trends where
other languages are adding lispy features but getting bogged down in
syntax soup.
I think the time is right for lisp. However, I believe we need a new
pragmatic dialect. Neither Scheme nor CL were designed to be the
ultimate glue language. They were designed for their own ecosystem,
and have become isolated. (Macros mean a future lisp should be able
to implement fairly good CL/Scheme compat.)
Fortunately, CL and Scheme are great environments for prototyping new
languages. Implement a VM, try some calling conventions, etc.
- Daniel
ccc31807
> What do you guys think of what he wrote?
Steven Degutis seems to mix issues of language and platform.
As to platform, the idea of VM is certainly attractive. We have the
CLR from Microsoft, the JVM from Sun/Oracle, and (hopefully soon)
Parrot from the Perl/Python/Ruby families. The JVM is (I believe)
justifiably popular -- it's open, has many third party libraries,
portable, and has a mature community. OTOH, it's slow and clunky.
Likewise, the idea of compiling source to executable code is also
attractive, however, you have to deal with both OS and machine issues.
I think there's room for both. Some might prefer writing to a VM in a
portable fashion while others might prefer writing machine code
directly for a particular OS/machine. Personally, I look forward to
the day when you could, if you wanted, target the CLR and Parrot as
well as the JVM.
As to language, we all know and use any number of 'languages' from day
to day. In my job, this week I have written HTML, CSS, JavaScript,
LaTeX, SQL, SVG, some DOS batch files, R, some Excel macros, a lot of
Perl, and Lisp. In the past couple of years, I have written in Java,
C, Ruby, Erlang, XSLT and XQuery, a little Prolog, and maybe some
others that I don't recall. I have a friend who uses COBOL on a daily
basis and sometimes resorts to assembly.
If any language family could be said to hit the sweet spot of
generalizing on different platforms but specializing on specific
tasks, it would be Lisp. And the proliferation of different languages,
platforms, and machines bodes well for Lisp.
> The fact is, no other platform out there right now can provide
> the standard libraries, third-party support, extensibility,
> well-rounded featureset, community support, and portability
> like the JVM can. Clojure is currently the best incarnation
> of Lisp we have, and will remain for the foreseeable future.
Yeah, you can say the same thing about the .NET platform, gcc and
friends, Perl (especially), and others. I don't think the important
part is pushing a particular implementation like Clojure, but pushing
the idea that a language like Lisp can generate Clojure, as well as
Scheme and all the other Lisps.
CC.
Michael Moeller
Turning a predilection of a language into a credo is rather
silly. Choosing an appropriate language depends solely on
the task I have to accomplish. Doing everything in
Lisp, or what language ever, is pretty amateurish.
In addition, in my point of view there are far more
interresting things about Lisp than counting parenthesis,
comparing CLOS to C++, or the thousandth boring variation
of this paradigm.
Anybody who likes to contribute something new to the world of
programming languages is most welcome. I'm afraid I haven't
seen such a thing since more than 20 years.
Regards,
Michael
Anticomuna
> I report, you decide :Phttp://blog.8thlight.com/steven-degutis/2011/08/15/future-of-lisp.html
>
> Is Clojure really the most popular Lisp today? Common Lisp is C++ with more parantheses? Nu useless?... I have so many problems with this article I don't know where to start.
>
> What do you guys think of what he wrote?
All it matters is a KILLER APP. A killer app is something that will
make people want to use the language.
For example, Java had applets and then servlets in the beginning, now
its use is driven mostly by server side stuff or mobile. Ruby had its
hit app with Ruby on Rails. Javascript has AJAX technology to drive up
its use. C++ is well entrenched in a variety of niches.
All Lisp needs is a killer app. That's all.
Nobody cares about the syntax. Ruby looks like vomit, but people still
use it. Objective C is a piece of crap language, but people use it
because of the iPhone.
About Common Lisp specifically, as a developer who came from a Java
and Perl background I found Common Lisp much easier to understand than
Scheme. Scheme is the one Lisp who looks like there are far too many
parentheses. Common Lisp looks clean in comparison and the macro
dispatching stuff really helps to make things stand out, this being
more readable.
István Lakatos
> All it matters is a KILLER APP.
Well, a killer app for Lisp would probably be GNU Emacs, I think. I don't know if we can actually call it "killer" though, since it's not *really* that widely used. A lot of people I know are too afraid to use it.
The problem with Lisp is, from what I understand, is that a killer-app popping up is very unlikely, Lisp being used mainly as a "secret weapon", or on servers, or only as an extension language, but rarely on the desktop or as an accessible framework.
Michael Moeller
No doubt, Lisp has its points. On the other hand, if I don't
make heavy use of its macro facility while introducing several
layers of abstraction, so why Lisp?
I never came across a real world application which really
required this kind of complexity and using Lisp 'plain vanilla'
has no advantage over almost any other language.
Lisp, Prolog or ML are used in research. In my opinion that's
where they belong. Otherwise it means taking a sledgehammer to
crack a nut.
Regards,
Michael
Pascal J. Bourguignon
As Naggum used to say...
If you don't need lisp, then you're addressing the wrong problem!
Let's read again:
"Where Lisp Fails: at Turning People into Fungible Cogs."
http://www.loper-os.org/?p=69
"Re: How is perl braindamaged? (was Re: Is LISP dying?)"
http://www.xach.com/naggum/articles/31421457...@naggum.no.html
Tim Bradshaw
> So much for widespread portability. I think people who work in the
> server world have a wildly distorted view of the importance of the jvm.
> No one who had a clear eyed view of the client space would have
> targetted a langauge at the jvm (microsoft and apple are both working
> hard to ensure that the jvm will die). This was clojure's biggest
> strategic mistake.
The interesting thing here, of course, isn't anything to do with the
future of Lisp - discussion of that has never been useful in my
experience - but the fact that we are now living in a world of two
cultures, with Java as an important distinguishing characteristic.
One culture we might call the "desktop culture", although of course
it's now about phones and tablets more than laptops, let alone desktops
(I don't want to call it the "client culture" as that sounds too much
like "client state" to me). The other culture we can call the "server
culture".
Java is not only dead in the desktop culture: it was never really
alive. In the browser, applets were never any good, and it's now a
very long time since JavaScript and Flash destroyed any niche they
might have had. Java GUI apps are also generally terrible in terms of
look & feel and usually in terms of performance as well. Certainly the
only Java application I use is Eclipse, and the only reason I use that
is because I occasionally write Java. I have tried and recoiled in
horror from various other Java apps and I now actively avoid them, and
I'm sure I'm not alone in that. Java is simply not a contender in the
desktop culture.
The situation in the server culture is different. It's would be easy
to say that Java is simply the new COBOL, used to implement the
terrible enterprise crapware of which there is such an unfortunate
surfeit. While it is certainly dominant in that market, that's not the
only place it is used. Hadoop, for instance, is very far from being
enterprise crapware and there are numerous other examples. It's
probably the case that, to a good first approximation, Java is simply
the language (and runtime) of choice in the server culture, regardless
of the crapness or otherwise of the application.
So what's happening here is that someone from the desktop culture is
looking at a server culture tool and failing to understand it. From
the other culture, people are probably looking the other way and
failing to understand in much the same way. The cultures are now so
far apart that they are no longer able to understand each other.
Espen Vestre
> Java is not only dead in the desktop culture: it was never really
> alive.
I thought Android finally brought it to life?
--
(espen)
Tim Bradshaw
> I thought Android finally brought it to life?
Good point. I should think of some clever reply pointing out why I'm
still right ("it's not really Java") but actually, no. I still think
there is a real point around the two cultures thing.
Espen Vestre
>> I thought Android finally brought it to life?
>
> Good point. I should think of some clever reply pointing out why I'm
> still right ("it's not really Java") but actually, no. I still think
> there is a real point around the two cultures thing.
I'd like to think you're right, but I'm not really qualified to know, as
I haven't (yet) looked into Android programming.
--
(espen)
Duane Rettig
> On Aug 16, 4:41 pm, István Lakatos <lakatos.i...@gmail.com> wrote:
>
> > I report, you decide :Phttp://blog.8thlight.com/steven-degutis/2011/08/15/future-of-lisp.html
>
> > Is Clojure really the most popular Lisp today? Common Lisp is C++ with more parantheses? Nu useless?... I have so many problems with this article I don't know where to start.
>
> > What do you guys think of what he wrote?
>
> All it matters is a KILLER APP. A killer app is something that will
> make people want to use the language.
>
> For example, Java had applets and then servlets in the beginning, now
> its use is driven mostly by server side stuff or mobile. Ruby had its
> hit app with Ruby on Rails. Javascript has AJAX technology to drive up
> its use. C++ is well entrenched in a variety of niches.
>
> All Lisp needs is a killer app. That's all.
I would agree, except that I would take it even farther, and so I
disagree in magnitude.
I speak only of Common Lisp here (other Lisps can fend for themselves,
including Clojure, which also needs a Killer App - also, someone
suggested Emacs, and that is the Killer App which allows Emacs Lisp to
be so widely used in so many places that it wouldn't otherwise be
used). As for Common Lisp, it is unique among non-C languages in that
it has many instances, made by multiple commercial vendors as well as
multiple open-source groups. Each of these "vendors" need a Killer
App.
At Franz, we searched for a Killer App for many years until we found
what we believe is ours: Allegro Graph. It has blossomed into a whole
semantic web technology, even causing us to divide our website into
two halves (see http://www.franz.com/agraph). It has caused many
people who would not have given Lisp a first thought to become avid CL
users. And since it is server/client based, with their companies'
favorite languages as clients, they do not have to hide the lisp
interface from their management; they can just use one of the client
languages that is "acceptable" to their companies. Also, Agraph has
received numerous distinctions for speed and scalability amongst its
competitors in the semantic database market, including a recent
milestone of being able to process a trillion rdf triples (http://
ftp.franz.com/about/press_room/trillion-triples.lhtml). Does this
affect Franz Inc in a good way? Absolutely. Does it affect Common
Lisp in a good way? Yes. Is it Common Lisp's Killer App? No - it is
Allegro CL specific.
So I would strengthen this statement:
"All Lisp needs is a killer app."
to this:
"All Lisp needs is one killer app each."
Duane
Jeff M.
> On Aug 16, 4:41 pm, István Lakatos <lakato...@gmail.com> wrote:
> > I report, you decide :Phttp://blog.8thlight.com/steven-degutis/2011/08/15/future-of-lisp.html
> >
> > Is Clojure really the most popular Lisp today? Common Lisp is C++ with more parantheses? Nu useless?... I have so many problems with this article I don't know where to start.
> >
> > What do you guys think of what he wrote?
>
> All it matters is a KILLER APP. A killer app is something that will
> make people want to use the language.
>
> For example, Java had applets and then servlets in the beginning, now
> its use is driven mostly by server side stuff or mobile. Ruby had its
> hit app with Ruby on Rails. Javascript has AJAX technology to drive up
> its use. C++ is well entrenched in a variety of niches.
>
> All Lisp needs is a killer app. That's all.
>
Personally, I think this is what's impossible for "Lisp" - even Common Lisp. That's because a *lot* of what programmers today care about, Common Lisp doesn't [portably] provide out-of-the-box. That's because the CL standard doesn't address sockets, the web, security, threading, and a plethora of other "common" technologies in use today.
Implementations of Common Lisp do have their own killer apps. Franz immediately comes to mind with Allegro* libraries, and those implementation all implement their own versions of the above, unstandardized technologies. But that makes people want to use Allegro, which happens to be a Common Lisp implementation - not the other way around.
Python, Ruby, even *shiver* Java, they have the advantage of their only being a single implementation that anyone writing code targets. If I want to write a web server in Python, Erlang, Ruby, etc, I just download one of a dozen different libraries for whatever language I prefer and go; they are guaranteed to at least get me up and running with minimal hassles.
If I want to do the same in Lisp, the implementation of Lisp I choose is largely based on the web framework I want to use. And then I need to spend an entire afternoon downloading other various ASDF packages that the framework uses that may - or may not - work on that particular implementation of CL. If I'm using Scheme, then I need to make sure it has various SFRI's.
That - more than anything else - is Common Lisp's greatest problem. When I Google something like "common lisp os x" and one of the first links to pop up deals with steps like:
1. Install MacPorts
2. Download SBCL
3. configure; make; make install
4. Download Emacs
5. Download Slime
6. Edit .emacs file
7. ...
Those are some pretty major problems to get up and running vs. almost any other language you can download today.
People choose a language to either A) accomplish something or B) learn something (we'll discount group C - just to look cool). Lisp is great for both, but accomplishing something in it - for a newcomer - can be a royal PITA.
Jeff M.
Alessio Stalla
Nothing forces you to use "Common Lisp, the standard". The existence
of the Common Lisp standard is a plus, but just like when you write an
application in, say, Python, you choose a single implementation, you
can do the same with Lisp - just write your app in SBCL or CCL or
Allegro or <insert your favourite Lisp here> rather than writing it in
Common Lisp (the standard). In other words, you can (and often
should!) treat each CL implementation as if it were a language on its
own! With the added bonus that all these languages share a vast common
ground that makes porting - should the need for it ever arise - much
easier than, e.g., between Python and Ruby or between Java and C#.
After all, when people say "Clojure" they really mean Clojure/JVM and
not Clojure/CLR most of the time; same as Python -> CPython and not
JPython or IronPython, Ruby -> not Jruby or IronRuby, C/C++ -> Unix C/C
++ vs MS C/C++, etc.
Alessio
Antsan
Pascal J. Bourguignon
> If I want to do the same in Lisp, the implementation of Lisp I choose
> is largely based on the web framework I want to use. And then I need
> to spend an entire afternoon downloading other various ASDF packages
> that the framework uses that may - or may not - work on that
> particular implementation of CL. If I'm using Scheme, then I need to
> make sure it has various SFRI's.
You are late. In 2011, there's quicklisp.
> That - more than anything else - is Common Lisp's greatest
> problem. When I Google something like "common lisp os x" and one of
> the first links to pop up deals with steps like:
>
> 1. Install MacPorts
> 2. Download SBCL
> 3. configure; make; make install
> 4. Download Emacs
> 5. Download Slime
> 6. Edit .emacs file
> 7. ...
>
> Those are some pretty major problems to get up and running vs. almost
> any other language you can download today.
But if I want to compile some C program, I have to:
> 1. Install MacPorts
> 2. Download gcc
> 3. configure; make; make install
> 4. Download Emacs
> 5. Download cedet (well not anymore, it's bundled with emacs 23).
> 6. Edit .emacs file
> 7. ...
Remember, MacOSX doesn't come with development tools, they're an
optional package. MS-Windows doesn't come with MSVC, it's an optional
package. Even most linux distributions don't have gcc pre-installed!
Tim Bradshaw
> Personally, I think this is what's impossible for "Lisp" - even Common
> Lisp. That's because a *lot* of what programmers today care about,
> Common Lisp doesn't [portably] provide out-of-the-box. That's because
> the CL standard doesn't address sockets, the web, security, threading,
> and a plethora of other "common" technologies in use today.
This is something that crops up a lot, and I think is generally because
people would rather complain than get work done. Pick an
implementation of CL which has the things you need. Now pretend it is
the only implementation: this is the situation you are currently in for
Perl, say, and somehow it is not a problem for Perl.
Marco Antoniotti
> Nobody cares about the syntax. Ruby looks like vomit, but people still
> use it.
Are you diagnosing WJ with gastrointestinal disfunction? :)
Cheers
--
MA
Peter Hill
Perl: Everything that is available is available for the single
implementation. A developer has no choice as to which implementation
they target.
Lisp: The set of things that are available in one implementation are
not available in others and have been written using sufficient(ly)
special features to make porting non trivial (trivial = lift and copy
the source code). No implementation has an adequately full set of
libraries and the number of variations means that the developers of
libraries etc will never cover the full set of implementations.
It's like before and after Babel.
--
Peter Hill
Spamtrap reply domain as per NNTP-Posting-Host in header
Can of worms - what every fisherman wants.
Can of worms - what every PC owner gets!
Zach Beane
> On Fri, 19 Aug 2011 09:31:46 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>
>>On 2011-08-18 17:14:24 +0100, Jeff M. said:
>>
>>> Personally, I think this is what's impossible for "Lisp" - even Common
>>> Lisp. That's because a *lot* of what programmers today care about,
>>> Common Lisp doesn't [portably] provide out-of-the-box. That's because
>>> the CL standard doesn't address sockets, the web, security, threading,
>>> and a plethora of other "common" technologies in use today.
>>
>>This is something that crops up a lot, and I think is generally because
>>people would rather complain than get work done. Pick an
>>implementation of CL which has the things you need. Now pretend it is
>>the only implementation: this is the situation you are currently in for
>>Perl, say, and somehow it is not a problem for Perl.
>
> Perl: Everything that is available is available for the single
> implementation. A developer has no choice as to which implementation
> they target.
I don't have that impression when it comes to Windows and Perl. There
seem to be multiple active implementations and, when reading portable
Perl libraries, special care seems to be taken in some cases to support
platform-specific idiosyncracies.
Zach
Bakul Shah
> All Lisp needs is a killer app. That's all.
I thought Lisp _had_ a killer app. AI. Didn't it kill Lisp for a while? :-)
Raymond Wiker
Possibly because you can write your program in 1/10th of the
amount of code, and 1/10th of the time?
For the last year or so, I've been using Lisp exclusively, and
the numbers above are, if anything, conservative.
Raymond Wiker
> If I want to do the same in Lisp, the implementation of Lisp I choose is largely based on the web framework I want to use. And then I need to spend an entire afternoon downloading other various ASDF packages that the framework uses that may - or may not - work on that particular implementation of CL. If I'm using Scheme, then I need to make sure it has various SFRI's.
This is 2011. No need to mess about with ASDF packages: start
with quicklisp, and add whatever is necessary, as necessary.
Raymond Wiker
Lisp's killer app is... Lisp. It's the killer app that lets you
get the problem solved faster, and in fewer lines, and quite likely also
with better performance.
Tim Bradshaw
> Lisp: The set of things that are available in one implementation are
> not available in others and have been written using sufficient(ly)
> special features to make porting non trivial (trivial = lift and copy
> the source code). No implementation has an adequately full set of
> libraries and the number of variations means that the developers of
> libraries etc will never cover the full set of implementations.
Then use perl.
Raymond Wiker
FWIW:
I use Lispworks at work. Most of the modern Lisp libraries seem to have
been developed on SBCL, mainly because this is a high-quality, free
implementation.
The code I write use at least 50-odd libraries, and only one of these do
I need to patch to get it to work with Lispworks.
My experience is that most Lisp libraries are high quality and
portable; I have a much better impression of libraries for Lisp than for
Python and Java (and .NET).
Teemu Likonen
> No implementation has an adequately full set of libraries and the
> number of variations means that the developers of libraries etc will
> never cover the full set of implementations.
In theory, yes, but let's not get too academic here. Do you have some
specific problems in mind?
If a programmer picks a reasonably good implementation like SBCL, what
problems does she have?
Tim Bradshaw
> I use Lispworks at work. Most of the modern Lisp libraries seem to have
> been developed on SBCL, mainly because this is a high-quality, free
> implementation.
I use Perl at work. There's typically a huge number of
slightly-different modules for anything I might want to do, each of
them available in many versions. Since I need my programs to work on
many machines, and this actually matters (you *really* want programs
which run as root across hundreds of systems in a financial
organisation to work), I quite frequently end up writing my own modules
which (a) work, and (b) are trivial to bundle with the program. So
much for Perl's legendary library availability.
Pascal Costanza
> I report, you decide :P
> http://blog.8thlight.com/steven-degutis/2011/08/15/future-of-lisp.html
>
> Is Clojure really the most popular Lisp today? Common Lisp is C++ with more parantheses? Nu useless?... I have so many problems with this article I don't know where to start.
>
> What do you guys think of what he wrote?
It seems to me he doesn't know what he's talking about.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
The views expressed are my own, and not those of my employer.
István Lakatos
There seems to be this false notion among programmers that new and fresh is always the best, and if an implementation or library hasn't been updated for more than a year (let's say), then it's useless and broken.
So when someone who just learned the freshest of lisps, with one implementation, one community, looks back and sees a bunch of implementations, each one with their own separate community, and the seas of aging libraries, it seems kinda normal that he thinks we are madmen clinging onto a dieing language :P
Of course, ignorance is no excuse for writing dumb blog posts.
Bigos
> Personally, I think this is what's impossible for "Lisp" - even Common Lisp. That's because a *lot*
> of what programmers today care about, Common Lisp doesn't [portably] provide out-of-the-box. That's
> because the CL standard doesn't address sockets, the web, security, threading, and a plethora of
> other "common" technologies in use today.
Ruby also doesn't provide many things out of the box, but it has the
gem system for loading and installing all sorts of libraries.
Quicklisp is to some extent similar to that but much more difficult to
use.
> Python, Ruby, even *shiver* Java, they have the advantage of their only being a single
> implementation that anyone writing code targets. If I want to write a web server in Python,
> Erlang, Ruby, etc, I just download one of a dozen different libraries for whatever language
> I prefer and go; they are guaranteed to at least get me up and running with minimal hassles.
Don't know about Python, but I have heard about 2 implementations of
Java and about half a dozen implementations of Ruby. The difference
is, I think, those languages have ONE reference implementation, that
others strive to be compatible with.
To improve chances of attracting more programmers to use Lisp and
create all the killer applications you want, I think you need to
improve quality of lisp documentation.
Common Lisp Cookbook is a good idea, but is seems it has been
abandoned. I think Hyperspec badly needs to undergo some kind of
upgrade to make it easier to use and understand. I think it is good
idea to keep current content as it is, but adding some kind of
moderated user notes, as in PHP manual http://www.php.net/manual/en/language.types.boolean.php
, would help tremendously.
While I'm at it, I would like to ask one question? Why Lisp, despite
being so easy in terms of syntax and other language related stuff, is
so difficult when it comes to its ecosystem, is some sort of elite
Lispers conspiracy to eliminate lazy and not so clever programmers?
Jack
Pascal J. Bourguignon
> While I'm at it, I would like to ask one question? Why Lisp, despite
> being so easy in terms of syntax and other language related stuff, is
> so difficult when it comes to its ecosystem, is some sort of elite
> Lispers conspiracy to eliminate lazy and not so clever programmers?
Yes. Read again:
"Where Lisp Fails: at Turning People into Fungible Cogs."
http://www.loper-os.org/?p=69
--
Raymond Wiker
> On Aug 18, 5:14 pm, "Jeff M." <mass...@gmail.com> wrote:
>
>> Personally, I think this is what's impossible for "Lisp" - even Common Lisp. That's because a *lot*
>> of what programmers today care about, Common Lisp doesn't [portably] provide out-of-the-box. That's
>> because the CL standard doesn't address sockets, the web, security, threading, and a plethora of
>> other "common" technologies in use today.
>
> Ruby also doesn't provide many things out of the box, but it has the
> gem system for loading and installing all sorts of libraries.
> Quicklisp is to some extent similar to that but much more difficult to
> use.
How can possibly
(ql:quickload :whatever-system-i-want-to-load)
be described as "difficult to use"?
>> Python, Ruby, even *shiver* Java, they have the advantage of their only being a single
>> implementation that anyone writing code targets. If I want to write a web server in Python,
>> Erlang, Ruby, etc, I just download one of a dozen different libraries for whatever language
>> I prefer and go; they are guaranteed to at least get me up and running with minimal hassles.
>
> Don't know about Python, but I have heard about 2 implementations of
> Java and about half a dozen implementations of Ruby. The difference
> is, I think, those languages have ONE reference implementation, that
> others strive to be compatible with.
>
> To improve chances of attracting more programmers to use Lisp and
> create all the killer applications you want, I think you need to
> improve quality of lisp documentation.
> Common Lisp Cookbook is a good idea, but is seems it has been
> abandoned. I think Hyperspec badly needs to undergo some kind of
> upgrade to make it easier to use and understand. I think it is good
> idea to keep current content as it is, but adding some kind of
> moderated user notes, as in PHP manual http://www.php.net/manual/en/language.types.boolean.php
> , would help tremendously.
>
> While I'm at it, I would like to ask one question? Why Lisp, despite
> being so easy in terms of syntax and other language related stuff, is
> so difficult when it comes to its ecosystem, is some sort of elite
> Lispers conspiracy to eliminate lazy and not so clever programmers?
Your assumption is wrong (or at least not universally accepted),
so your question does not make sense.
Pascal J. Bourguignon
>> While I'm at it, I would like to ask one question? Why Lisp, despite
>> being so easy in terms of syntax and other language related stuff, is
>> so difficult when it comes to its ecosystem, is some sort of elite
>> Lispers conspiracy to eliminate lazy and not so clever programmers?
>
> Your assumption is wrong (or at least not universally accepted),
> so your question does not make sense.
Yes, it does! A cog can't fathom reading the doc of quicklisp, or
asking here or on irc.
Pascal Costanza
An additional factor that comes into play seems to be the belief that,
because Rich Hickey is "smart" and has already seen the other Lisp
dialects, it's not necessary anymore to investigate them yourself.
> Of course, ignorance is no excuse for writing dumb blog posts.
Michael Moeller
This might well be true with your project. Dont't get me wrong.
I agree Lisp is a great language. And I know of similar numbers.
Unless we are talking about cell phone games and other toy
applications I'm afraid things are more complex. Why not to use
Lisp is based on a mixture of preconceptions and lack of knowledge.
On the other hand there are pretty good reasons not to use it.
Interestingly enough this has nothing to do with the language
as such.
Consider domains like international bank transactions, production
plant engineering, or spaceflight. In my opinion this would be the
real killer apps. However, nothing will be applied there unless
it's understood down to the last bit regarding any possible situation.
It's far easier to write your own stuff from scratch.
Regards,
Michael
Tim Bradshaw
> Consider domains like international bank transactions, production
> plant engineering, or spaceflight. In my opinion this would be the
> real killer apps. However, nothing will be applied there unless
> it's understood down to the last bit regarding any possible situation.
I can't speak for the other two, but the stuff of which large critical
banking systems are made certainly does not meet this requirement, and
in fact should inspire serious fear.
Michael Moeller
Thats interesting. However, just for the sake of clarity: what
I had in mind was not vulnerability but precision in a time
critical environment. I can judge this only by what is made
public and talking to people involved in this. Perhaps you know
better. However, I'm afraid Lisp is a natural candidate in neither
case.
Regards,
Michael
Anticomuna
> I don't understand this article at all. It seems to be just useless gibberish, miles apart from what I would consider useful about Lisp or programming in general.
The article is just an unfounded opinion based on the author's lack of
knowledge. Even among Java developers, nobody cares about Clojure or
any other Lisp.
Most Java developers don't know any other language and try to avoid
Javascript like the plague, even if they need it for webapps.
The only people who talk about alternative languages on the JVM are
either programming language snobs who believe to be "above" everyone
else or people like me who work on some small project, but hardly
anything that would signify something else's death.
Duane Rettig
If you're looking for Real Time guarantees in an application, then
you're looking in the wrong place if you are wanting to use any
unrestricted General Purpose language. Any use of malloc/free,
sockets, etc, will fail your real-time guarantees. Even a simple
language like C will fail you in this area. If you want to get real-
time guarantees, you must either turn to a real-time specialized
language, or else severely restrict your GP language with a lot of
real-time rules. For this, Lisp is just as natural a candidate as
any. In fact, Common Lisp does not even specify a Garbage Collector
(though it refers to one in a few places) and some implementations
allow for the turning off of the gc.
Duane
00101010
> The article is just an unfounded opinion based on the author's lack of
> knowledge.
Classic unsubstantiated and erroneous claim.
> Even among Java developers, nobody cares about Clojure or
> any other Lisp.
Classic unsubstantiated and erroneous claim.
> Most Java developers don't know any other language and try to avoid
> Javascript like the plague, even if they need it for webapps.
What does your classic unsubstantiated and erroneous claim have to do
with Lisp, Anticomuna?
> The only people who talk about alternative languages on the JVM are
> either programming language snobs who believe to be "above" everyone
> else or people like me who work on some small project, but hardly
> anything that would signify something else's death.
What does your classic unsubstantiated and erroneous claim have to do
with Lisp, Anticomuna?
00101010
> I reach the same conclusion when I am speaking to someone who
> not so long ago learned Clojure, and hasn't really come into
> contact with the rest of the Lisp world.
> There seems to be this false notion among programmers that new
> and fresh is always the best, and if an implementation or library
> hasn't been updated for more than a year (let's say), then it's
> useless and broken.
If that lack of up-to-dateness means it has green threads and so can't
use more than 1/4 of a modern machine's processor, lacks any library
that works with it OOTB that can be used for web/networking stuff, and
can't generate a GUI from reasonably portable source code, then yeah,
it's useless and broken -- at least as much so as a 1993 edition of
Visual C with a few old proprietary libraries is useless and broken, and
perhaps as much as COBOL is useless and broken. :)
If you only need to write the same kinds of programs (say, terminal-mode
command line utilities and banking systems) that you were writing back
in the seventies, then an old and crufty Common Lisp implementation may
be right up your alley, and failing that you will probably love C++.
If you need to do what 90+% of developers are doing now then you need
stuff that older programming language kits generally won't provide OOTB
and that will often not be easily had in the form of widely-ported,
free, high quality libraries that can be installed and used with a
minimum of fuss. (Having to rewrite half of it to make it work with your
implementation does not count as "a minimum of fuss".)
And then you may NEED to run on the JVM or something (for example to run
on an Android phone or tablet or in a servlet container). Then your
choices for a Lisp are basically reduced to ABCL and Clojure, and in
either case your code is going to be tied to the JVM platform and
libraries, so the advantage of ABCL being Common Lisp and your code
therefore theoretically being portable to another CL implementation
basically disappears, while the advantage of access to existing CL
libraries is mostly equalized away by the large and mature (and actively
maintained, heavily used, and so heavily nitpicked for bugs) Java
library ecosystem being available as well. (And CL libraries designed
for use where it's easy to make native, direct OS calls will probably
not play nice with the JVM regardless. At best there will be a
significant performance hit from going through the Java/native thunk for
each such call, and likely there will be issues with native resources
vs. the JVM garbage collector and other such complications; native and
JVM GUI components fighting, fire and brimstone, dogs and cats living
together, etc.; and at worst the darn thing just plain won't work,
crashing the JVM or locking up or futzing up the display to the point of
unusability or something.)
Clojure also has some interesting new ideas (and features) regarding
concurrency and the management of mutable state. It's not intended as a
drop-in replacement for Common Lisp and viewing it as a claimed "CL
replacement/upgrade" would be a mistake. If it's a drop-in replacement
for anything, it's Java, not CL.
Bigos
> Bigos<ruby....@googlemail.com> writes:
>
>> On Aug 18, 5:14 pm, "Jeff M."<mass...@gmail.com> wrote:
>>
>>> Personally, I think this is what's impossible for "Lisp" - even Common Lisp. That's because a *lot*
>>> of what programmers today care about, Common Lisp doesn't [portably] provide out-of-the-box. That's
>>> because the CL standard doesn't address sockets, the web, security, threading, and a plethora of
>>> other "common" technologies in use today.
>>
>> Ruby also doesn't provide many things out of the box, but it has the
>> gem system for loading and installing all sorts of libraries.
>> Quicklisp is to some extent similar to that but much more difficult to
>> use.
>
> How can possibly
>
> (ql:quickload :whatever-system-i-want-to-load)
>
> be described as "difficult to use"?
Ease of use is not only typing one character less than 'gem install
whatever'. To large extent it also depends on availability and quality
of documentation geared toward dumb newbies.
>> While I'm at it, I would like to ask one question? Why Lisp, despite
>> being so easy in terms of syntax and other language related stuff, is
>> so difficult when it comes to its ecosystem, is some sort of elite
>> Lispers conspiracy to eliminate lazy and not so clever programmers?
>
> Your assumption is wrong (or at least not universally accepted),
> so your question does not make sense.
I my question makes sense to to those who can see sarcasm in it.
Jack
Anticomuna
his. His article is just opinion and, judging by his over-
generalizations, it is also non-sense.
Alternative languages on the JVM are just a fad ignored by most. Ruby
is the most popular because of Ruby on Rails, but the rest are just
flat-lines. The job market ignores them.
I haven't seen any project in any of those languages in my whole
career. I may have seen Ruby or Python cited on a small fraction of
job descriptions, but that's all.
Tim Bradshaw
> Thats interesting. However, just for the sake of clarity: what
> I had in mind was not vulnerability but precision in a time
> critical environment. I can judge this only by what is made
> public and talking to people involved in this. Perhaps you know
> better. However, I'm afraid Lisp is a natural candidate in neither
> case.
I'm slightly confused what sort of thing you're referring to here, in
finance anyway. The HFT people will care a lot about real-time
performance guarantees, but for virtually everything else transactional
integrity of various kinds is the critical thing. And my point was
really that, for financial systems, it is a mistake to think that there
is some cabal who write these golden perfect systems which hold the
world together: instead it's held together by a really terrifying mess
of half-working crapware. I am continually amazed and depressed that
people get away with it, in fact. Of course I can't rule out the
golden cabal, but I have never spoken to anyone who claims to have even
heard of such a thing.
I do live in hope that in, say, space systems, there are people who
write stuff that really does work and is well put together, though I
fear that it's all the same mess. They obviously do have real-time
requirements, but it's a mistake to say that "real-time means no Lisp":
if I wanted to do do real-time stuff in Lisp I'd plan to spend a lot of
time talking to technical people behind the implemention to understand
what I needed to do, which is pretty much the same as if I wanted to do
real-time stuff in any language.
Anticomuna
<zerozeroonezeroonezeroonez...@h2g2.cazoola> wrote:
> If that lack of up-to-dateness means...
If you had any actual data or point to make, this debate might get
interesting.
I find funny that some people believe that Clojure, something
virtually unknown outside some very limited Java developer circles, is
even there to "compete".
I don't mean only against Common Lisp, but any other Lisp or
programming language out there in the market these days.
Even F# is more popular than Clojure. Seriously, dude. Less hubris
would be a good piece of advice.
Pascal Costanza
Whatever...
Thomas Hühn
> I do live in hope that in, say, space systems, there are people who
> write stuff that really does work and is well put together, though I
> fear that it's all the same mess. They obviously do have real-time
http://www.fastcompany.com/magazine/06/writestuff.html
Thomas
00101010
> First of all, he is the one claiming something. The burden of proof is
> his.
Classic pontification.
> His article is just opinion and, judging by his over-
> generalizations, it is also non-sense.
Classic unsubstantiated and erroneous claim.
> Alternative languages on the JVM are just a fad ignored by most.
Classic unsubstantiated and erroneous claim. Both Scala and Clojure are
gaining significant traction, and on the CLR side so is F# as an
alternative to C#. Interestingly, all three alternative hosted languages
have a strong functional-programming philosophy behind them.
> Ruby is the most popular because of Ruby on Rails, but the rest are
> just flat-lines.
Classic unsubstantiated and erroneous claim.
> The job market ignores them.
The job market ignored Java when it was only a couple of years old.
> I haven't seen any project in any of those languages in my whole
> career.
A lot of career developers hadn't seen any project in Java when Java was
still brand new.
> I may have seen Ruby or Python cited on a small fraction of
> job descriptions, but that's all.
Classic pontification.
00101010
> On 20 ago, 15:07, 00101010
> <zerozeroonezeroonezeroonez...@h2g2.cazoola> wrote:
>> If that lack of up-to-dateness means...
>
> If you had any actual data or point to make, this debate might get
> interesting.
Classic erroneous presupposition that I didn't make a point.
> I find funny that some people believe that Clojure, something
> virtually unknown outside some very limited Java developer circles, is
> even there to "compete".
Someone might, back in the mid-90s, have "found it funny" that some
people believed that Java was even there to compete.
> I don't mean only against Common Lisp, but any other Lisp or
> programming language out there in the market these days.
Classic ambiguity.
> Even F# is more popular than Clojure.
F# is also at least three times older than Clojure.
> Seriously, dude. Less hubris
> would be a good piece of advice.
Classic erroneous presupposition.
00101010
> I do live in hope that in, say, space systems, there are people who
> write stuff that really does work and is well put together, though I
> fear that it's all the same mess.
It's all the same mess.
ok
> What do you ... think ... ?
Come on lurkers/trolls/vacationers, put in some comment on this one!
Guinness is awaiting a new c.l.l. comment-count-record, let's bring it
up to at least 3000 hot shot write ups, go go go!!
(I will kindly offer a year of free beer to the one posting the
comment number 3000, wow, I'm really generous.)
kensi
ok, it should only take me a few minutes to whip up a bot-poster with
ABCL and Java's extensive HTTP libraries. So, how soon after that 3000th
post goes up does the beer tap open?
Raymond Wiker
> On 20/08/11 09:56, Raymond Wiker wrote:
>> Bigos<ruby....@googlemail.com> writes:
>>
>>> On Aug 18, 5:14 pm, "Jeff M."<mass...@gmail.com> wrote:
>>>
>>>> Personally, I think this is what's impossible for "Lisp" - even Common Lisp. That's because a *lot*
>>>> of what programmers today care about, Common Lisp doesn't [portably] provide out-of-the-box. That's
>>>> because the CL standard doesn't address sockets, the web, security, threading, and a plethora of
>>>> other "common" technologies in use today.
>>>
>>> Ruby also doesn't provide many things out of the box, but it has the
>>> gem system for loading and installing all sorts of libraries.
>>> Quicklisp is to some extent similar to that but much more difficult to
>>> use.
>>
>> How can possibly
>>
>> (ql:quickload :whatever-system-i-want-to-load)
>>
>> be described as "difficult to use"?
>
> Ease of use is not only typing one character less than 'gem install
> whatever'. To large extent it also depends on availability and quality
> of documentation geared toward dumb newbies.
"Ease of use" does not imply "can be used by dumb newbies". That said,
Quicklisp *is* easy to use, and from a cursory glance at gem, it appears
that gem is roughly equivalent.
One apparent downside with gem is that anybody can publish a "gem",
while quicklisp has an "editor".
>>> While I'm at it, I would like to ask one question? Why Lisp, despite
>>> being so easy in terms of syntax and other language related stuff, is
>>> so difficult when it comes to its ecosystem, is some sort of elite
>>> Lispers conspiracy to eliminate lazy and not so clever programmers?
>>
>> Your assumption is wrong (or at least not universally accepted),
>> so your question does not make sense.
>
> I my question makes sense to to those who can see sarcasm in it.
Nope, it doesn't. Even if I look at that question through my
sarcasm-tinted glasses, I cannot see any sense in it.
Anticomuna
<zerozeroonezeroonezeroonez...@h2g2.cazoola> wrote:
> Classic unsubstantiated and erroneous claim. Both Scala and Clojure are
> gaining significant traction, and on the CLR side so is F# as an
> alternative to C#. Interestingly, all three alternative hosted languages
> have a strong functional-programming philosophy behind them.
Not according to reality:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Michael Moeller
On Sat, 20 Aug 2011, Tim Bradshaw wrote:
I agree but I'm afraid we are at cross-purposes. These are just some
examples of the important stuff, at least in my opinion. I don't insist
in real-time. Of course you can do many projects in Lisp and a typed
Lisp is almost as fast as C.
I'm referring to software which makes the world go round. Maybe my
knowledge is biased in some way. I'm sitting at terminals since the
late seventies (yes, UNIVAC). This doesn't mean anything but what
I know for sure is no one I know of will touch Lisp when it comes
to this kind of projects.
Most of the space shuttles software was written from scratch for
example. The same applies to many other projects. It seems to be
far easier than to verify any of the existing stuff. I can't judge this.
The companies doing cell phone accounting (from which I know of)
use some existing database stuff and lots of proprietary C programming.
The people writing software for process engineering won't even tell
you. Proprietary OS with a Java interface, for example.
It's not about who is right or wrong. I don't say there isn't
good real world software written in Lisp. I only say neither me nor
anybody I know of ever came across such software. I suspect there
are good reasons for that.
Regards,
Michael
Tim Bradshaw
> I don't insist
> in real-time. Of course you can do many projects in Lisp and a typed
> Lisp is almost as fast as C.
OK, I think you probably don't know what "real-time" means.
Zach Beane
> I'm referring to software which makes the world go round.
Lowell Hawkinson had some nice success stories at ILC 2010 regarding
Gensym's G2 product, which is powered by Common Lisp. It was used to
help manage factories, the Biosphere 2 project, satellite launches,
etc. Very neat stuff.
Zach
Bigos
> Bigos<ruby....@some.server.con> writes:
>
>> On 20/08/11 09:56, Raymond Wiker wrote:
>>> Bigos<ruby....@googlemail.com> writes:
>>>
>>>> On Aug 18, 5:14 pm, "Jeff M."<mass...@gmail.com> wrote:
>>>>
>>>>> Personally, I think this is what's impossible for "Lisp" - even Common Lisp. That's because a *lot*
>>>>> of what programmers today care about, Common Lisp doesn't [portably] provide out-of-the-box. That's
>>>>> because the CL standard doesn't address sockets, the web, security, threading, and a plethora of
>>>>> other "common" technologies in use today.
>>>>
>>>> Ruby also doesn't provide many things out of the box, but it has the
>>>> gem system for loading and installing all sorts of libraries.
>>>> Quicklisp is to some extent similar to that but much more difficult to
>>>> use.
>>>
>>> How can possibly
>>>
>>> (ql:quickload :whatever-system-i-want-to-load)
>>>
>>> be described as "difficult to use"?
>>
>> Ease of use is not only typing one character less than 'gem install
>> whatever'. To large extent it also depends on availability and quality
>> of documentation geared toward dumb newbies.
>
> "Ease of use" does not imply "can be used by dumb newbies". That said,
> Quicklisp *is* easy to use, and from a cursory glance at gem, it appears
> that gem is roughly equivalent.
>
> One apparent downside with gem is that anybody can publish a "gem",
> while quicklisp has an "editor".
>
Paraphrasing old saying about beauty, ease of use is in the eye of user.
Perhaps because I come from different background I find it difficult to
agree with your point. To give you example information explaining my
moaning about lisp ecosystem and why I feel that way have a look at this
link.
http://en.wikipedia.org/wiki/Usability#Lund.2C_1997_usability_maxims
Although lisp environment meets many criteria mentioned in the above
link, there are still some things mentioned there that are on my
wish-list for a better lisp environment and documentation. After some
paraphrasing the wikipedia aricle I would say:
*Know the newbie, and YOU are not the newbie.
*The documentation for the decision must be there when the decision is
needed.
*Don't overwhelm the user.
*Consistency, consistency, consistency.
*Keep it simple.
*The best journey has the fewest steps. Shorten the distance between the
user and the goal.
I don't think if anything can be done about it in the short term. Some
implementations try to address these problems, for example by adding
asdf and there's Practical Common Lisp. Perhaps after a while, when I
get more familiar with Lisp and my complaints will be irrelevant. I
think these problems put off many potential Lisp users, and made me
spend many frustrating evenings trying to get where I am now.
Jack
gavino
java is a huge hunk of shit
popularity is meaningless since sales dollars can push awful gobshite such as kobe potter twilight hansen bros avatar etc.
atatcking the problem hea don with archlinux and common lisp would given same $$ kick java ass every time
Jason Earl
> On Thursday, August 18, 2011 1:04:27 AM UTC+3, Anticomuna wrote:
>
>> All it matters is a KILLER APP.
>
> Well, a killer app for Lisp would probably be GNU Emacs, I think. I
> don't know if we can actually call it "killer" though, since it's not
> *really* that widely used. A lot of people I know are too afraid to
> use it.
>
> The problem with Lisp is, from what I understand, is that a killer-app
> popping up is very unlikely, Lisp being used mainly as a "secret
> weapon", or on servers, or only as an extension language, but rarely
> on the desktop or as an accessible framework.
The reason that Common Lisp is only used on servers or as a secret
weapon is that currently Common Lisp has a very poor story when it comes
to distributing the software. This is what John Wiegley had to say
about why he switched to writing Ledger in C++ from Common Lisp.
http://www.mail-archive.com/ledge...@googlegroups.com/msg01337.html
I love Lisp the language. The community, and its strategies for
deploying and distributing Lisp programs, I don't care for at
all. When I went on IRC to ask how to build my CL-Ledger as a
standalone binary, I got responses ranging from, "You don't want
to do that," to outright insults. Just the amount of manual
effort it takes to dump your running core -- so as to make later
executions of the Lisp environment quicker -- is laborious and
bizarre in terms of how poorly it's documented.
C++ may have its warts, but it's universal, deterministically
speedy, and can be built on any platform as a standalone binary.
Lisp brings great joy to the programmer, at the cost of the
average user; C++ is just about the opposite.
I think that it is also telling that ledger still has a Emacs Lisp front
end (as that is relatively easy to distribute in a useful way).
Quicklisp is a pretty good solution for developers. It allows you to
easily add libraries to your development environment, and it does a
great job of managing dependencies. However, these days that's just
baseline functionality. Developers on UNIX-like platforms expect to be
able to apt-get (or whatever) most of the libraries they need, and the
folks running on Windows expect the development environment to come with
everything they need already included.
On the other hand Quicklisp is apparently a fairly new development, and
I would not be surprised to see it become something truly amazing
(instead of just very good). Lisp has a lot to offer developers, and I
think that it is likely to experience a bit of a renaissance.
Jason
Zach Beane
>> The problem with Lisp is, from what I understand, is that a killer-app
>> popping up is very unlikely, Lisp being used mainly as a "secret
>> weapon", or on servers, or only as an extension language, but rarely
>> on the desktop or as an accessible framework.
>
> The reason that Common Lisp is only used on servers or as a secret
> weapon is that currently Common Lisp has a very poor story when it comes
> to distributing the software. This is what John Wiegley had to say
> about why he switched to writing Ledger in C++ from Common Lisp.
>
> http://www.mail-archive.com/ledge...@googlegroups.com/msg01337.html
>
> I love Lisp the language. The community, and its strategies for
> deploying and distributing Lisp programs, I don't care for at
> all. When I went on IRC to ask how to build my CL-Ledger as a
> standalone binary, I got responses ranging from, "You don't want
> to do that," to outright insults. Just the amount of manual
> effort it takes to dump your running core -- so as to make later
> executions of the Lisp environment quicker -- is laborious and
> bizarre in terms of how poorly it's documented.
Buildapp improves this situation a bit, at least for SBCL.
Zach
Michael Moeller
On Sat, 20 Aug 2011, Tim Bradshaw wrote:
I'm sorry, insulting each other is not my cup of tea. It only
proves I'm talking to an amateur.
Michael Moeller
Very interesting. Do you have an URL?
Regards,
Michael
gavino
apt-get ugh!
I suggest lisp code be distributed as loadable text files.
gzip to save space
load em up
all complex bs quicklisp etc solved with each file having 1 and only 1 dep, so go load that text file
Zach Beane
If there are slides, I don't know where they might be, sorry.
Zach
Michael Moeller
Thanks anyway. I'll search the web.
Regards,
Michael
Jason Earl
Thanks for the pointer. I should have known that such a facility would
exist. Buildapp does appear to be quite a bit more refined than the
method I was using previously. You will almost certainly recognize the
Quicklisp boilerplate I stole from my .sbclrc file.
--8<---------------cut here---------------start------------->8---
(let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp"
(user-homedir-pathname))))
(when (probe-file quicklisp-init)
(load quicklisp-init)))
(ql:quickload "parse")
(in-package :org.notengoamigos.parse)
(sb-ext:save-lisp-and-die "parse" :executable t :toplevel 'main)
--8<---------------cut here---------------end--------------->8---
Of course, both still leave me with a 30 meg executable file for a
trivial little program. However, I can live with that.
Jason
00101010
> One apparent downside with gem is that anybody can publish a "gem",
> while quicklisp has an "editor".
You misspelled "upside"; the ability of anyone to publish libraries
without having to satisfy the particular sensibilities of a gatekeeper
is a feature, not a bug. Developers who have ever had run-ins with
Apple's notoriously fickle, self-serving, and arbitrary app store rules
will know this.
Zach Beane
Anyone can publish sets of libraries that can be installed with
Quicklisp. The default set is curated, and it's currently the only set,
but I don't intend for it to remain the only set.
Zach
00101010
> On 20 ago, 16:33, 00101010
> <zerozeroonezeroonezeroonez...@h2g2.cazoola> wrote:
>> Classic unsubstantiated and erroneous claim. Both Scala and Clojure are
>> gaining significant traction, and on the CLR side so is F# as an
>> alternative to C#. Interestingly, all three alternative hosted languages
>> have a strong functional-programming philosophy behind them.
>
> Not according to reality:
Classic unsubstantiated and erroneous claim.
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Anyone can cite 1 biased study to support their claim. More
widely-recognized authorities, in various eras, have claimed, among
other gems:
* The earth is flat.
* Maggots spontaneously appear in rotting meat.
* The universe is ~6000 years old and consists of the earth, sun, moon,
planets, and a big black sphere with tiny holes in it, with light
shining in from beyond.
* Epileptic seizures are caused by demonic possession.
* Land speeds above about 30mph are impossible, and if they are
possible traveling that fast will kill you.
* The universe is eternal and static, unchanging on the largest scales.
* Heavier-than-air flight is impossible.
* Supersonic flight is impossible.
* There's a world market for maybe a dozen computers.
* Tobacco smoking is perfectly safe.
* The Earth is heading into an ice age sometime around 2000-2010.
* Nobody will ever need more than 640K of RAM.
00101010
> oracle and all its software have been obsolete for 6+ years
>
> java is a huge hunk of shit
>
> popularity is meaningless since sales dollars can push awful gobshite such as kobe potter twilight hansen bros avatar etc.
What does your classic unsubstantiated and erroneous opinion of Avatar
have to do with Lisp, gavino?
00101010
> Lowell Hawkinson had some nice success stories at ILC 2010 regarding
> Gensym's G2 product, which is powered by Common Lisp. It was used to
Not exactly a ringing endorsement. :)
Anticomuna
Zach Beane
It was not, as I understand it, responsible for ordering pizza.
Zach
00101010
> You are classic erroneous and unsubstantiated yourself!
What does your classic unsubstantiated and erroneous claim have to do
with Lisp, Anticomuna?
Tim Bradshaw
> I'm sorry, insulting each other is not my cup of tea. It only
> proves I'm talking to an amateur.
Based on what you said, specifically, "I don't insist in real-time. Of
course you can do many projects in Lisp and a typed Lisp is almost as
fast as C", I concluded you thought "real-time" was somehow about
implementations being fast: was that wrong?
Anton Kovalenko
> Anyone can publish sets of libraries that can be installed with
> Quicklisp. The default set is curated, and it's currently the only set,
> but I don't intend for it to remain the only set.
For now, there might be the only set /published/, but otherwise...
Almost immediately after trying Quicklisp, I wanted it to manage my
local systems as well. Guessing that Zach Beane was likely to have more
urgent tasks than documenting the repository format (or answering my
questions about it), I decided to figure it out myself.
It turned out to be a piece of cake; the only non-trivial detail that
I've stumbled upon was the order of archive entries for SHA1 (i.e. that
namestrings are sorted alphabetically for this purpose, while archive
entries in the *.tar file may go in other order). Even that last detail
would be obvious from Quicklisp code, if I postponed getting SHA1 right
until it's verified by Quicklisp.
Now I would be surprised if I'm unique here; there could be as well 200
lispers with 400 private repositories already. Of course, it makes sense
to wait for published format specification from Zach before putting that
stuff online (and, again, I'm not likely to be unique in thinking like
that).
The point is, if Zach Beane /wanted/ a single Quicklisp repository with
no possibility of alternatives, he would have to do something about the
archive format ASAP (switching to some combination of OLE Storage, XML
and MSI installer databases would be a pretty good deterrent for people
like me).
--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia
A.L.
<lakato...@gmail.com> wrote:
>I report, you decide :P
>http://blog.8thlight.com/steven-degutis/2011/08/15/future-of-lisp.html
>
>Is Clojure really the most popular Lisp today? Common Lisp is C++ with more parantheses? Nu useless?... I have so many problems with this article I don't know where to start.
>
>What do you guys think of what he wrote?
Future of Lisp was already. Yesterday.
A.L.
James Ashley
> The HFT people will care a lot about real-time
> performance guarantees,
And most traders want to pretend they're doing HFT.
I am aware of a person who sold a "real-time trading" system that lets
customers log in and do their transactions from their homes using
their web browsers. I don't know which company was stupid enough to
buy it. I don't know whether he sold them a product that's just
begging to be hacked or if he just got really creative with the
definition of "real-time". I'm 90% certain it was written in C# and
will have at least one extra layer of ws-* calls between the web
server and whatever actually performs the transaction.
> but for virtually everything else transactional
> integrity of various kinds is the critical thing. And my point was
> really that, for financial systems, it is a mistake to think that there
> is some cabal who write these golden perfect systems which hold the
> world together: instead it's held together by a really terrifying mess
> of half-working crapware. I am continually amazed and depressed that
> people get away with it, in fact. Of course I can't rule out the
> golden cabal, but I have never spoken to anyone who claims to have even
> heard of such a thing.
That person mentioned above has also worked with some of the finance
companies that use those rocket science-style economics formulae that
try to analyze trends and predict the future. There are all these
pesky regulations now that tie the IT departments' hands and make it
take forever to get anything done. So the analysts just plug the magic
numbers and formulae into Excel. But that's *really* slow (it's
getting to the point where one day's numbers aren't finished getting
chugged before it's time to kick off the next day's batch). The
solution? Microsoft HPC clusters.
> I do live in hope that in, say, space systems, there are people who
> write stuff that really does work and is well put together,
I've run across a few articles here. Despite the spectacular failures,
NASA seems to have this together pretty well. For them, it seems to be
all about the procedures and the proofs and a rigid formality for
everything. When something *does* go wrong, they seem to have a very
rigid system in place for making sure it never happens again.
It sounds to me like it would be an absolute nightmare place to work.
And they can only do things this way because they don't have to worry
about details like competitors or profit.
> though I
> fear that it's all the same mess.
When you get into private industry, I'm willing to bet that's
absolutely correct. And some of the JPL stories imply that NASA's
pride in the infallibility of its uber-procedures may just be typical
government agency PR work, pretending that adding lots of extra
redundant hoops for the production process to jump through somehow
benefits the finished product quality.
Regards,
James
oni...@gmail.com
Actually You are not the unique one.
quicklisp is really powerful for getting the systems you want.
But it is just one neat part of story.
the missing neat part in quicklisp, I think, is the way that let
lispers publish (say upload or any method) packages or systems onto
quicklisp.
Maybe it is better using a git repository (or maybe any possible sort)
rather than just plain tar files to managing packages and systems.
So that I can have my local quicklisp repository with my lisp code,
and also I can have a remote quicklisp repository to sync to (a
central repository for everyone).
I mean why not make quicklisp a distributed lisp social coding
system. :P
It is just some random thought.
Michael Moeller
opinion in a few lines and I'm allergic to people starting to attack
when out of arguments.
I only tried to give a few examples of software I know of which I
consider important. Lets forget about real-time. There is a lot
more. Normally this "typed and compiled"-thing is the immediate,
all-covering answer always heard from Lispers. Thats why I addressed
this in advance. Although it's true Lisp is a great language, I don't
know of any Lisp in really big or important applications. I'm ready
to be tought otherwise.
Regards,
Michael
Tim Bradshaw
> No, it wasn't meant this way. It's always difficult to express an
> opinion in a few lines and I'm allergic to people starting to attack
> when out of arguments.
It was not my intention to attack you. I just read what you wrote as
meaning that you probably didn't understand what is normally meant by
"real-time", but were making the common mistake of assuming it means
"fast".
> I only tried to give a few examples of software I know of which I
> consider important. Lets forget about real-time. There is a lot
> more. Normally this "typed and compiled"-thing is the immediate,
> all-covering answer always heard from Lispers. Thats why I addressed
> this in advance. Although it's true Lisp is a great language, I don't
> know of any Lisp in really big or important applications. I'm ready
> to be tought otherwise.
Well, for what it's worth I think it's now really a long time since
performance (as opposed to real-tiem) characteristics of Lisp systems
mattered very much (which is not to say that people don't endless
repeat these arguments: they do, of course).
I also think the whole library-availability / delivery thing is
another long-dead problem: certainly it was not even slightly a problem
for me when I wrote stuff more seriously, and that's now nearly ten
years ago.
What I think is the actual problem is, in fact, the same one that
stopped me: I just didn't have any good enough ideas for a killer app
and probably also was not willing to sacrifice enough of my life if I
did. It wasn't Lisp, it was me. And, in my opinion, a lot of people
could do with admitting that, rather than blaming their tools.
I think that's probably all I have to say. Quoting myself earlier in
the thread "the interesting thing here, of course, isn't anything to do
with the future of Lisp - discussion of that has never been useful in
my experience": and yet I've immediately got sucked into it.
Michael Moeller
> Well, for what it's worth I think it's now really a long time since
> performance (as opposed to real-tiem) characteristics of Lisp systems
> mattered very much (which is not to say that people don't endless repeat
> these arguments: they do, of course).
>
> I also think the whole library-availability / delivery thing is another
> long-dead problem: certainly it was not even slightly a problem for me
> when I wrote stuff more seriously, and that's now nearly ten years ago.
>
> What I think is the actual problem is, in fact, the same one that
> stopped me: I just didn't have any good enough ideas for a killer app
> and probably also was not willing to sacrifice enough of my life if I
> did. It wasn't Lisp, it was me. And, in my opinion, a lot of people
> could do with admitting that, rather than blaming their tools.
>
> I think that's probably all I have to say. Quoting myself earlier in the
> thread "the interesting thing here, of course, isn't anything to do with
> the future of Lisp - discussion of that has never been useful in my
> experience": and yet I've immediately got sucked into it.
>
Regards,
Michael
Anton Kovalenko
> the missing neat part in quicklisp, I think, is the way that let
> lispers publish (say upload or any method) packages or systems onto
> quicklisp.
We have something similar with ASDF-INSTALL, and it's the recipe for
/not/ being easy to use. If the whole collection is not edited by
someone who strives for system compatibility (with each other, and with
existing CL implementations), what's "quick" about quicklisp will go
away.
> Maybe it is better using a git repository (or maybe any possible sort)
> rather than just plain tar files to managing packages and systems.
Been there as well (remember clbuild). Quicklisp client doesn't use any
external program, even when unarchiving, and I like it this way.
> So that I can have my local quicklisp repository with my lisp code,
> and also I can have a remote quicklisp repository to sync to (a
> central repository for everyone).
What's the point of a /central/ repository for everyone? With no editor
in charge of the whole thing, the only difference it makes (relative to
a private repository for each user) is a single point of failure.
As of a private repository, you can have it now. As of making your
/collection/ of published code available for quicklisp, I can have it
(and it won't be long till everyone can have it, anyway).
> I mean why not make quicklisp a distributed lisp social coding
> system. :P
Because it has another place in the universe (the equivalent for Linux
package management would be /apt/ or /yum/; to summarize, it's not a
territory where hackers are hacking, it's where maintainers get the
boring details right, so the whole thing is ready for user).
Lisp social coding would be valuable, but it will require another effort
to be implemented. I will know it's there when I see a debugger
displaying something like this:
.... CHIPZ:DECOMPRESSION-ERROR...
Restarts:
[1] Report bug against CHIPZ
[2] Propose arguments <...> as a new regression test
00101010
> What's the point of a /central/ repository for everyone? With no editor
> in charge of the whole thing, the only difference it makes (relative to
> a private repository for each user) is a single point of failure.
There is a second difference: there's a one-stop shop.
Now, how to have that cake and eat it too is an interesting conundrum.
Some combination of mirrors, backup DNS servers, and BitTorrent, perhaps?
Anton Kovalenko
>> What's the point of a /central/ repository for everyone? With no editor
>> in charge of the whole thing, the only difference it makes (relative to
>> a private repository for each user) is a single point of failure.
>
> There is a second difference: there's a one-stop shop.
Then it's enough to have a single place for /metadata/, and ASDF-INSTALL
already does that. Will work fine, until someone wants an /alternative/
place for metadata, and a choice of the right one available for users,
which brings us back to square one.
There is an inherent /political/ problem with a "single place for
everyone to upload code, so all this code works well
together". Technical solution is impossible, unless you throw away at
least one of (single-place-p for-everyone-p works-well-together-p).
> Now, how to have that cake and eat it too is an interesting
> conundrum. Some combination of mirrors, backup DNS servers, and
> BitTorrent, perhaps?
A problem with distributed voluntary mirroring of packages (without
authoritative /central/ repository) can be solved technically. Perhaps
the only non-trivial thing is the verification of data integrity; let's
wait until (and/or do something to ensure) Quicklisp verification is
ready.
00101010
> 00101010 <zerozeroonezer...@h2g2.cazoola> writes:
>> Now, how to have that cake and eat it too is an interesting
>> conundrum. Some combination of mirrors, backup DNS servers, and
>> BitTorrent, perhaps?
>
> A problem with distributed voluntary mirroring of packages (without
> authoritative /central/ repository) can be solved technically. Perhaps
> the only non-trivial thing is the verification of data integrity; let's
> wait until (and/or do something to ensure) Quicklisp verification is
> ready.
In many areas, authoritative sources (such as the original developers)
publish MD5 sums for their files. If you're worried about bogus MD5 sums
being published by black hats for the same files, throw on a layer of
public key crypto to digitally sign the MD5 attestations.
Anton Kovalenko
>> the only non-trivial thing is the verification of data integrity;
>> let's wait until (and/or do something to ensure) Quicklisp
>> verification is ready.
> In many areas, authoritative sources (such as the original developers)
> publish MD5 sums for their files. If you're worried about bogus MD5
> sums being published by black hats for the same files, throw on a
> layer of public key crypto to digitally sign the MD5 attestations.
That's what I mean (and what I expect to see in Quicklisp, including a
layer of public key crypto).
I guess it would be already in Quicklisp, unless there were an
implementation (let me avoid proper names here :) that can't compute
SHA1 reasonably fast when it's implemented in Lisp (when we have SHA1,
public key verification is no problem, even for that implementation:
with DSA, modular exponentation is the next most time-consuming part,
but even a very naive code doesn't take noticeable time).
oni...@gmail.com
> /not/ being easy to use. If the whole collection is not edited by
> someone who strives for system compatibility (with each other, and with
> existing CL implementations), what's "quick" about quicklisp will go
> away.
> ...
> What's the point of a /central/ repository for everyone? With no editor
> in charge of the whole thing, the only difference it makes (relative to
> a private repository for each user) is a single point of failure.
I don't mean we do not need someone striving on the system
compatibility.
And I really appreciate the endeavor so far made that we can have an
easy-to-use lisp with quicklisp.
(This is why we still need a central place where we can rely on.)
Actually, I mean integrating more lispers' effort on the system
compatibility.
(If you have your local sources and you really want to publish, you
must ensure its compatibility at least. )
> Been there as well (remember clbuild). Quicklisp client doesn't use any
> external program, even when unarchiving, and I like it this way.
It's pure lisp implemented and without external package dependency.
I like its pure way, too.
> Because it has another place in the universe (the equivalent for Linux
> package management would be /apt/ or /yum/; to summarize, it's not a
> territory where hackers are hacking, it's where maintainers get the
> boring details right, so the whole thing is ready for user).
>
Why not make hackers and maintainers working together.
oni...@gmail.com
> everyone to upload code, so all this code works well
> together". Technical solution is impossible, unless you throw away at
> least one of (single-place-p for-everyone-p works-well-together-p).
>
you are right. It's difficult to control it when everyone can have a
hand in it.
I wonder if we could have some sort of tweak on it a little so that
we
don't lose (single-place-p for-everyone-p works-well-together-p) and
we still live well.
I'm still optimistic on it.
Peder O. Klingenberg
> Unless we are talking about cell phone games and other toy
> applications I'm afraid things are more complex.
We do stock trading and banking. All in-house development, all (well,
except for some simplistic php at the front end) Lisp, evolved over 10+
years. Yes, the systems are a tad more complex than a cellphone game.
Lisp is a great help in managing that complexity.
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.
WJ
> Possibly because you can write your program in 1/10th of the
> amount of code, and 1/10th of the time?
>
> For the last year or so, I've been using Lisp exclusively, and
> the numbers above are, if anything, conservative.
Give some example code.
--
Bigos
I won't provide code examples for comparison. Also can't estimate amount
of code I would use in Lisp compared to a more conventional language.
But I can definitely see improvement in development speed and
productivity. I have understood Lisp only recently and I'm amazed what I
can achieve. I have recently written few programs in Lisp that I
wouldn't be bothered to write before due to amount of time and effort it
would involve. Even with quite limited Lisp skills suddenly all became
possible.
I'm not a professional, but a hobbyist. I can't afford spending all day
fighting programming problems. Also, I don't need to distribute software
written for my own use. Ease and speed of development is most important
for me, so Lisp naturally seems to be a good choice. I use much less
Ruby now. But even if I do, thanks to Lisp, I have fresh perspective at
certain Ruby problems.
Marco Antoniotti
He uses a combination of the pretty-printer with read-macros. The result is so un-lispy that he is afraid to publish it here.
Cheers
--
MA
Antsan
Raymond Wiker
> As if that would make anything easier...
8 lines of (relatively simple) of format usage beats 1000 lines of
Java, anytime.