Hi,
I'm really new to Lisp. I had heard of it before and got the
impression of a dead language with an exotic syntax and no real use.
My opinion was changed by Paul Graham's article <a href = "http://
www.paulgraham.com/avg.html">Beating the averages</a>.
I started investigating and in the last weeks I've been watching the
videos of "Structure and Interpretation of Computer Programs" and I'm
reading "Practical Common Lisp". I liked a lot what I heard and read
and tried to tell my friends and colleagues about it, but the reaction
was like I'm going nuts, even though I made it clear that I intend to
learn more and try to implement a nontrivial program in Common Lisp
before forming my final opinion. The most frequent argument I heard
was: "If Lisp was that good, it would be much more popular".
So I started asking myself why isn't Lisp popular. Is it because of
it's syntax? Is it because of the prejudice that it is slow? Or some
other reason? I searched the Internet a little and saw that other
people had asked themselves the same question. A discussion on
Lispcast titled <a href = "http://www.lispcast.com/drupal/node/29">No
easy download</a> caught my attention along with another article by
Paul Graham - <a href = "http://www.paulgraham.com/popular.html">Being
Popular</a>.
So I formed my own opinion on why Lisp isn't popular and summarized it
in the following two points:
1. There are not enough libraries in Lisp. Even worse, most of the
existing libraries are not standard. The fastest way to implement
something is to have it already implemented for you.
2. Most people don't see the advantages of Lisp over their programming
language even for tasks for which Lisp is really much more suitable,
because they don't know what can be done easily in Lisp.
And then I asked myself if there are circumstances which would help
Lisp get back on center stage. What I'm certain of is two things.
First, as time goes by, more and more features of Lisp will get
introduced to other languages and its will become harder to convince
people to make the transition. And second, trying to get people to
learn Lisp so they would appreciate it won't work. They should be
convinced of the use to learn it before they agree to do it. And so I
got to this crazy idea which I want to share. If I'm being stupid
please bear with me.
The best way to convince people to learn Lisp is by convincing them to
use it first and then use that to show them its advantages. I don't
know about Scheme, but the FFI of Common Lisp seems to be good enough
to allow for other languages to use libraries written in Lisp. So if
there are powerful libraries written in Lisp which can be used from C+
+, Java, C#, Perl, Python, Ruby, etc, people will use them. Several
widely used popular libraries in Lisp, especially for tasks which are
outside the traditional Lisp domain, can really make a difference in
the attitude towards the language.
The other thing which is mandatory is to make rich libraries for Lisp
which are readily available, comprehensive, free and standard. The
best way to do this is by creating the prerequisites for the emergence
of libraries which are de facto standard, like what boost is for C++.
Instead of almost 10 libraries for GUI of which people don't know
which to choose, there should be no more than three and it should be
immediately clear what's the use of each of them.
And the third thing which could really boost things up is some way to
make both kinds of libraries very public so that non-lispers could
become aware that:
1. They can benefit from Lisp without learning it through powerful
libraries written in Lisp.
2. There will benefit from investing in learning Lisp, because there
are a lot of solutions readily available.
And here comes my crazy idea. All of this can be achieved through a
web site targeted at developers in all programming languages. This
site should be the best programming libraries directory on the
internet, hosting libraries in any programming language. Its main goal
should be to hold as many libraries as possible and provide powerful
search, ranking and comparison features. Here are some of the features
I have in mind:
1. Each library should have in its description separate fields for
implementation language(s) and target language(s) unlike sourceforge
which has only one language field. To the users of the library it
matters much more what languages can use the library, but the
implementation language is important too.
2. The "supported feature" fields of the libraries should have
rankings associated with them so that users could rank the support for
individual features separately.
3. The users should be able to add new library categories with custom
feature fields.
4. The users should be able to sort the libraries according to their
own ranking criteria like the <a href = "http://
shootout.alioth.debian.org/gp4/index.php">Gentoo Benchmark<\a> or in
some other way.
5. The users should be able to create comparison tables for two or
more libraries, choosing which features to compare.
I think that if such a site exists and contains all important
libraries for the major programming languages it will attract enough
attention to start the ball rolling and become the best programming
libraries directory. Of course a site of this scale will require some
serious funding but I believe this is a solvable problem.
And with this site in place, it will be up to the Lisp community to
start actively pursuing the interest of the other programmers. The key
is to identify the most popular libraries and implement them in Common
Lisp and Scheme. This will provide Lisp with the libraries that people
want thus making it ultimately more useful. And if these libraries are
more powerful than the original and are made available to other
programming languages, they will have the potential to start to draw
people towards Lisp.
Of course there is a reduced version of this agenda, which is to use
existing software project sites like Sourceforge and implement the
most popular libraries there in Lisp and post them on Sourceforge. But
existing project sites are not targeted at libraries specifically so
they don't provide the tools to highlight the key features and compare
them. Furthermore, a good libraries site for Lisp is needed anyway,
and it will only gain if it allows libraries in other languages
because it will draw the attention of non-lispers.
Well that's it, I hope I didn't annoy anybody, and sorry for the
really long post, but I wanted to share this idea and see what others
think.
On 23 äÅË, 13:08, MishoM <···············@gmail.com> wrote:
> Hi,
>
> I'm really new to Lisp.
>
> ..........
>
> 1. There are not enough libraries in Lisp. Even worse, most of the
> existing libraries are not standard. The fastest way to implement
> something is to have it already implemented for you.
That's your opinion. My opinion is that it is way early for you to
draw conclusions. If you want to learn keep your concentration here
and be mindful of what the more experienced ones have to say.
> 2. Most people don't see the advantages of Lisp over their programming
> language even for tasks for which Lisp is really much more suitable,
> because they don't know what can be done easily in Lisp.
How is it my problem that someone decided to crawl instead to walk?
MishoM wrote:
> Hi,
>
> I'm really new to Lisp. I had heard of it before and...
...had exactly the same reaction as anyone who finds Lisp. What varies
is whether anyone immediately starts writing Lisp code or instead drops
into comp.lang.lisp to rally the troops, form a committee, create a
repository, take out an ad, hold a conference, and straighten everybody
else out.
hth,kenneth
Thanks to all of you. I suspected that my idea was stupid, and said
so ;)
And yes, I know I need more time to learn Lisp, before making
statements about it. I never said to anybody "Lisp is great", I just
said, "I'm learning about Lisp. I'll have a definite opinion when I've
tried to use it for a while, but this far it seem to be great."
About popularity - I think it is of great help for any programming
language to be popular because this means there's a stronger driving
force to maintain it.
Maybe I'm wrong about the amount of libraries - from browsing sites
(including virtually all sites you referenced me to) I got the
impression that most libraries are targeted towards web development
and AI.
And about trying to propose a way to popularize the language without
even having started to use it - that's true, these were just some
thoughts which I wanted to share to people who might find them either
interesting or extremely stupid. It turned out to be the later. These
thoughts were to a great extent provoked by the discussions I quoted.
Anyway, as the Chinese say "He, who speaks up may be a fool for 5
minutes, but he who doesn't remains a fool for his whole life." So,
thank you for taking the time to answer and I'll dismiss the rude
comments, they insult only those who made them.
On Dec 23, 6:10 pm, Kenny <·········@gmail.com> wrote:
> MishoM wrote:
> > Hi,
>
> > I'm really new to Lisp. I had heard of it before and...
>
> ...had exactly the same reaction as anyone who finds Lisp. What varies
> is whether anyone immediately starts writing Lisp code or instead drops
> into comp.lang.lisp to rally the troops, form a committee, create a
> repository, take out an ad, hold a conference, and straighten everybody
> else out.
>
> hth,kenneth
I've installed on my laptop a CL system and I'm going to start writing
code as soon as I feel I've learned enough to be able to write
anything meaningful. Sorry for "ralling the troops etc.", I didn't
have the intention of organizing or straightening anything, I don't
have the time for this. I just wanted to drop an idea, silly as it
might be.
On Tue, 23 Dec 2008 08:25:42 -0800, MishoM wrote:
> I've installed on my laptop a CL system and I'm going to start writing
> code as soon as I feel I've learned enough to be able to write anything
> meaningful. Sorry for "ralling the troops etc.", I didn't have the
No, you are getting it wrong. Don't put off writing code. Start writing
code now. Do simple things, they will be "meaningful" in the sense that
you will be learning from them. The first few chapters of ANSI Common
Lisp or PCL should allow you to write interesting code.
Reading passively reading will never teach you any Lisp (or any other
programming language, or mathematics, natural sciences, economics, etc.
for that matter), you need to get your hands dirty and _do_ stuff.
HTH,
Tamas
Tamas K Papp wrote:
> On Tue, 23 Dec 2008 08:25:42 -0800, MishoM wrote:
>
>> I've installed on my laptop a CL system and I'm going to start writing
>> code as soon as I feel I've learned enough to be able to write anything
>> meaningful. Sorry for "ralling the troops etc.", I didn't have the
>
> No, you are getting it wrong. Don't put off writing code. Start writing
> code now. Do simple things, they will be "meaningful" in the sense that
> you will be learning from them. The first few chapters of ANSI Common
> Lisp or PCL should allow you to write interesting code.
>
> Reading passively reading will never teach you any Lisp (or any other
> programming language, or mathematics, natural sciences, economics, etc.
> for that matter), you need to get your hands dirty and _do_ stuff.
>
> HTH,
>
> Tamas
I haven't done any of the examples in the lisp books I've read. I've
started, but there was no direct satisfaction. There wasn't anything
really intriguing.
What I did instead, started translating various small "C/C++" code -
mostly libraries to Common Lisp - decompression, math, rendering, opengl
stuff. Currently I'm porting my Voxel Space Application for the iPhone
to Common Lisp - I would like to maintain the code in it, not in C. -
http://picasaweb.google.com/malkia/Mont
Probably not the best around, but I decided that for me to find the road
to lisp is to start from somewhere where I'm experienced (non-functional
imperative languages, semi-objective, close-to-the-metal etc.) and reach
my goal by using functional features more and more.
For example I've started right away using dotimes, dolist, and haven't
touched map functions for a while, until I felt comfortable. I'm barely
now scratching the macro-code, first took big steps of transforming
large pieces of duplicate code to be generated into one (mainly for
matrix operations), but now I'm trying little more iterative steps -
write some small macro, that calls a function to expand something, check
it on the REPL, go back, etc.
Later when I'm ready with my "written & driving" common lisp test, I'll
start digging more into PAIP, and SICP.
Certainly 15+ years of Basic, Pascal, X86 Assembly, C/C++, pointers,
manual memory management (well Basic had GC, but I was unaware then of
pointers), DMA and other "wonderful" machine related tasks are hard to
take out of me, but I'm trying. I'm still imaging every bit & piece I
put in the code, and how it would look in assembly.
This is also due to my professional career - that of being a console
game programmer. I learned to care about every memory allocation, every
bit that went to a structure, the layout of the structure in memory,
etc. It made me a cripple - I should stop worrying about such details,
and just do it, without thinking much how it would be in the machine.
So what I do expect, and I'm already benefiting, from Lisp is exactly
that - To unlearn the practice of close-to-the-metal programming, and
think more about expressing the ideas easier - e.g. being more
close-to-the-human.
So to me that's lisp - a close-to-the-human language, human in it's most
average case - someone who at least can do (+ 1 2)
Thanks,
Dimiter "malkia" Stanev.
Tamas K Papp <······@gmail.com> writes:
> Reading passively reading will never teach you any Lisp (or any other
> programming language, or mathematics, natural sciences, economics, etc.
> for that matter), you need to get your hands dirty and _do_ stuff.
That's not universally true. It depends on how you learn things,
which is an individual trait. I learned Lisp over a summer holiday,
reading ANSI Common Lisp on a lawn chair. This was back when I was a
student and laptops were expensive, so I didn't have a computer there.
I worked out the examples and exercises in my head instead, and by the
time I installed cmucl and ilisp for the first time I already had a
reasonable grasp of the language.
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.
On Tue, 23 Dec 2008 03:08:13 -0800, MishoM wrote:
> I started investigating and in the last weeks I've been watching the
> videos of "Structure and Interpretation of Computer Programs" and I'm
> reading "Practical Common Lisp". I liked a lot what I heard and read and
> tried to tell my friends and colleagues about it, but the reaction was
> like I'm going nuts, even though I made it clear that I intend to learn
> more and try to implement a nontrivial program in Common Lisp before
Hey dude,
If you started talking about how great a language is _before_ you have
used it for a while, I wouldn't be more polite to you either. I would
be rude and tell you to stop wasting my time.
> And then I asked myself if there are circumstances which would help Lisp
> get back on center stage. What I'm certain of is two things. First, as
(Common) Lisp doesn't need to be "popularized", especially not by
people who don't really program in it. CL is here, you can either use
it or not use it, I would recommend the former but I don't really care
what you do.
Get some perspective - you have watched a video and started reading a
book, and now you are ready to tell the world how great Lisp is, and
tell the lispers how to make Lisp better and more popular. You are
simply not a credible source of ideas on either. Stop wasting your time
- just learn Lisp and start programming.
Tamas
Tamas K Papp wrote:
> On Tue, 23 Dec 2008 03:08:13 -0800, MishoM wrote:
>
>
>>I started investigating and in the last weeks I've been watching the
>>videos of "Structure and Interpretation of Computer Programs" and I'm
>>reading "Practical Common Lisp". I liked a lot what I heard and read and
>>tried to tell my friends and colleagues about it, but the reaction was
>>like I'm going nuts, even though I made it clear that I intend to learn
>>more and try to implement a nontrivial program in Common Lisp before
>
>
> Hey dude,
>
> If you started talking about how great a language is _before_ you have
> used it for a while, I wouldn't be more polite to you either. I would
> be rude and tell you to stop wasting my time.
You must be like me, you just like being rude.
I think you forgot how good is Lisp.
I would at this point refer you to the many RtLs that include the
sentence "I knew at once I had found The One", but the black helicopters
are still looking for them.
>
>
>>And then I asked myself if there are circumstances which would help Lisp
>>get back on center stage. What I'm certain of is two things. First, as
>
>
> (Common) Lisp doesn't need to be "popularized", especially not by
> people who don't really program in it. CL is here, you can either use
> it or not use it, I would recommend the former but I don't really care
> what you do.
>
> Get some perspective - you have watched a video and started reading a
> book, and now you are ready to tell the world how great Lisp is, and
> tell the lispers how to make Lisp better and more popular. You are
> simply not a credible source of ideas on either.
Not bad, but I would have dragged his Mom into it somewhere.
> Stop wasting your time
> - just learn Lisp and start programming.
Yes!
kt
On Tue, 23 Dec 2008 10:51:08 -0500, Kenny wrote:
> You must be like me, you just like being rude.
Yes, sometimes.
> I think you forgot how good is Lisp.
>
> I would at this point refer you to the many RtLs that include the
> sentence "I knew at once I had found The One", but the black helicopters
> are still looking for them.
Nope, I know how good Lisp is, I use it daily. And I had the "I knew
at once" feeling when I started learning it. But I did not go and
proselytize to colleagues and friends, saying "look at this great
language! I have been using it for three whole days! you should be
using it too!".
Instead I just started working in it. Lo and behold, two colleagues
have already asked about Common Lisp. But I don't really care if they
will eventually start using it -- _I_ am using it, and it helps _me_
enormously. I don't see the point in convincing people about Lisp.
If they care about implementing complex programs efficiently, they
will look for it and eventually find it. If they don't, there is no
way I could convince them to use Lisp.
Recently I started working on a project that automates k-order
perturbation solutions of functional equations. I know of another,
similar system built in C++, which is a total nightmare of
Greenspunning (imagine manipulating symbolic expressions in C++. No
wait, don't imagine, you will have bad dreams). I will eventually
make this work public. But will go around convincing people to use
it? No, I couldn't care less.
Best,
Tamas
On Dec 23, 6:41 pm, Tamas K Papp <······@gmail.com> wrote:
> On Tue, 23 Dec 2008 10:51:08 -0500, Kenny wrote:
> > You must be like me, you just like being rude.
>
> Yes, sometimes.
>
> > I think you forgot how good is Lisp.
>
> > I would at this point refer you to the many RtLs that include the
> > sentence "I knew at once I had found The One", but the black helicopters
> > are still looking for them.
>
> Nope, I know how good Lisp is, I use it daily. And I had the "I knew
> at once" feeling when I started learning it. But I did not go and
> proselytize to colleagues and friends, saying "look at this great
> language! I have been using it for three whole days! you should be
> using it too!".
Unfortunately (for me) you are right. I've just been a little bit too
enthusiastic, for various reasons, the main of which is that I've been
writing in various languages, mainly C++ for the last 10+ years and
I've repeatedly found myself frustrated by the limitations of the
languages and learning about lisp I see that I could do these things
which I wanted to do before and couldn't. And more than that. Anyway,
thank you all for pointing out how far ahead of myself I'm getting.
Have nice holidays.
MishoM wrote:
> On Dec 23, 6:41 pm, Tamas K Papp <······@gmail.com> wrote:
>
>>On Tue, 23 Dec 2008 10:51:08 -0500, Kenny wrote:
>>
>>>You must be like me, you just like being rude.
>>
>>Yes, sometimes.
>>
>>
>>>I think you forgot how good is Lisp.
>>
>>>I would at this point refer you to the many RtLs that include the
>>>sentence "I knew at once I had found The One", but the black helicopters
>>>are still looking for them.
>>
>>Nope, I know how good Lisp is, I use it daily. And I had the "I knew
>>at once" feeling when I started learning it. But I did not go and
>>proselytize to colleagues and friends, saying "look at this great
>>language! I have been using it for three whole days! you should be
>>using it too!".
>
>
> Unfortunately (for me) you are right. I've just been a little bit too
> enthusiastic, for various reasons, the main of which is that I've been
> writing in various languages, mainly C++ for the last 10+ years and
> I've repeatedly found myself frustrated by the limitations of the
> languages and learning about lisp I see that I could do these things
> which I wanted to do before and couldn't. And more than that. Anyway,
> thank you all for pointing out how far ahead of myself I'm getting.
Actually I think you are doing just fine and we certainly appreciate the
enthusiasm and your taking the trouble to share. I was more just letting
you know we all feel the same way and waste a lot of time thinking about
how to evangelize Lisp (the whackier amongst us think we have to change
the name or be more like C++ or Java) and about a dozen community
projects have died at birth so STFU and start coding. :)
hth,kenneth
From: Hyphenated Smug Elitist
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <giqr5c$2nie$1@opal.icpnet.pl>
[spoken from an ivory tower.]
MishoM <···············@gmail.com> wrote:
> So I started asking myself why isn't Lisp popular. Is it because of
> it's syntax? [...]
The languages being popular can be roughly divided as such:
1) Ones favored by large corporations, favoring programmer
replaceability way over language expressibility. The obstructionist
compiler and interface is designed to make the code comprehensible
for the next drone in line after the current one asks for a sick
leave or a raise^W^W^W^W^W^W^W^Wjust kidding.
2) Languages designed by self-proclaimed "language design architects"
for hobbyists programmers. Perl's a great example, reading just a bit
lets an uneducated hobbyist create (fsvo) useful programs, comprising
instant gratification. Major version revisions later, the syntax and
semantics resemble an inanely-knit cargo cult of features borrowed
from all over the paradigms.
The ones not being popular:
1) Languages designed for expressibility with no regard for market value
or the affection of the Free Software mob. Examples include Lisp and
Smalltalk.
The lists are not exhaustive.
Popularity's not that much of a problem. Protocol support can be
implemented from scratch for NIH value, bindings can be autogenerated.
Newcomer supply exists and existing users tend to stick with Lisp.
> 1. There are not enough libraries in Lisp. Even worse, most of the
> existing libraries are not standard. The fastest way to implement
> something is to have it already implemented for you.
Standard? There are de-facto standards for protocol implementation. The
trend towards a large standard library is rather new, starting somewhere
around Java. De-facto standards seem to be good enough, asking around on
#lisp for favored protocol implementation produces a desirable response.
> 2. Most people don't see the advantages of Lisp over their programming
> language even for tasks for which Lisp is really much more suitable,
> because they don't know what can be done easily in Lisp.
Most people lack an attention span required to comprehend the advantages
of Lisp. Let 'em rot with their 60-ish type checkers and Unix-centered
scripting languages, only incidentally used for any higher purpose. Stop
exposing human children to television from such a young age as well as
ease up on the instant gratification bit. Corporate
programming-language-choice habits won't nudge a bit as long as
capitalist hegemony exists. Such is life.
> First, as time goes by, more and more features of Lisp will get
> introduced to other languages and its will become harder to convince
> people to make the transition.
If this syncretism goes on, "other languages" might finally become Lisps
and there will be no distinction between "mainstream" and "us". Not
likely. They'd rather expose their clunky ASTs through an unwieldy
interface.
> The best way to convince people to learn Lisp is by convincing them to
> use it first and then use that to show them its advantages. I don't
> know about Scheme, but the FFI of Common Lisp seems to be good enough
> to allow for other languages to use libraries written in Lisp.
Interfacing C from Lisp is easy, but not exactly the same the other way
around. Still, there's ECL with "embeddable" in its name. ECL programs
can be compiled to machine code as libraries and interfaced from C. ECL
has a rather nice FFI making interfacing from C a walk in the park.
Still, it forces Boehm GC into the process and using less-invasive GNU
Guile for embeddability/scripting purposes might be a better solution.
> The best way to do this is by creating the prerequisites for the
> emergence of libraries which are de facto standard, like what boost is
> for C++. Instead of almost 10 libraries for GUI of which people don't
> know which to choose, there should be no more than three and it should
> be immediately clear what's the use of each of them.
And who's gonna board the de-facto-standard-committee? Much rather save
some power struggles and authority-waving. Maybe the cliki pages could
be improved. For now:
- Use cells-gtk if you like the spreadsheet model, Kenny's implicit
declaration of macros (^foo) for accessing cells a'la defstruct and
Kenny's deliberate lack of documentation in the goal of supporting
Kenny's business model.
- Use ltk if Tk is good enough for you. AFAIK it's pretty stable and
ready for development.
- Use McCLIM if... well, I don't know much about McCLIM. It's been
usable for all intents and purposes since the Genera times.
Recommend asking questions directly instead of through a veiled
reference to a "potential newcomer user".
> And with this site in place, it will be up to the Lisp community to
> start actively pursuing the interest of the other programmers.
What are we, televangelists? I mind my own business not caring about the
guy next door.
--
Nawet świnka wejdzie na drzewo kiedy jest chwalona.
On 23 dic, 15:04, Hyphenated Smug Elitist <sthalik
·······@tehran.lain.pl> wrote:
> Interfacing C from Lisp is easy, but not exactly the same the other way
> around. Still, there'sECLwith "embeddable" in its name.ECLprograms
> can be compiled to machine code as libraries and interfaced from C.ECL
> has a rather nice FFI making interfacing from C a walk in the park.
> Still, it forces Boehm GC into the process and using less-invasive GNU
> Guile for embeddability/scripting purposes might be a better solution.
Thanks for the nice description. I just wanted to make a small
precision here. Guile was also heading towards using Boehm GC, AFAIK,
but it any case it does not matter much.
Any Lisp implementation is going to need a garbage collecting memory
allocator. However your C program is not forced to use it. The Boehm
GC may coexist with your use of malloc/free or new/delete, if
configured properly. Indeed, ECL deactivates a feature of Boehm GC
which is to intrusively scan the data sections of the program in which
ECL is embedded, so that memory is not accidentally retained.
Juanjo
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <git8e9$7gv$1@opal.icpnet.pl>
thus spoke Juanjo <·····················@googlemail.com>:
> Any Lisp implementation is going to need a garbage collecting memory
> allocator. However your C program is not forced to use it. The Boehm
> GC may coexist with your use of malloc/free or new/delete, if
> configured properly. Indeed, ECL deactivates a feature of Boehm GC
> which is to intrusively scan the data sections of the program in which
> ECL is embedded, so that memory is not accidentally retained.
Still, running the resulting program under Valgrind VM resulted in a
crash last time I used ECL. Valgrind tries to parse the machine code of
a binary and transform it somehow, this doesn't play well with Boehm
GC's assembly.
Dunno, maybe something changed, it was more than a year ago...
--
Nawet świnka wejdzie na drzewo kiedy jest chwalona.
On 24 dic, 13:03, Stanis³aw Halik <··············@tehran.lain.pl>
wrote:
> thus spoke Juanjo <·····················@googlemail.com>:
> Still, running the resulting program under Valgrind VM resulted in a
> crash last time I used ECL. Valgrind tries to parse the machine code of
> a binary and transform it somehow, this doesn't play well with Boehm
> GC's assembly.
Not being able to run in Valgrind is not really a killing problem and
it tells worse about the VM than about the library you are trying to
debug :-) Valgrind is normally used for detecting leaks and other
problems in C++ programs. It is no wonder that the GC is not good for
Valgrind for it uses low level and rather advanced capabilities of
your operating systems, such as memory protection and the like. OTOH
the Boehm-Weiser library provides those features such as leak
detection, which could be activated if you need them, and you may also
deactivate the most advanced techniques that the GC uses, such as
memory protection and generational garbage collection.
Juanjo
In article
<····································@z27g2000prd.googlegroups.com>,
MishoM <···············@gmail.com> wrote:
> Hi,
>
> I'm really new to Lisp. I had heard of it before and got the
> impression of a dead language with an exotic syntax and no real use.
> My opinion was changed by Paul Graham's article <a href = "http://
> www.paulgraham.com/avg.html">Beating the averages</a>.
>
> I started investigating and in the last weeks I've been watching the
> videos of "Structure and Interpretation of Computer Programs" and I'm
> reading "Practical Common Lisp". I liked a lot what I heard and read
> and tried to tell my friends and colleagues about it, but the reaction
> was like I'm going nuts, even though I made it clear that I intend to
> learn more and try to implement a nontrivial program in Common Lisp
> before forming my final opinion. The most frequent argument I heard
> was: "If Lisp was that good, it would be much more popular".
>
> So I started asking myself why isn't Lisp popular. Is it because of
> it's syntax? Is it because of the prejudice that it is slow? Or some
> other reason? I searched the Internet a little and saw that other
> people had asked themselves the same question. A discussion on
> Lispcast titled <a href = "http://www.lispcast.com/drupal/node/29">No
> easy download</a> caught my attention along with another article by
> Paul Graham - <a href = "http://www.paulgraham.com/popular.html">Being
> Popular</a>.
>
> So I formed my own opinion on why Lisp isn't popular and summarized it
> in the following two points:
>
> 1. There are not enough libraries in Lisp. Even worse, most of the
> existing libraries are not standard. The fastest way to implement
> something is to have it already implemented for you.
>
> 2. Most people don't see the advantages of Lisp over their programming
> language even for tasks for which Lisp is really much more suitable,
> because they don't know what can be done easily in Lisp.
...
There are many reasons.
Though it is good for a newbie to think of popularity, etc.,
it does not really help that much. What you are writing
about comes up quite often.
You have a better position to rate the usefulness for Lisp
and where it is applicable when you have some experience
using it. That means you should have written some
software. Currently your position is like looking at
a Mercedes Benz brochure, really liking the cars, and
wondering yourself why not everybody drives a Mercedes.
Then you talk to the engineers how to make Mercedes
more popular. You can imagine that this will not
change much...
Better:
Dive in, write some software, see where it lacks libraries,
contribute, etc. If you want to help on Usenet, get
some experience and help people solving problems. Help
other newbies to get over the first hurdles.
Starting points for you:
Community Wiki
http://www.cliki.net/
Projects
http://common-lisp.net/
IRC channel for Common Lisp programmers
#lisp
Though Lisp (Common Lisp) is not that popular, it is still
quite active, there have been excellent contributions
from younger programmers in the last years, several
implementations are actively maintained and there
are implementations that are extremely good. So there
is something to it that lets it survive even though
it might not look 'popular'.
Lisp is still very useful for:
* complex software written by small teams
(actually the worst thing you can do is write
complex software in a large team) with high
productivity
* software that grows incrementally and evolutionary
* interactive software development
* software that needs a very flexible language that
can incorporate new ideas, styles and domains.
You don't have to wait for the language designer
to implement a new loop construct, you can
write your own with any complexity you like.
* as an extension language. See Emacs.
If that kind of describes your needs and capabilities,
then Lisp is for you. Check out the wiki or talk
to people at the IRC channel and see where you can
contribute...
--
http://lispm.dyndns.org/
MishoM wrote:
> Of course there is a reduced version of this agenda, which is to use
> existing software project sites like Sourceforge and implement the
> most popular libraries there in Lisp and post them on Sourceforge.
Such a collection already exists. See http://www.cl-user.net/
What would be useful is to have more maintainers for this - i.e., people
who go through the existing entries and check whether there is missing
information and/or information that needs to be updated, as well as, of
course, making new entries.
Volunteers are highly welcomed.
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/
MishoM <···············@gmail.com> writes:
> Hi,
>
> I'm really new to Lisp. I had heard of it before and got the
> impression of a dead language with an exotic syntax and no real use.
> My opinion was changed by Paul Graham's article <a href = "http://
> www.paulgraham.com/avg.html">Beating the averages</a>.
>
> I started investigating and in the last weeks I've been watching the
> videos of "Structure and Interpretation of Computer Programs" and I'm
> reading "Practical Common Lisp". I liked a lot what I heard and read
> and tried to tell my friends and colleagues about it, but the reaction
> was like I'm going nuts, even though I made it clear that I intend to
> learn more and try to implement a nontrivial program in Common Lisp
> before forming my final opinion. The most frequent argument I heard
> was: "If Lisp was that good, it would be much more popular".
How much caviar did you eat this year? Last year?
How much caviar did you friend eat recently?
I heard that caviar was eaten a lot 90 years ago in the Tsar's court,
but if it was that good, it would be much more popular.
> So I started asking myself why isn't Lisp popular. Is it because of
> it's syntax? Is it because of the prejudice that it is slow? Or some
> other reason?
The plain truth is that lisp is rare because it is very expensive:
You need to have more than two neurons to spend on it, an some
delicacy of taste.
> 1. There are not enough libraries in Lisp. Even worse, most of the
> existing libraries are not standard. The fastest way to implement
> something is to have it already implemented for you.
Often, it has not been my experience.
The fastes way to implement something is to have good tools to
implement it yourself. This is a problem of specifications.
> 2. Most people don't see the advantages of Lisp over their programming
> language even for tasks for which Lisp is really much more suitable,
> because they don't know what can be done easily in Lisp.
Yes.
> The best way to convince people to learn Lisp is by convincing them to
> use it first and then use that to show them its advantages. I don't
> know about Scheme, but the FFI of Common Lisp seems to be good enough
> to allow for other languages to use libraries written in Lisp.
Libraries are not a problem.
It's the other way around generally: it is easier to call _foreign_
libraries from lisp. With ECL, an easily "embedded" CL
implementation, it's easy to call lisp from the foreign languages.
I heard commercial implementations make it easy to call them as DLL.
It's not really relevant: there are a lot of IPC, direct function call
is less and less relevant, given the network, distributed and
parallelized architectures.
> The other thing which is mandatory is to make rich libraries for Lisp
> which are readily available, comprehensive, free and standard. The
> best way to do this is by creating the prerequisites for the emergence
> of libraries which are de facto standard, like what boost is for C++.
Boost is just greenspunning lisp into C++ with an horrible syntax and
implementation. If you want to use C++, try Lpp instead.
Why would we want something as horrible as boost in CL when we
already have the COMMON-LISP package?
> Instead of almost 10 libraries for GUI of which people don't know
> which to choose, there should be no more than three and it should be
> immediately clear what's the use of each of them.
Instead of searching and searching until you find 10 libraries of GUI,
why don't you just stop at the first you find and write your
application?
> And the third thing which could really boost things up is some way to
> make both kinds of libraries very public so that non-lispers could
> become aware that:
>
> 1. They can benefit from Lisp without learning it through powerful
> libraries written in Lisp.
That's the whole point of lisp: you just CANNOT benefit of it without
using it! Absolutely NO library you may write in Lisp can reach the
100th of the power of Lisp, unless it is an implementation of Lisp.
The best proof is the number of Lisp libraries that have been
translated into other programming languages.
The idea is plain silly and just show that you don't know lisp yet.
Please spend a few month studying and come back to tell us what you
think of this next year...
A library is like a casted object. It may be very useful to have a
fork or a coat hanger, but this is nothing compared to efficient tools
to make the molds needed to produce these objects. Of course, you can
also make molds with inefficient tools, and it will make absolutely no
difference for the coat hanger or fork user.
Clearly, you didn't understand what "meta" in "meta programming" means.
> 2. There will benefit from investing in learning Lisp, because there
> are a lot of solutions readily available.
No, the benefit due to existing solutions is close to 0.
The benefit of Lisp comes from the process of YOU developping new
solutions to new problems. If you're doing cut-and-pasting coding,
which is no programming, then Lisp is of no use. Here is one concrete
example of the examples I mentionned above. Apple's (ex NeXT)
Interface Builder is an application that is written in Objective-C.
It allows non-programmer or dumbed-down-programmers to build user
interfaces, connecting objects that require little additionnal actual
code to make an application. There is no Lisp benefit to be seen here.
However, Interface Builder wouldn't exist if it had not been developed
by Bertrand Hulo in Lisp in the first place. Thanks to using Lisp, he
could write an Interface Builder that was hundreds of times better
than the user interface editors of that time.
> And here comes my crazy idea. All of this can be achieved through a
> web site targeted at developers in all programming languages. This
> site should be the best programming libraries directory on the
> internet, hosting libraries in any programming language.
It's wrong.
What you could do however is everytime you see something done in
foreign programming languages, mention how it's much more easier to do
in Lisp. The result will be the same, the difference is that instead
of spending hundred of time units you'd spend only one, instead of
hiring hundreds of java monkeys, you'd hire only one lisp brain.
> Of course there is a reduced version of this agenda, which is to use
> existing software project sites like Sourceforge and implement the
> most popular libraries there in Lisp and post them on Sourceforge.
And they'll say: "You've translated some lib in lisp? So what? Turing
completeness, etc".
> Well that's it, I hope I didn't annoy anybody, and sorry for the
> really long post, but I wanted to share this idea and see what others
> think.
On the other hand, Lisp has the potential of making these other
programming languages irrelevant, in that it can allow you to
aggregate enough AI to make an artificial programmer. Final customers
don't care about programming languages. They have specifications, and
they want executable code. Once we've written (in lisp) the software
that takes specifications and produces executable code, as long as
this code has less bugs and more features as code written in PHP or
C++, customers will drop these programmers and make use of our lisp
killer application.
--
__Pascal Bourguignon__
In article <··············@pbourguignon.anevia.com>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
...
> > 2. There will benefit from investing in learning Lisp, because there
> > are a lot of solutions readily available.
>
> No, the benefit due to existing solutions is close to 0.
>
> The benefit of Lisp comes from the process of YOU developping new
> solutions to new problems. If you're doing cut-and-pasting coding,
> which is no programming, then Lisp is of no use. Here is one concrete
> example of the examples I mentionned above. Apple's (ex NeXT)
>
> Interface Builder is an application that is written in Objective-C.
> It allows non-programmer or dumbed-down-programmers to build user
> interfaces, connecting objects that require little additionnal actual
> code to make an application. There is no Lisp benefit to be seen here.
>
> However, Interface Builder wouldn't exist if it had not been developed
> by Bertrand Hulo in Lisp in the first place. Thanks to using Lisp, he
> could write an Interface Builder that was hundreds of times better
> than the user interface editors of that time.
From what I read Steve Jobs got a demo of the Lisp version
of Jean-Marie Hulot's Interface Builder and hired him
the same day. The software later was also an inspiration
for Visual Age Smalltalk, I read.
For the record, here is a paper that the describes the use
of the Interface Builder of ExperCommon LISP:
Signal Constellation Design Tool: A Case study in User Interface
Synthesis
Gabriel Robins
http://www.cs.virginia.edu/~robins/papers/Signal_Constellation_Design_Tool_A_Case_Study_in_User_Interface_Synthesis.pdf
--
http://lispm.dyndns.org/
On Dec 23, 3:08 am, MishoM <···············@gmail.com> wrote:
> Hi,
>
> I'm really new to Lisp. I had heard of it before and got the
> impression of a dead language with an exotic syntax and no real use.
> My opinion was changed by Paul Graham's article <a href = "http://www.paulgraham.com/avg.html">Beating the averages</a>.
>
> I started investigating and in the last weeks I've been watching the
> videos of "Structure and Interpretation of Computer Programs" and I'm
> reading "Practical Common Lisp". I liked a lot what I heard and read
> and tried to tell my friends and colleagues about it, but the reaction
> was like I'm going nuts, even though I made it clear that I intend to
> learn more and try to implement a nontrivial program in Common Lisp
> before forming my final opinion. The most frequent argument I heard
> was: "If Lisp was that good, it would be much more popular".
>
> So I started asking myself why isn't Lisp popular.
>
> ... [whole message 1162 words]
First, realize that your post is a FAQ. It happens about once every 2
or 3 months i think since i started reading comp.lang.lisp in 1999.
Someone, typically newbie, will post elaborate thoughts about such
topic as “why lisp isn't popular”. Often, these are tech geekers who
are social science illiterate. It would be far more fruitful, for
example, if people came from social science background to comment on
the issue.
Here's a few notes of my opinion you might be interested.
-----------------------
★ I don't think Lisp will ever be popular. I thought it would
eventually, 10 years ago, but now i think never. For detail, see:
• Will Lisp Ever Be Popular?
http://xahlee.org/UnixResource_dir/writ/lisp_be_popular.html
• Proliferation of Computing Languages
http://xahlee.org/UnixResource_dir/writ/new_langs.html
----------------------
★ Judged on the language itself from a academic point of view, i think
there are 2 problems of lisp that caused it serious damage. The
irregularity in syntacx, and the “cons” as list abstraction. The
irregularity prevented lisp to grow in many directions (compared how
XML is received today). However, the syntax irregularity does not
hamper lisp's use no more than say perl's syntax hampers its use.
However, the cons problem is a serious damage, that is almost
unfixable. The cons problem is the number one almost unsurmountble
problem for lisp, in fact, it is killing lisp today amid verdant
growth of functional langs. For detail, see:
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
• My First Encounter And Impression Of Lisp
http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html
----------------------
Personally, i like lisp for basically 2 reasons:
• It is functional. Functional programing, in my opinion, is the
simplest, most versatile, easy to use and learn, paradigm. (but too
often the functional programers, esp academics, makes it 10 times more
difficult with lots of lots of opaque jargons)
• Lisp was extremely well designed with respect to its time. The
lispers, are thinkers. (however, today, lisp the lang when compared to
other langs today such as Python, Ruby, or the tens new functional
langs, i think lisp the lang is actually NOT any better. Even not
counting the cons problem, it has lots of historical baggage and
ugliness that shows)
I basically only use emacs lisp, as a practical tool. I learned some
scheme in a academic context in 1999 (having read the sicp and R4RS),
and had some thoughts about learning Common Lisp, but today, i have no
interest in these whatsoever. See also:
• Xah's Emacs Lisp Tutorial
http://xahlee.org/emacs/elisp.html
You can also find book-length tutorials on Java, Perl, Python on my
website.
Xah
∑ http://xahlee.org/
☄
On Dec 23, 5:30 pm, Xah Lee <······@gmail.com> wrote:
> The irregularity prevented lisp to grow in many directions (compared how
> XML is received today).
I really do not understand what you mean by "irregularity"
It is pretty simple to implement XML in Lisp (via MOP + reader +
printer) but XML has no intrinsic computational model, i.e., you could
not "implement" Lisp in XML. I say, merge the two: http://www.agentsheets.com/lisp/XMLisp/
On Dec 25, 10:23 pm, game_designer <··············@gmail.com> wrote:
> On Dec 23, 5:30 pm,XahLee<······@gmail.com> wrote:
>
> > The irregularity prevented lisp to grow in many directions (compared how
> > XML is received today).
>
> I really do not understand what you mean by "irregularity"
>
> It is pretty simple to implement XML in Lisp (via MOP + reader +
> printer) but XML has no intrinsic computational model, i.e., you could
> not "implement" Lisp in XML.
spend at least 1 hour reading this article:
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
this means subsequent articles or wikipedia articles or spend time to
think about it. Go over parts you thought its not clear. You'll
understand.
Xah
∑ http://xahlee.org/
☄
On Dec 23, 3:08 am, MishoM <···············@gmail.com> wrote:
> Hi,
>
> I'm really new to Lisp. I had heard of it before and got the
> impression of a dead language with an exotic syntax and no real use.
> My opinion was changed by Paul Graham's article Beating the averages.
Thanks for your proposal. It's clear you put a lot of time into the
write-up. I hope the responses that were - shall we say - not so
polite - don't turn you off from Lisp.
It's interesting that you find the number of Lisp libraries lacking.
Wanting to do some web programming, I experience the opposite: an
overwhelming number of selections and "the paradox of choice." Your
other point - that there's no de-facto "standard" set of libraries - I
agree with whole-heartedly. I like the batteries being included.
I think the network effect helps us all, and I applaud your desire to
help realize that. Trust that the barriers you encounter will be
encountered by others, and do what you can to tear them down. By
leaving a trail of breadcrumbs (so to speak) you'll help those who
follow you.
Riffing on your initial ideas, I'd love to see a cohesive set of
"batteries included" Lisp libraries. Even the products of an attempt
- e.g. write-ups of comparisons of similar libraries, or just
additional information posted to http://www.cl-user.net/ or http://cliki.net/
- would be invaluable.
Walter
On Dec 23, 4:53 pm, I wrote:
> Trust that the barriers you encounter will be encountered by
> others, and do what you can to tear them down. By leaving a
> trail of breadcrumbs (so to speak) you'll help those who
> follow you.
Or to put it more pithily:
You don't need to save Lisp to save one Lisp programmer.
(And if that programmer saves another...)
Walter
Hi!
My plan was:
1. Fix packaging/deployment uglities (asdf, asdf-install). It looks
like I've made some progress and I see no problems in the future to
finish it.
2. Maybe some GC-related extensions (mapping all live objects, but it
can be hard).
3. Reader extensions and fixes: associate readmacros with symbols, not
only to characters. Making possible to have multiple assignments of
e.g. #\[ readmacro at the same time and a way to switch them easily.
Fix package system design (there are several ways to do so, but I
think see-packages macro is one of the solutions). Make hierarchical
packages portable. Allow for direct embedding of other language source
templates into lisp, e.g. direct JS and HTML/XML quasiquoting for Web,
SQL quasiquoting.
4. Reviving lispdebug and integrating it into SLIME.
5. Maybe lighter OO system. CLOS is too flexible so it compromises
performance. But I'm afraid it is too late...
6. Making lisp distributions analogous to linux distributions, so that
they would install at one click and would be self-consistent.
These are internal problems/development directions of CL itself. Some
of them are obstacles for lisp to be more popular. Some are the ways
for lisp to be more attractive.
budden wrote:
> Hi!
> My plan was:
> 1. Fix packaging/deployment uglities (asdf, asdf-install). It looks
> like I've made some progress and I see no problems in the future to
> finish it.
Damn, two saviors in one year!
> 2. Maybe some GC-related extensions (mapping all live objects, but it
> can be hard).
Rarely needed, easily done by the app if it needs it.
> 3. Reader extensions and fixes: associate readmacros with symbols, not
> only to characters. Making possible to have multiple assignments of
> e.g. #\[ readmacro at the same time and a way to switch them easily.
> Fix package system design (there are several ways to do so, but I
> think see-packages macro is one of the solutions). Make hierarchical
> packages portable. Allow for direct embedding of other language source
> templates into lisp, e.g. direct JS and HTML/XML quasiquoting for Web,
> SQL quasiquoting.
That would be an emacs, thing, no?
> 4. Reviving lispdebug and integrating it into SLIME.
> 5. Maybe lighter OO system. CLOS is too flexible so it compromises
> performance. But I'm afraid it is too late...
Hey, what happened to savior-mode? Do a dynamic graph thingy, lighter
weight and more flexible.
> 6. Making lisp distributions analogous to linux distributions, so that
> they would install at one click and would be self-consistent.
>
> These are internal problems/development directions of CL itself. Some
> of them are obstacles for lisp to be more popular. Some are the ways
> for lisp to be more attractive.
Yeah, and I stopped dating Anna Kournikova because she lived on the
sixth floor of a walk-up.
hth,kenneth
I just looked at the new language Ioke. Ioke has some features of
Lisp, ruby and javascript. For lispers it can be a trivial language
(Lisp has more features and macros ...), but this language look for a
market, to be popular.
Just my two cents.
> Damn, two saviors in one year!
Have you read apocalypse?
> > GC
> Rarely needed, easily done by the app if it needs it.
Is there a way for app to walk data in closures and on the stack?
> > 3. Reader extensions and fixes: associate readmacros with symbols, not
> That would be an emacs, thing, no?
What do you mean? I took a look at parenscript and found that CL
sucks:
JS allows 'string' and "string", lisp allows "string" only.
Hence, quasiquoting JS from CL is non-sence. Quasiquoting CL from JS
looks a bit
better :) So, for _pragmatic_ web-apps JS/HTML embedding would be
useful. Lisp-mode
dies hard and this is the main issue.
> Hey, what happened to savior-mode? Do a dynamic graph thingy, lighter
> weight and more flexible.
What do you mean?
budden <···········@mail.ru> writes:
> Hi!
> My plan was:
It's good to have a plan.
> 1. Fix packaging/deployment uglities (asdf, asdf-install). It looks
> like I've made some progress and I see no problems in the future to
> finish it.
I'm wondering. It looks like users of commercial implementations
don't have any problem with "libraries", "packaging" and "deployment".
Why would that be? Do commercial implementations come with batteries
included?
> 2. Maybe some GC-related extensions (mapping all live objects, but it
> can be hard).
What impact can that have on the popularity of lisp? From the point
of view of non lisp programmers/
> 3. Reader extensions and fixes: associate readmacros with symbols, not
> only to characters. Making possible to have multiple assignments of
> e.g. #\[ readmacro at the same time and a way to switch them easily.
Is that a language change?
> Fix package system design (there are several ways to do so, but I
> think see-packages macro is one of the solutions). Make hierarchical
> packages portable. Allow for direct embedding of other language source
> templates into lisp, e.g. direct JS and HTML/XML quasiquoting for Web,
> SQL quasiquoting.
This is language change.
> 4. Reviving lispdebug and integrating it into SLIME.
Debugging tools are good. What about "debugging in time"? (check
google's video).
> 5. Maybe lighter OO system. CLOS is too flexible so it compromises
> performance. But I'm afraid it is too late...
YALC.
> 6. Making lisp distributions analogous to linux distributions, so that
> they would install at one click and would be self-consistent.
Yes, this cannot be bad. I view commercial implementations as
distributions. We already have a couple of distributions:
- Lisp in a Box
- Lispbox
and IIRC, recently somebody posted on cll something about some
distribution or package set, but I can't find it right now.
> These are internal problems/development directions of CL itself. Some
> of them are obstacles for lisp to be more popular. Some are the ways
> for lisp to be more attractive.
--
__Pascal Bourguignon__
Hi All,
in support of "go out and program" let me start with a shameless plug.
These are all Lisp applications:
* first visual programming language with Java bytecode compiler
* first Visual language for Lego Mindstorm prototype
* Web 2.0 style ability to share agents (in 1995)
...
http://video.google.com/videoplay?docid=-1481380128543299977&hl=en
One word if you are really concerned with the popularity of Lisp or
programming in general: EDUCATION
At the middle school level we are doing pretty well now. AgentSheets,
a program for video game and simulation design, is the first tool to
be used district wide by middle school kids in the USA.A new, large
scale, project is just about to start: http://scalablegamedesign.cs.colorado.edu/wiki/Publications
I have to share some videos of that experience as well. You have to
see it to believe it. Every kid takes a REQUIRED course on game
design. AgentSheets (the Lisp and Java version) produce Lisp
representation of the game which then gets compiled natively (Lisp) or
into Java bytecodes (Java).
Then, at the University level things start to look much worse for
Lisp. The "Programming languages with Lisp in week" courses work quite
well to teach students to never touch Lisp ever again. Students do not
usually care about any specific language attribute. Syntax, yes, that
could be an issue but really the big turn off is that students do not
see any kind of application that THEY could use the language for. And
the curb appeal of Lisp is rather low compared to all the free tools
students get including: MS XNA (to make game that can run on your
Xbox), or Eclipse.
In contrast, we have been teaching game design courses using OpenGL
and Lisp quite successfully. The point at which students change their
mind is if they see me change the running code and notice the
immediate feedback. Wow, how did you do this? Well, this is Lisp...
Now you get their interest. But is it fast enough? So, far CL still
has a speed advantage to scripting language such as Ruby and Python
but JavaScript on Chrome can already approximate and in some cases
even outperform some compiled Lisp code.
As an educator I would like to continue using Lisp in graphics courses
but I need a Lisp with
- better curb appeal: think XNA not Emacs SLIME
- instant usability: download Lisp and 5 minutes later have a working
hello world OpenGL NEHE demo
- Mac and Win support including GUI builder
- no cost..
Alex
Hallo Pascal
Sorry, I'm short in time.
> It looks like users of commercial implementations don't have any problem with "libraries", "packaging" and "deployment".
Yeah, until they trying to use open-source libraries (remember Kenny's
asdf tutorial).
> What impact can that have on the popularity of lisp? From the point of view of non lisp programmers
It is just "bell or whistle". C coders can't do that. I don't know
about Java coders. It is just one more mark in comparison table which
is in favor of lisp.
> Is that a language change?
All what you say is a language change I view as a language extension.
Lisp is extensible, right? I believe CL standard have several flaws,
and I'm not going to discuss my sanity anymore :) Take it as my
religion dogma. To make lisp more popular, they need to be fixed. I
don't suggest to change lisp, but I'd prefer to extend it and use some
standad features of CL for compatibility only. Reader fix will not be
a change, but "partial metacircular closure" and it (hopefully) will
be completely portable. You have implemented the reader so you know
that it is not too hard and can be rather smooth.
> What about "debugging in time"? (check google's video).
Which one? lispdebug is able to undo program execution (at least, to
some extent). In fact, I don't think it is strictly necessary, but it
is very attractive to newbies. Now it is called http://www.cliki.net/Jabberwocky
, but it is in a suspended state.
I have created a Scheme programming environment suitable for
practical, real-world programming. It was done as a personal
programming tool. It might be of interest to someone here as well!
Check it out at: http://spark-scheme.wikispot.org/Front_Page
-- Vijay
Vijay Mathew wrote:
> I have created a Scheme programming environment suitable for
> practical, real-world programming. It was done as a personal
> programming tool. It might be of interest to someone here as well!
> Check it out at: http://spark-scheme.wikispot.org/Front_Page
What are its differentiating features?
- Daniel
On Dec 30, 10:23 am, D Herring <········@at.tentpost.dot.com> wrote:
> Vijay Mathew wrote:
> > I have created a Scheme programming environment suitable for
> > practical, real-world programming. It was done as a personal
> > programming tool. It might be of interest to someone here as well!
> > Check it out at:http://spark-scheme.wikispot.org/Front_Page
>
> What are its differentiating features?
>
> - Daniel
The biggest differentiating feature is it's rich collection of
libraries - data structures, database support (SQLite and ODBC),
networking, GUI, web server scripting etc, etc. You can find more
information at: http://spark-scheme.wikispot.org/Documentation. Some
of the libraries are incomplete. Usually, I add a library or language
feature when I have a need for one. Note that Spark is my personal
programming system.
-- Vijay
budden <···········@mail.ru> wrote:
+---------------
| 3. Reader extensions and fixes: associate readmacros with symbols, not
| only to characters. Making possible to have multiple assignments of
| e.g. #\[ readmacro at the same time and a way to switch them easily.
+---------------
Already there: You can use the "integer infix parameter" argument
of a dispatching macro character reader macro function, see CLHS
"2.1.4.4 Macro Characters" to completely change the meaning, if
you like. That is, #[...] can be totally different from #0[...],
which can be totally different from #1[...]. You could even have
the forms with supplied integer parameters set a global default
which is used by any later forms without one, so that:
#0[...] #[...] #[...] #1[...] #[...] #[...]
would mean the same as:
#0[...] #0[...] #0[...] #1[...] #1[...] #1[...]
I would not suggest doing that, though, since that would make #[...] be
"globally moded" in a way that can be very hard to read & debug later.
If you don't want to use dispatching macro characters, then you
can pull the same trick with plain macro characters, by inventing
a magic "default-switching" syntax different from any of your other
uses. E.g., if "[" is your macro character then you could easily
write [horribly confusing] stuff like this:
(defun foo (who when base)
[##SQL]
(let* (name
date
(row [select name, date from comments
where name = '$who' and date < '$when'
limit 1]))
[##PERL]
(values name [$date - $base])))
I would not suggest trying to use anything as confusing as that
for real... but one *could*...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
> Already there: You can use the "integer infix parameter" argument
Maybe, but integers look a bit hakish here. I though of something
like:
#wsql[ select name from comments into :name] (
(list #wperl[ $foo ] name) ; name is bound here with SQL embedding
)
here we use only one dispatch macro character #w which says "read a
symbol and
call its symbol-readmacro". So we have symbol-readmacros for :sql
[ and :perl[ .
It is just a bit unfair - we need extra space to separate dispatching
symbol.
> [##SQL]
I dislike it (as you do), it is anti-lispy.
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gj2kuq$aq9$1@opal.icpnet.pl>
thus spoke budden <···········@mail.ru>:
>> Already there: You can use the "integer infix parameter" argument
> Maybe, but integers look a bit hakish here. I though of something
> like:
> #wsql[ select name from comments into :name] (
> (list #wperl[ $foo ] name) ; name is bound here with SQL embedding
> It is just a bit unfair - we need extra space to separate dispatching
> symbol.
And why is that? Bind #\[ to read-delimited list and #\] to
(get-macro-character #\)) and it should Just Work.
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
IMHO...
Lisp is not popular because of the s-exp syntax. Many people
are thrown right away when looking at it. But without the s-exp
syntax its not Lisp. But its the s-exp syntax that attracted
me to learn Lisp.
Its not the libraries (lack or not lack), it has absolutely
nothing to do with that.
Programming languages are not popular in general. Non-programmers
do not like any programs. Programmers do not like other programmers
programs. Many people do not even like the programs they write
themselves. Its just what it is.
Learn to be unpopular, it is freeing.
Wade
On Dec 24, 4:27 pm, Wade <·············@gmail.com> wrote:
> IMHO...
>
> Lisp is not popular because of the s-exp syntax. Many people
> are thrown right away when looking at it. [snip]
>
> Its not the libraries (lack or not lack), it has absolutely
> nothing to do with that.
It's more complicated than that.
The s-expressions-as-why-Lisp-isn't-popular argument is the ol'
standard. Without s-expressions, Lisp wouldn't be Lisp. We can then
blame the lack of popularity on programmers not liking an _inherent_
characteristic of Lisp, rather than something we can remedy.
> Its not the libraries (lack or not lack), it has absolutely
> nothing to do with that.
The original poster specifically said that's one of his problems with
Lisp. Ergo, it does have something to do with that.
For adoption of any language, it's all about barrier to entry vs.
perceived expected future benefit. Obviously for some, s-expressions
*are* a barrier to entry. If they don't adopt Lisp, we have the
choice to blame it on an inherent characteristic of the language, or
the possibility that we haven't articulated the benefits in a
convincing enough way. Have you seen a well-written, fairly brief
explanation of the benefits of s-expressions and why they let you do
things that are impossible in other languages? I haven't.
For others, the s-expressions are no problem. Their barriers are
something else: libraries as mentioned previously, the number of
different Lisp implementations, that Emacs is nearly required to do
serious Lisp programming on free implementations, asdf on Windows...
the list goes on. These barriers *exist*. But it is easy to blame it
all on the parenthesis.
(Didn't want to break up the paragraph with a footnote: I'm aware of
Cusp etc. and absolutely applaud their efforts.)
To speak from personal experience: I wanted to do a little web
programming with Hunchentoot. I realized that it would be easier to
switch to *nix than to do it in Windows. And I did. I'm learning a
*different operating system* to do what I want in Lisp. How many
budding Lisp programmers would do that?
Walter
On Dec 24, 6:58 pm, WalterGR <········@gmail.com> wrote:
> > Its not the libraries (lack or not lack), it has absolutely
> > nothing to do with that.
>
> The original poster specifically said that's one of his problems with
> Lisp. Ergo, it does have something to do with that.
>
Then perhaps the original poster can name ONE (as in 1) specific
library that is missing that he needs.
Wade
Wade wrote:
> On Dec 24, 6:58 pm, WalterGR <········@gmail.com> wrote:
>> > Its not the libraries (lack or not lack), it has absolutely
>> > nothing to do with that.
>>
>> The original poster specifically said that's one of his problems with
>> Lisp. Ergo, it does have something to do with that.
>
> Then perhaps the original poster can name ONE (as in 1) specific
> library that is missing that he needs.
Are there any mature OpenGL 2 or OpenGL 3 bindings for any Lisp? The last
time I looked, there was many awful bindings that only covered OpenGL 1 and
I could not even get them to work.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Jan 5, 7:53 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Wade wrote:
> > On Dec 24, 6:58 pm, WalterGR <········@gmail.com> wrote:
> >> > Its not the libraries (lack or not lack), it has absolutely
> >> > nothing to do with that.
>
> >> The original poster specifically said that's one of his problems with
> >> Lisp. Ergo, it does have something to do with that.
>
> > Then perhaps the original poster can name ONE (as in 1) specific
> > library that is missing that he needs.
>
> Are there any mature OpenGL 2 or OpenGL 3 bindings for any Lisp? The last
> time I looked, there was many awful bindings that only covered OpenGL 1 and
> I could not even get them to work.
OpenGL 2:
http://www.cliki.net/cl-glfw
http://www.cliki.net/cl-opengl
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
········@gmail.com wrote:
> On Jan 5, 7:53 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Wade wrote:
>> > On Dec 24, 6:58 pm, WalterGR <········@gmail.com> wrote:
>> >> > Its not the libraries (lack or not lack), it has absolutely
>> >> > nothing to do with that.
>>
>> >> The original poster specifically said that's one of his problems with
>> >> Lisp. Ergo, it does have something to do with that.
>>
>> > Then perhaps the original poster can name ONE (as in 1) specific
>> > library that is missing that he needs.
>>
>> Are there any mature OpenGL 2 or OpenGL 3 bindings for any Lisp? The last
>> time I looked, there was many awful bindings that only covered OpenGL 1
>> and I could not even get them to work.
>
> OpenGL 2:
>
> http://www.cliki.net/cl-glfw
> http://www.cliki.net/cl-opengl
Are they mature?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> ········@gmail.com wrote:
>> On Jan 5, 7:53 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>>> Wade wrote:
>>>> On Dec 24, 6:58 pm, WalterGR <········@gmail.com> wrote:
>>>>>> Its not the libraries (lack or not lack), it has absolutely
>>>>>> nothing to do with that.
>>>>> The original poster specifically said that's one of his problems with
>>>>> Lisp. Ergo, it does have something to do with that.
>>>> Then perhaps the original poster can name ONE (as in 1) specific
>>>> library that is missing that he needs.
>>> Are there any mature OpenGL 2 or OpenGL 3 bindings for any Lisp? The last
>>> time I looked, there was many awful bindings that only covered OpenGL 1
>>> and I could not even get them to work.
>> OpenGL 2:
>>
>> http://www.cliki.net/cl-glfw
>> http://www.cliki.net/cl-opengl
>
> Are they mature?
>
Mature is only in the eye of the beholder...
That aside, there can't be any mature OpenGL library, simply because
there are too many extensions, that you might have to check runtime.
LispWorks OpenGL bindings works just fine.
LispBuilder one too.
Dimiter "malkia" Stanev wrote:
> Jon Harrop wrote:
>> ········@gmail.com wrote:
>>> On Jan 5, 7:53 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>>>> Wade wrote:
>>>>> On Dec 24, 6:58 pm, WalterGR <········@gmail.com> wrote:
>>>>>>> Its not the libraries (lack or not lack), it has absolutely
>>>>>>> nothing to do with that.
>>>>>> The original poster specifically said that's one of his problems with
>>>>>> Lisp. Ergo, it does have something to do with that.
>>>>> Then perhaps the original poster can name ONE (as in 1) specific
>>>>> library that is missing that he needs.
>>>> Are there any mature OpenGL 2 or OpenGL 3 bindings for any Lisp? The
>>>> last time I looked, there was many awful bindings that only covered
>>>> OpenGL 1 and I could not even get them to work.
>>> OpenGL 2:
>>>
>>> http://www.cliki.net/cl-glfw
>>> http://www.cliki.net/cl-opengl
>>
>> Are they mature?
>
> Mature is only in the eye of the beholder...
Even in the complete absence of any working software?
> That aside, there can't be any mature OpenGL library, simply because
> there are too many extensions, that you might have to check runtime.
>
> LispWorks OpenGL bindings works just fine.
>
> LispBuilder one too.
Can you cite some software using them, to substantiate that they have had a
significant number of testers?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-01-05, Jon Harrop <···@ffconsultancy.com> wrote:
>> http://www.cliki.net/cl-glfw
>> http://www.cliki.net/cl-opengl
>
> Are they mature?
How much maturity can you cram into a function wrapper?
Kaz Kylheku wrote:
> On 2009-01-05, Jon Harrop <···@ffconsultancy.com> wrote:
>>> http://www.cliki.net/cl-glfw
>>> http://www.cliki.net/cl-opengl
>>
>> Are they mature?
>
> How much maturity can you cram into a function wrapper?
A lot. I fixed LablGL's GLU tesselator bindings with respect to the GC and
GLCaml's handling of shader programs, for example. There are many
subtleties involved in binding OpenGL and they require extensive testing
with good coverage of features to reach maturity as a consequence.
From what I can gather, these CL bindings are nowhere near mature. Only 75
people have ever posted to their mailing list and there have been no posts
for 6 weeks now:
http://common-lisp.net/pipermail/cl-opengl-devel/
They are not even packaged for any of the major Linux distros so you cannot
use popcon results. Indeed, Google indicates that only one person has ever
even discussed using the GLU tesselator from CL and it was me!
I would not consider OCaml's OpenGL bindings to be mature but at least they
have 800 installs and 45 active users according to the Debian and Ubuntu
popcon results.
Linux is bad for graphics (e.g. compared to WPF on Windows) and the open
source FPLs on Linux are even worse. I have seen some impressive graphical
programs written using OCaml under Linux but the authors always do
everything from scratch by themselves.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-01-08, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> On 2009-01-05, Jon Harrop <···@ffconsultancy.com> wrote:
>>>> http://www.cliki.net/cl-glfw
>>>> http://www.cliki.net/cl-opengl
>>>
>>> Are they mature?
>>
>> How much maturity can you cram into a function wrapper?
>
> A lot. I fixed LablGL's GLU tesselator bindings with respect to the GC and
> GLCaml's handling of shader programs, for example. There are many
If you can do it by yourself, maybe it's not that hard.
> subtleties involved in binding OpenGL and they require extensive testing
Many? How many? More than, say, ten subtleties?
For each subtlety, would it take more than a week of one developer's time to
take care of it?
> From what I can gather, these CL bindings are nowhere near mature. Only 75
> people have ever posted to their mailing list and there have been no posts
> for 6 weeks now:
That is ambiguous, because sometimes when projects are mature, the noise dies
down. It could be from lack of interest (which has nothing to do with maturity)
or lack of bugs.
> http://common-lisp.net/pipermail/cl-opengl-devel/
>
> They are not even packaged for any of the major Linux distros so you cannot
> use popcon results. Indeed, Google indicates that only one person has ever
> even discussed using the GLU tesselator from CL and it was me!
>
> I would not consider OCaml's OpenGL bindings to be mature but at least they
> have 800 installs and 45 active users according to the Debian and Ubuntu
> popcon results.
So a custom, in-house software project could never be mature, because
it has just one installation, and you can't even google for that one.
Kaz Kylheku wrote:
> On 2009-01-08, Jon Harrop <···@ffconsultancy.com> wrote:
>> Kaz Kylheku wrote:
>>> On 2009-01-05, Jon Harrop <···@ffconsultancy.com> wrote:
>>>>> http://www.cliki.net/cl-glfw
>>>>> http://www.cliki.net/cl-opengl
>>>>
>>>> Are they mature?
>>>
>>> How much maturity can you cram into a function wrapper?
>>
>> A lot. I fixed LablGL's GLU tesselator bindings with respect to the GC
>> and GLCaml's handling of shader programs, for example. There are many
>
> If you can do it by yourself, maybe it's not that hard.
I did not do it by myself.
>> subtleties involved in binding OpenGL and they require extensive testing
>
> Many? How many? More than, say, ten subtleties?
Hundreds.
> For each subtlety, would it take more than a week of one developer's time
> to take care of it?
Yes. My (incomplete) GLU tesselator bindings took 2 weeks.
>> From what I can gather, these CL bindings are nowhere near mature. Only
>> 75 people have ever posted to their mailing list and there have been no
>> posts for 6 weeks now:
>
> That is ambiguous, because sometimes when projects are mature, the noise
> dies down.
The archives show there has never been any noise about this project.
> It could be from lack of interest (which has nothing to do with
> maturity) or lack of bugs.
Or perhaps some kind of miracle.
>> I would not consider OCaml's OpenGL bindings to be mature but at least
>> they have 800 installs and 45 active users according to the Debian and
>> Ubuntu popcon results.
>
> So a custom, in-house software project could never be mature, because
> it has just one installation, and you can't even google for that one.
These are not in-house software projects.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-01-08, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> On 2009-01-08, Jon Harrop <···@ffconsultancy.com> wrote:
>>> Kaz Kylheku wrote:
>>>> On 2009-01-05, Jon Harrop <···@ffconsultancy.com> wrote:
>>>>>> http://www.cliki.net/cl-glfw
>>>>>> http://www.cliki.net/cl-opengl
>>>>>
>>>>> Are they mature?
>>>>
>>>> How much maturity can you cram into a function wrapper?
>>>
>>> A lot. I fixed LablGL's GLU tesselator bindings with respect to the GC
>>> and GLCaml's handling of shader programs, for example. There are many
>>
>> If you can do it by yourself, maybe it's not that hard.
>
> I did not do it by myself.
>
>>> subtleties involved in binding OpenGL and they require extensive testing
>>
>> Many? How many? More than, say, ten subtleties?
>
> Hundreds.
Could you even name seven such concerns? (And I don't mean the same kind of
concern repeated over each function for which a binding is made).
>> For each subtlety, would it take more than a week of one developer's time
>> to take care of it?
>
> Yes. My (incomplete) GLU tesselator bindings took 2 weeks.
So you took care of only one subtlety then? Yet, you had some working bindings.
>>> From what I can gather, these CL bindings are nowhere near mature. Only
>>> 75 people have ever posted to their mailing list and there have been no
>>> posts for 6 weeks now:
>>
>> That is ambiguous, because sometimes when projects are mature, the noise
>> dies down.
>
> The archives show there has never been any noise about this project.
That still means nothing.
Asserting some property of a software by the amount of noise some people are
making about it strongly smacks of the ad hominem fallacy.
We can easily find examples of software that generates a lot of noise, which is
quite buggy, and vice versa.
Popularity doesn't translate to maturity.
The depth of testing rests in variety, not quantity. If there are a million
users, but they are all monkeys who do almost exactly the same thing with the
software, a six member representative sample of those users will provide about
the same coverage as the full million.
(The exception would be real-time concurrent software, which has a
different order of execution each time it is run, even for apparently the same
inputs. We do gain additional confidence about its stability even from
successful repetitions of the same test cases.)
Kaz Kylheku wrote:
> On 2009-01-08, Jon Harrop <···@ffconsultancy.com> wrote:
>> Hundreds.
>
> Could you even name seven such concerns? (And I don't mean the same kind
> of concern repeated over each function for which a binding is made).
Sure:
. Static link or dynamic load the whole GL?
. Do you expose GL extensions in the target language and, if so, how?
. How do you make "void *" type safe in the GLU tesselator?
. How do you handle dynamically allocated vertices in the tesselator?
. Don't forget to enforce calling of "init" because some implementations
will segfault if you do not.
. Don't forget to handle null texture data.
. How do you handle library-allocated buffers?
. How do you handle arrays of unboxed structs if your target language does
not support value types?
. How do you handle GL errors?
. What are the implicit dependencies between library-allocated data
structures that must be taken into account in order to avoid GC bugs, e.g.
at finalization?
You can get a much longer list of subtleties by looking at the bugs filed
against various GL bindings, such as PyGL:
http://sourceforge.net/tracker/?atid=105988&group_id=5988&func=browse
>>> For each subtlety, would it take more than a week of one developer's
>>> time to take care of it?
>>
>> Yes. My (incomplete) GLU tesselator bindings took 2 weeks.
>
> So you took care of only one subtlety then? Yet, you had some working
> bindings.
Working but incomplete, yes. I basically hard-coded the common case as C
code and gave it a trivial API for OCaml to call. Other people have tried
to bind the GLU tesselator comprehensively and, as you can see, they have
had a lot of trouble.
>>>> From what I can gather, these CL bindings are nowhere near mature. Only
>>>> 75 people have ever posted to their mailing list and there have been no
>>>> posts for 6 weeks now:
>>>
>>> That is ambiguous, because sometimes when projects are mature, the noise
>>> dies down.
>>
>> The archives show there has never been any noise about this project.
>
> That still means nothing.
It means your statement is not applicable here.
> Asserting some property of a software by the amount of noise some people
> are making about it strongly smacks of the ad hominem fallacy.
You probably mean "absence of evidence is not evidence of absence" rather
than "ad hominem". If so, that applies to correctness and not to maturity.
> We can easily find examples of software that generates a lot of noise,
> which is quite buggy, and vice versa.
>
> Popularity doesn't translate to maturity.
What open source projects do you consider to be mature even though there is
no evidence that they have been used or tested to any significant degree?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Kaz Kylheku wrote:
>> On 2009-01-08, Jon Harrop <···@ffconsultancy.com> wrote:
>>> Hundreds.
>> Could you even name seven such concerns? (And I don't mean the same kind
>> of concern repeated over each function for which a binding is made).
>
> Sure:
>
> .. Static link or dynamic load the whole GL?
Off course dynamic, how otherwise else? (MESA?)
> .. Do you expose GL extensions in the target language and, if so, how?
As long as you have glGetExtensions, and some way to callback a function
with parameters (and you have that in CL with CFFI).
> .. How do you make "void *" type safe in the GLU tesselator?
What if you don't use the GLU tesselator? How many apps are using it?
It's not even safe to use such piece of machinery, and there is no need
to do so.
> .. How do you handle dynamically allocated vertices in the tesselator?
>
> .. Don't forget to enforce calling of "init" because some implementations
> will segfault if you do not.
>
> .. Don't forget to handle null texture data.
>
> .. How do you handle library-allocated buffers?
>
> .. How do you handle arrays of unboxed structs if your target language does
> not support value types?
>
> .. How do you handle GL errors?
>
> .. What are the implicit dependencies between library-allocated data
> structures that must be taken into account in order to avoid GC bugs, e.g.
> at finalization?
To all of the previous - Somehow. I don't know what's your problem? You
get the bindings, run the solution, if you run into problem - you look
for a workaround (in any language, API, etc.).
> You can get a much longer list of subtleties by looking at the bugs filed
> against various GL bindings, such as PyGL:
>
> http://sourceforge.net/tracker/?atid=105988&group_id=5988&func=browse
No need for that - you might run into some of them, you might not run
into them at all...
....
Dimiter "malkia" Stanev wrote:
> Jon Harrop wrote:
>> .. Static link or dynamic load the whole GL?
>
> Off course dynamic, how otherwise else? (MESA?)
Some bindings use dlopen (e.g. GLCaml) others do not (e.g. LablGL).
>> .. Do you expose GL extensions in the target language and, if so, how?
>
> As long as you have glGetExtensions, and some way to callback a function
> with parameters (and you have that in CL with CFFI).
So you don't bind GL extensions at all, you just leave it for the user.
>> .. How do you make "void *" type safe in the GLU tesselator?
>
> What if you don't use the GLU tesselator?
So you only aspire to write partial bindings?
> How many apps are using it?
Several that I have come across (including our own, of course). The GLU
tesselator is used for 2D vector graphics and for computing silhouettes in
some 3D shadow algorithms.
> It's not even safe to use such piece of machinery,
Complete nonsense.
> and there is no need to do so.
True but useless. Writing a numerically robust tesselator is extremely
difficult. I started along that path and gave up having read a seventh PhD
thesis on the subject.
>> .. How do you handle dynamically allocated vertices in the tesselator?
>>
>> .. Don't forget to enforce calling of "init" because some implementations
>> will segfault if you do not.
>>
>> .. Don't forget to handle null texture data.
>>
>> .. How do you handle library-allocated buffers?
>>
>> .. How do you handle arrays of unboxed structs if your target language
>> does not support value types?
>>
>> .. How do you handle GL errors?
>>
>> .. What are the implicit dependencies between library-allocated data
>> structures that must be taken into account in order to avoid GC bugs,
>> e.g. at finalization?
>
> To all of the previous - Somehow. I don't know what's your problem? You
> get the bindings, run the solution, if you run into problem - you look
> for a workaround (in any language, API, etc.).
You ditch Lisp in favor of a language with mature libraries, as everyone
else has done.
>> You can get a much longer list of subtleties by looking at the bugs filed
>> against various GL bindings, such as PyGL:
>>
>> http://sourceforge.net/tracker/?atid=105988&group_id=5988&func=browse
>
> No need for that - you might run into some of them, you might not run
> into them at all...
You almost certainly will if you try to use immature bindings like most Lisp
libraries and, when you have problems, you will be facing an unfeasible
amount of work. That problem is widespread among esoteric languages.
Anyone needing to get a competitive amount of work done cannot afford to
follow your advice, i.e. your advice is useless in the real world.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
I have been involved in Lisp, Ocaml, Squeak Smalltalk and Objective-C
projects over the past year and it seems that Lisp's biggest hurdle is
not syntax or style. A resurgence of Lisp implemenations like Clojure,
nuLisp, newLisp etc seem to suggest that there is validity to the
"code is data" approach and the syntax. For me stability has not been
a problem with Lisp libraries, but the sparse documentation can be
extremely frustrating. On the upside the people on the mailing lists
are pretty helpful.
The big obstacle seems to be this idea of an image, a virtual machine
which is 100% self-reflective and pliable at runtime. It takes quite a
while to appreciate that being able to see the values of certain
variables real-time and hot-swapping on all levels is a huge
advantage. As a practical example, if I am building a web-app writing
a real-time admin interface is *much* easier with an image-based Lisp.
Instead of constantly being lured into performance shootouts with
static, compiled binary-based languages, the Lisp community should do
more to highlight this aspect of their technology. It is the missing
chapter from "Practical Common Lisp".
-deech
On Jan 9, 10:30 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Dimiter "malkia" Stanev wrote:
> > Jon Harrop wrote:
> >> .. Static link or dynamic load the whole GL?
>
> > Off course dynamic, how otherwise else? (MESA?)
>
> Some bindings use dlopen (e.g. GLCaml) others do not (e.g. LablGL).
>
> >> .. Do you expose GL extensions in the target language and, if so, how?
>
> > As long as you have glGetExtensions, and some way to callback a function
> > with parameters (and you have that in CL with CFFI).
>
> So you don't bind GL extensions at all, you just leave it for the user.
>
> >> .. How do you make "void *" type safe in the GLU tesselator?
>
> > What if you don't use the GLU tesselator?
>
> So you only aspire to write partial bindings?
>
> > How many apps are using it?
>
> Several that I have come across (including our own, of course). The GLU
> tesselator is used for 2D vector graphics and for computing silhouettes in
> some 3D shadow algorithms.
>
> > It's not even safe to use such piece of machinery,
>
> Complete nonsense.
>
> > and there is no need to do so.
>
> True but useless. Writing a numerically robust tesselator is extremely
> difficult. I started along that path and gave up having read a seventh PhD
> thesis on the subject.
>
>
>
> >> .. How do you handle dynamically allocated vertices in the tesselator?
>
> >> .. Don't forget to enforce calling of "init" because some implementations
> >> will segfault if you do not.
>
> >> .. Don't forget to handle null texture data.
>
> >> .. How do you handle library-allocated buffers?
>
> >> .. How do you handle arrays of unboxed structs if your target language
> >> does not support value types?
>
> >> .. How do you handle GL errors?
>
> >> .. What are the implicit dependencies between library-allocated data
> >> structures that must be taken into account in order to avoid GC bugs,
> >> e.g. at finalization?
>
> > To all of the previous - Somehow. I don't know what's your problem? You
> > get the bindings, run the solution, if you run into problem - you look
> > for a workaround (in any language, API, etc.).
>
> You ditch Lisp in favor of a language with mature libraries, as everyone
> else has done.
>
> >> You can get a much longer list of subtleties by looking at the bugs filed
> >> against various GL bindings, such as PyGL:
>
> >> http://sourceforge.net/tracker/?atid=105988&group_id=5988&func=browse
>
> > No need for that - you might run into some of them, you might not run
> > into them at all...
>
> You almost certainly will if you try to use immature bindings like most Lisp
> libraries and, when you have problems, you will be facing an unfeasible
> amount of work. That problem is widespread among esoteric languages.
>
> Anyone needing to get a competitive amount of work done cannot afford to
> follow your advice, i.e. your advice is useless in the real world.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
deech wrote:
> I have been involved in Lisp, Ocaml, Squeak Smalltalk and Objective-C
> projects over the past year and it seems that Lisp's biggest hurdle is
> not syntax or style. A resurgence of Lisp implemenations like Clojure,
> nuLisp, newLisp etc seem to suggest that there is validity to the
> "code is data" approach and the syntax...
Resurgence? Clojure is the only one of significance and it is barely a blip
on the radar:
http://www.google.com/trends?q=clojure%2Cocaml%2Cf%23
If you want an example of code-is-data seeing serious use then look at
Mathematica. Not much of a Lisp and only domain specific but its by far the
best example you'll get.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop <···@ffconsultancy.com> writes:
> If you want an example of code-is-data seeing serious use then look at
> Mathematica. Not much of a Lisp and only domain specific but its by far the
> best example you'll get.
I'd bet that:
- Common Lisp has more programmers than Mathematica.
- Common Lisp has more deployed applications than Mathematica.
- Common Lisp has more paying users in the end than Mathematica.
For one thing, there's only one commercial Mathematica implementation
vendor, while there are at least three major commercial Common Lisp
implementation vendors.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> If you want an example of code-is-data seeing serious use then look at
>> Mathematica. Not much of a Lisp and only domain specific but its by far
>> the best example you'll get.
>
> I'd bet that:
> - Common Lisp has more programmers than Mathematica.
Mathematica had a million users by 1999 and now has several million. Even
free Lisp implementations have only a few thousand users. I very much doubt
all commercial Lisps combined have 10,000 users.
> - Common Lisp has more deployed applications than Mathematica.
Yes. Mathematica is built as a single monolithic solution for technical
computing. Wolfram Research pull in as much functionality as possible and
leverage that to sell copies. So the number of "deployed applications" is
tiny: Mathematica is built specifically for writing many small disposable
programs (which is typical in technical computing) and not deployable
applications.
> - Common Lisp has more paying users in the end than Mathematica.
The largest number of Mathematica copies sold will be the $45 student
edition. I doubt any commercial Lisp can compete in terms of units sold.
However, in the absence of figures the nearest metric is the size of the
companies and Wolfram Research dwarfs all of the commercial Lisp vendors.
> For one thing, there's only one commercial Mathematica implementation
> vendor, while there are at least three major commercial Common Lisp
> implementation vendors.
Wolfram Research have hundreds of employees and the founder is now a
billionaire thanks to sales of Mathematica.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
P� Sun, 11 Jan 2009 06:21:27 +0100, skrev Jon Harrop
<···@ffconsultancy.com>:
>
> Mathematica had a million users by 1999 and now has several million. Even
> free Lisp implementations have only a few thousand users. I very much
> doubt
> all commercial Lisps combined have 10,000 users.
>
There are about 30 000 professional Lisp programmes world wide and about
100 000 that use Lisp.
This is far less than the 4 million copies sold of Mathematica but still
an order of magitude more than you seem to suggest.
--------------
John Thingstad
John Thingstad wrote:
> På Sun, 11 Jan 2009 06:21:27 +0100, skrev Jon Harrop
> <···@ffconsultancy.com>:
>>
>> Mathematica had a million users by 1999 and now has several million. Even
>> free Lisp implementations have only a few thousand users. I very much
>> doubt all commercial Lisps combined have 10,000 users.
>
> There are about 30 000 professional Lisp programmes world wide and about
> 100 000 that use Lisp.
No way.
Market share by programming language:
USA (from dice.com):
Lisp: 0.06%
C#: 15%
UK (from itjobswatch.co.uk):
Lisp: 0.017%
C#: 30%
France (from monster.fr):
Lisp: 1 job
C#: 1,219 jobs
Assuming 3M C# developers, those equate 13,000 or 1,700 or 2,500
professional Lisp programmers worldwide. However, Lisp is unusually popular
in the USA and Germany so the true figure is certainly much less than
13,000 professional Lisp programmers.
These figures are similar to other sources, such as the book market where
Lisp has 0.09% market share:
http://radar.oreilly.com/archives/2008/03/state-of-the-computer-book-mar-23.html
So there are nowhere near 100,000 Lisp programmers in reality.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gkdonm$ce6$1@news.motzarella.org>
Jon Harrop schrieb:
> John Thingstad wrote:
>> På Sun, 11 Jan 2009 06:21:27 +0100, skrev Jon Harrop
>> <···@ffconsultancy.com>:
>>> Mathematica had a million users by 1999 and now has several million. Even
>>> free Lisp implementations have only a few thousand users. I very much
>>> doubt all commercial Lisps combined have 10,000 users.
>> There are about 30 000 professional Lisp programmes world wide and about
>> 100 000 that use Lisp.
>
> No way.
>
> Market share by programming language:
>
> USA (from dice.com):
> Lisp: 0.06%
> C#: 15%
>
> UK (from itjobswatch.co.uk):
> Lisp: 0.017%
> C#: 30%
>
> France (from monster.fr):
> Lisp: 1 job
> C#: 1,219 jobs
>
> Assuming 3M C# developers, those equate 13,000 or 1,700 or 2,500
> professional Lisp programmers worldwide. However, Lisp is unusually popular
> in the USA and Germany so the true figure is certainly much less than
> 13,000 professional Lisp programmers.
>
> These figures are similar to other sources, such as the book market where
> Lisp has 0.09% market share:
>
> http://radar.oreilly.com/archives/2008/03/state-of-the-computer-book-mar-23.html
>
> So there are nowhere near 100,000 Lisp programmers in reality.
I also think that your 10k is more realistic.
There are probably 100k people who know Lisp pretty well, but they are
not professional devs and they don’t pay thousands of dollars for
commercial Lisps when they can have SBCL for free.
The vendors might still be able to survive for some time though. They
dominate their niche pretty well, and there seem to be enough projects
out there to continue like that for a while.
Although I don’t see a chance that they can grow.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
André Thieme wrote:
> I also think that your 10k is more realistic.
> There are probably 100k people who know Lisp pretty well, but they are
> not professional devs and they don’t pay thousands of dollars for
> commercial Lisps when they can have SBCL for free.
Yes. In particular, many students are taught Lisp. However, one could argue
that they do not even constitute Lisp users unless they continue to use
Lisp.
> The vendors might still be able to survive for some time though. They
> dominate their niche pretty well, and there seem to be enough projects
> out there to continue like that for a while.
> Although I don’t see a chance that they can grow.
Yes. I think commercial Lisp vendors should just about be able to sustain
themselves but it will not be easy and I also cannot see them growing. To
be honest, I'm surprised anyone can earn a living by selling a language
implementation when there are so many great language implementations
available for free.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Jan 11, 3:59 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> André Thieme wrote:
> > I also think that your 10k is more realistic.
> > There are probably 100k people who know Lisp pretty well, but they are
> > not professional devs and they don’t pay thousands of dollars for
> > commercial Lisps when they can have SBCL for free.
>
> Yes. In particular, many students are taught Lisp. However, one could argue
> that they do not even constitute Lisp users unless they continue to use
> Lisp.
>
> > The vendors might still be able to survive for some time though. They
> > dominate their niche pretty well, and there seem to be enough projects
> > out there to continue like that for a while.
> > Although I don’t see a chance that they can grow.
>
> Yes. I think commercial Lisp vendors should just about be able to sustain
> themselves but it will not be easy and I also cannot see them growing. To
> be honest, I'm surprised anyone can earn a living by selling a language
> implementation when there are so many great language implementations
> available for free.
There must be something commercial vendors supply that customers don't
get with free lisps.
Duane
·····@franz.com wrote:
> On Jan 11, 3:59 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Andr� Thieme wrote:
>>> I also think that your 10k is more realistic.
>>> There are probably 100k people who know Lisp pretty well, but they are
>>> not professional devs and they don�t pay thousands of dollars for
>>> commercial Lisps when they can have SBCL for free.
>> Yes. In particular, many students are taught Lisp. However, one could argue
>> that they do not even constitute Lisp users unless they continue to use
>> Lisp.
>>
>>> The vendors might still be able to survive for some time though. They
>>> dominate their niche pretty well, and there seem to be enough projects
>>> out there to continue like that for a while.
>>> Although I don�t see a chance that they can grow.
>> Yes. I think commercial Lisp vendors should just about be able to sustain
>> themselves but it will not be easy and I also cannot see them growing. To
>> be honest, I'm surprised anyone can earn a living by selling a language
>> implementation when there are so many great language implementations
>> available for free.
>
> There must be something commercial vendors supply that customers don't
> get with free lisps.
And I wager the good news is that the bigger the customer the more
likely they will be (to be cynical) to want the warm fuzzy* of vendor
support and (to be optimistic) to have at least one person in the
enterprise figure out that it ain't free if one has five people (or even
one) working on something the vendor offers.
I am still having great luck with qooxdoo, but a lot of hours are going
into digging around incomplete and poorly indexed doc (thk g*d for open
source) and putting up queries on the mailing list no one answers, or
answers so-so. Nor do I see the 24-48 hr turnaround on bug fixes a
certain Lisp vendor usually provides.
kth
* Or even better, a written SLA. k
Kenneth Tilton wrote:
>
> And I wager the good news is that the bigger the customer the more
> likely they will be (to be cynical) to want the warm fuzzy* of vendor
> support
It's not just "warm fuzzy". At ITA, we're what you'd call a
big customer of Lisp. I work very closely with our Lisp
vendor (Clozure), who provide valuable support. Their
turnaround time is excellent. The developers there are
extremely sharp and do a great job.
(I'm not trying to impugn other vendors. Quite the contrary:
the other maintainers of Common Lisp implementations
are generally extremely impressive!)
And due to the miracle of open source software, all
of you out there will benefit from all these little
improvements and fixes.
Full disclosure:
a few of them are old friends of mine from MIT,
and many of the rest have become personal friends since
I've been working with them. But all of the above is
quite true.
·····@franz.com wrote:
> There must be something commercial vendors supply that customers don't
> get with free lisps.
Support, a decent IDE, libraries that actually work, usable Windows support
and many other things I imagine.
That does not make it a good business model though. I am considering
something similar, building a HLVM on top of LLVM. I would also like to
earn money from the project but doing that by keeping it closed source and
trying to sell it seems like the worst option to me. Open sourcing the
platform, making it commerce friendly and selling documentation (e.g.
books, journals) and libraries built upon it seems like a much more viable
business model. The key is to get third parties building on your platform.
That is what MATLAB did and Mathematica did not and is the reason why far
more people use MATLAB than Mathematica. Microsoft use a similar model by
giving away fundamental tools like F# for free in order to grow their
platform.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 12 Jan., 20:32, Jon Harrop <····@ffconsultancy.com> wrote:
> ·····@franz.com wrote:
> > There must be something commercial vendors supply that customers don't
> > get with free lisps.
>
> Support, a decent IDE, libraries that actually work, usable Windows support
> and many other things I imagine.
Franz also provides customers with a lot of source code of Allegro CL.
http://www.franz.com/support/documentation/8.1/doc/installation.htm#source-install-1
I wish LispWorks (my favorite Lisp implementation) had that...
>
> That does not make it a good business model though. I am considering
> something similar, building a HLVM on top of LLVM. I would also like to
> earn money from the project but doing that by keeping it closed source and
> trying to sell it seems like the worst option to me. Open sourcing the
> platform, making it commerce friendly and selling documentation (e.g.
> books, journals) and libraries built upon it seems like a much more viable
> business model. The key is to get third parties building on your platform.
>
> That is what MATLAB did and Mathematica did not and is the reason why far
> more people use MATLAB than Mathematica. Microsoft use a similar model by
> giving away fundamental tools like F# for free in order to grow their
> platform.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
Jon Harrop schrieb:
> ·····@franz.com wrote:
>> There must be something commercial vendors supply that customers don't
>> get with free lisps.
>
> Support, a decent IDE, libraries that actually work, usable Windows support
> and many other things I imagine.
>
> That does not make it a good business model though. I am considering
> something similar, building a HLVM on top of LLVM. I would also like to
> earn money from the project but doing that by keeping it closed source and
> trying to sell it seems like the worst option to me. Open sourcing the
> platform, making it commerce friendly and selling documentation (e.g.
> books, journals) and libraries built upon it seems like a much more viable
> business model. The key is to get third parties building on your platform.
I can agree with you if you think about starting a project today.
But let�s remember that the Lisp vendors grew into their markets. They
started to build their IDEs at very different times. It was when several
people heared about this �Internet� thing. Some rich guys had mobile...
well, one could call them phones, although cabin was what they looked like.
At those times the markets were different, Lisp machines existed and not
everyone knew they would be dead by the year 2000, and so on.
So, from that perspective I can understand the business models of the
vendors.
The are masters of their niches.. no one will try to get into that
market, so no new competition. And they have each some hundred paying
customers for years to come which will guarantee survival.
A pretty stable niche I would say.
But I honestly don�t see a chance how they could grow.
Maybe one of them decides to build a new IDE for Clojure. That could
perhaps make sense. There is no such IDE now, and in the long run more
and more Lispers will switch over to Clojure and other people are also
moving into that direction.
But currently there is no real IDE.
Just editors with code colorization and indentation.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On 12 Jan., 23:24, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Jon Harrop schrieb:
>
> > ·····@franz.com wrote:
> >> There must be something commercial vendors supply that customers don't
> >> get with free lisps.
>
> > Support, a decent IDE, libraries that actually work, usable Windows support
> > and many other things I imagine.
>
> > That does not make it a good business model though. I am considering
> > something similar, building a HLVM on top of LLVM. I would also like to
> > earn money from the project but doing that by keeping it closed source and
> > trying to sell it seems like the worst option to me. Open sourcing the
> > platform, making it commerce friendly and selling documentation (e.g.
> > books, journals) and libraries built upon it seems like a much more viable
> > business model. The key is to get third parties building on your platform.
>
> I can agree with you if you think about starting a project today.
> But let’s remember that the Lisp vendors grew into their markets. They
> started to build their IDEs at very different times. It was when several
> people heared about this “Internet” thing. Some rich guys had mobile...
The Lisp guys were among the first to hear about that 'Internet'
thing.
symbolics.com was the first .com domain. Some of the early protocols
even were developed in Lisp, like imap, wais, ....
> well, one could call them phones, although cabin was what they looked like.
> At those times the markets were different, Lisp machines existed and not
> everyone knew they would be dead by the year 2000,
No? I thought that was pretty much clear in 1990 when they already
were out of business
(LMI, TI, Xerox) or scaled down (Symbolics). In 1990 the market was
already
collapsed. The AI Winter started in 1987.
>and so on.
Corman Lisp for Windows was developed in the early 90s.
Scieneer Common Lisp was released in 2002.
I would also think of Clozure Associates as kind of a vendor.
'Clozure Associates develops, hosts, and maintains Clozure CL (aka
CCL)'
Clozure CL was open sourced in 2001. Recently they got funding
from users to improve the IDE.
> So, from that perspective I can understand the business models of the
> vendors.
> The are masters of their niches.. no one will try to get into that
> market, so no new competition.
See above.
> And they have each some hundred paying
> customers for years to come which will guarantee survival.
> A pretty stable niche I would say.
I don't know how stable the niche is. But I see that Franz and
LispWorks
are still improving their products after all those years with regular
releases. LispWorks for example will get SMP support with releases 6.
Without tracking the changes in the OS and hardware area these
products would be dead.
> But I honestly don’t see a chance how they could grow.
They can grow by supporting markets that are growing or are not
supported
well currently. Especially markets that grow in absolute numbers
(installed/used systems).
Markets where growing number of users might need a flexible tool or
want/can to grow from
existing tools to a more capable development tool.
* Linux/Desktop
* Linux/Servers
* Windows PCs
* Macs
* Mobile devices
Users want to write applications with native user interfaces and
web user interfaces using a simple GUI & IDE. I think there is
still room for improvement.
From other development tools you can see trends in the direction
of modelling, support for groups, agile development, code
maintenance etc. You can see that Franz moves in the direction
of 'semantic technologies'.
> Maybe one of them decides to build a new IDE for Clojure. That could
> perhaps make sense. There is no such IDE now, and in the long run more
> and more Lispers will switch over to Clojure and other people are also
> moving into that direction.
> But currently there is no real IDE.
> Just editors with code colorization and indentation.
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
······@corporate-world.lisp.de wrote:
> On 12 Jan., 23:24, André Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> And they have each some hundred paying
>> customers for years to come which will guarantee survival.
>> A pretty stable niche I would say.
>
> I don't know how stable the niche is. But I see that Franz and
> LispWorks are still improving their products after all those years with
> regular releases.
Lispworks seem to release a couple of patches a year but their mailing list
traffic has fallen 80% over the past four years.
> LispWorks for example will get SMP support with releases
> 6. Without tracking the changes in the OS and hardware area these
> products would be dead.
I would say that they failed to track important changes (e.g. lack of SMP
when multicore machines have been ubiquitous for years) and they are
undead.
>> But I honestly don’t see a chance how they could grow.
>
> They can grow by supporting markets that are growing or are not
> supported well currently. Especially markets that grow in absolute numbers
> (installed/used systems). Markets where growing number of users might need
> a flexible tool or want/can to grow from existing tools to a more capable
> development tool.
>
> * Linux/Desktop
The commercial Linux desktop market is tiny.
> * Linux/Servers
The Linux server market is a possibility but they would need a reputation
for reliability that they do not have.
> * Windows PCs
They cannot possibly hope to compete with Microsoft's offerings.
> * Macs
The OS X market is tiny and shrinking.
> * Mobile devices
By far the best of those choices, IMHO.
> Users want to write applications with native user interfaces and
> web user interfaces using a simple GUI & IDE. I think there is
> still room for improvement.
>
> From other development tools you can see trends in the direction
> of modelling, support for groups, agile development, code
> maintenance etc. You can see that Franz moves in the direction
> of 'semantic technologies'.
The problem isn't the application domains that they are trying to provide
for. The problem is that they are offering only Lisp to paying customers
who have many more alluring alternatives available for free.
They could have built upon a better foundation like the JVM, as opposed to
Greenspunning their own VMs, but Clojure has beaten them to it, and is
free.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Jan 13, 4:07 am, Jon Harrop <····@ffconsultancy.com> wrote:
> ······@corporate-world.lisp.de wrote:
> > On 12 Jan., 23:24, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> And they have each some hundred paying
> >> customers for years to come which will guarantee survival.
> >> A pretty stable niche I would say.
>
> > I don't know how stable the niche is. But I see that Franz and
> > LispWorks are still improving their products after all those years with
> > regular releases.
>
> Lispworks seem to release a couple of patches a year but their mailing list
> traffic has fallen 80% over the past four years.
The numbers based on Gmane message ids for your entertainment:
2004 1579
2005 1785
2006 1179
2007 1087
2008 1546
Frog talk removed.
On Jan 13, 4:07 am, Jon Harrop <····@ffconsultancy.com> wrote:
> > LispWorks for example will get SMP support with releases
> > 6. Without tracking the changes in the OS and hardware area these
> > products would be dead.
>
> I would say that they failed to track important changes (e.g. lack of SMP
> when multicore machines have been ubiquitous for years) and they are
> undead.
It's not too late still. Dual core machines are standard and usually
one core is for the OS and background services.
>
> >> But I honestly don’t see a chance how they could grow.
>
> > They can grow by supporting markets that are growing or are not
> > supported well currently. Especially markets that grow in absolute numbers
> > (installed/used systems). Markets where growing number of users might need
> > a flexible tool or want/can to grow from existing tools to a more capable
> > development tool.
>
> > * Linux/Desktop
>
> The commercial Linux desktop market is tiny.
Ok
>
> > * Linux/Servers
>
> The Linux server market is a possibility but they would need a reputation
> for reliability that they do not have.
It's not the problem in realibility but in prefabricated built in web
framework, kiddies are learn to drag & drop and even masters use it
for quick only-3-pages dirty apps. The problem is that many
applications start that way and aren't rewritten. Allegroserve was a
great step but Franz lost itself in the warp. There are many good web
frameworks, like weblocks, the vendors should just adapt or write one
and make work great with their implementation out of the box. Lisp
server pages remind me of the middle of 90s. I'm picking on Franz
because they at least done more than the rest, beside Scieneer web
server the others did nothing. Lisp open source did a lot but there is
some staff that open source doesn't do well without megabucks bucking
it.
If the lisp vendors still don't get it here's the plan:
1. adapt weblocks or some other framework
2. keep it open source
3. make it work great with your implementation so the people with
money will prefer to buy your lisp
4. do what this people do http://www.telerik.com/ for your framework
>
> > * Windows PCs
>
> They cannot possibly hope to compete with Microsoft's offerings.
They MUST compete with Microsoft'f offerings and use their advantages
in their specific niches.
If they lure 1000 customers from Microsoft, MS won't even notice, but
lisp vendors size will grow times X.
Lisp vendors are small fish, if they grab certain niches are serve it
will it would make them grow
>
> > * Macs
>
> The OS X market is tiny and shrinking.
No Mac is relevant again and growing.
http://marketshare.hitslink.com/report.aspx?qprid=11
>
> > * Mobile devices
>
> By far the best of those choices, IMHO.
>
> > Users want to write applications with native user interfaces and
> > web user interfaces using a simple GUI & IDE. I think there is
> > still room for improvement.
>
> > From other development tools you can see trends in the direction
> > of modelling, support for groups, agile development, code
> > maintenance etc. You can see that Franz moves in the direction
> > of 'semantic technologies'.
>
> The problem isn't the application domains that they are trying to provide
> for. The problem is that they are offering only Lisp to paying customers
> who have many more alluring alternatives available for free.
I agree for people interested in learning new languages. They don't
have much money and want their toys free.
But company not willing to spend few hundreds bucks on a tool,
pleeease? Money is not a problem, it's the perception of why using
this weird thing?
>
> They could have built upon a better foundation like the JVM, as opposed to
> Greenspunning their own VMs, but Clojure has beaten them to it, and is
> free.
They aren't Greenspunning, lisp is just working better under it's own
VM than JVM.
And free is relative. Postgre is free but people still buy Oracle.
Open Office is free but people still buy MS Office. There are many Dvd
rippers free but I still bought commercial ones? Why ? Because they
offer some added value.
bobi
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
Slobodan Blazeski wrote:
> On Jan 13, 4:07 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> I would say that they failed to track important changes (e.g. lack of SMP
>> when multicore machines have been ubiquitous for years) and they are
>> undead.
>
> It's not too late still. Dual core machines are standard and usually
> one core is for the OS and background services.
I already have 8 cores. Most people have 4 cores. My laptop before last had
2 cores...
>> > * Windows PCs
>>
>> They cannot possibly hope to compete with Microsoft's offerings.
>
> They MUST compete with Microsoft'f offerings and use their advantages
> in their specific niches.
In other words, use a specific niche to avoid competing directly with
Microsoft. Lisp is that niche and it is not a lucrative one.
> If they lure 1000 customers from Microsoft, MS won't even notice, but
> lisp vendors size will grow times X.
They will not lure 1,000 customers from Microsoft.
> Lisp vendors are small fish, if they grab certain niches are serve it
> will it would make them grow
Only if the niche is commercially viable which, IMHO, Lisp is not.
>> > * Macs
>>
>> The OS X market is tiny and shrinking.
>
> No Mac is relevant again and growing.
> http://marketshare.hitslink.com/report.aspx?qprid=11
Other data shows OS X below 4% and shrinking:
http://news.softpedia.com/news/Windows-Vista-Windows-XP-Linux-Mac-OS-X-Market-Share-Deathmatch-58965.shtml
Consider that Leopard has sold only a few million copies compared to 140M
for Vista.
>> The problem isn't the application domains that they are trying to provide
>> for. The problem is that they are offering only Lisp to paying customers
>> who have many more alluring alternatives available for free.
>
> I agree for people interested in learning new languages. They don't
> have much money and want their toys free.
> But company not willing to spend few hundreds bucks on a tool,
> pleeease? Money is not a problem, it's the perception of why using
> this weird thing?
People don't leap at the idea of paying money for something that is worse.
>> They could have built upon a better foundation like the JVM, as opposed
>> to Greenspunning their own VMs, but Clojure has beaten them to it, and is
>> free.
>
> They aren't Greenspunning, lisp is just working better under it's own
> VM than JVM.
No, it isn't. Witness the fact that the JVM has a concurrent GC and
Lispworks still does not.
> And free is relative. Postgre is free but people still buy Oracle.
> Open Office is free but people still buy MS Office. There are many Dvd
> rippers free but I still bought commercial ones? Why ? Because they
> offer some added value.
Exactly. Not only do commercial Lisp vendors offer little value-add, they
create problems.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 13 Jan., 18:48, Jon Harrop <····@ffconsultancy.com> wrote:
> Exactly. Not only do commercial Lisp vendors offer little value-add, they
> create problems.
Actually most problems are created and not fixed by companies like
Microsoft,
who sell weak products and provide weak support. Microsoft's own
offerings are so full of bugs, even in its basic functionality. Word
for
example is the worst possible piece of tool to write a document
longer than a few pages with more than one text style. I had
to use their stuff, because that's what other people had, but
my experience writing anything more than a one page letter was
never fun. Often the document morphed into garbage during editing
(and that was not my content that was garbage ;-) ).
In contrast I found the support from Lisp vendors to be excellent.
Often the fixes are shipped the same day and can patch the
already delivered tool. That's one of the killer features
of Lisp, it enables the support to be very responsive. The
fixes are not bound to the usual software release cycles.
·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
> Microsoft's own offerings are so full of bugs, even in its basic
> functionality. Word for example is the worst possible piece of tool
> to write a document longer than a few pages with more than one text
> style.
Word might well be a veritable abomination for all sorts of
reasons. It is not very sensible or informative to compare development
environments and word processors. I have virtually no experience with
the current offerings of Microsoft in this area, but I would be
extremely skeptical about any conclusions based on the quality of such
pieces of software as Word or other components in the Office family.
--
Aatu Koskensilta (················@uta.fi)
"Wovon man nicht sprechen kann, darüber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
······@corporate-world.lisp.de wrote:
> On 13 Jan., 18:48, Jon Harrop <····@ffconsultancy.com> wrote:
>> Exactly. Not only do commercial Lisp vendors offer little value-add, they
>> create problems.
>
> Actually most problems are created and not fixed by companies like
> Microsoft, who sell weak products and provide weak support. Microsoft's
> own offerings are so full of bugs, even in its basic functionality. Word
> for example is the worst possible piece of tool to write a document
> longer than a few pages with more than one text style. I had
> to use their stuff, because that's what other people had, but
> my experience writing anything more than a one page letter was
> never fun. Often the document morphed into garbage during editing
> (and that was not my content that was garbage ;-) ).
>
> In contrast I found the support from Lisp vendors to be excellent.
> Often the fixes are shipped the same day and can patch the
> already delivered tool. That's one of the killer features
> of Lisp, it enables the support to be very responsive. The
> fixes are not bound to the usual software release cycles.
I write commercial libraries in a matter of weeks that are better than
anything comparable that has ever been written in any Lisp:
http://www.ffconsultancy.com/products/fsharp_for_visualization/
The only reason that is possible in F# is that it makes libraries like WPF
easy to use and those libraries are generations ahead of anything that is
available for Lisp. Moreover, they run out of the box on hundreds of
millions of machines. To top it all off, everything I need as a developer
is free.
Maybe if I were doing something related to the "semantic web" it might be
worth considering Franz' offering but for the vast majority of
applications, any Lisp (including commercial ones) have so little to offer
that it is a complete waste of time to even consider them. The idea that
they have any value add at all over Microsoft's offerings for general
purpose programming is just absurd.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Jan 14, 12:45 am, Jon Harrop <····@ffconsultancy.com> wrote:
> ······@corporate-world.lisp.de wrote:
...
> The only reason that is possible in F# is that it makes libraries like WPF
> easy to use and those libraries are generations ahead of anything that is
> available for Lisp. Moreover, they run out of the box on hundreds of
> millions of machines. To top it all off, everything I need as a developer
> is free.
....
-------
http://stackoverflow.com/questions/161125/whats-wrong-with-f
The main problems with F# are currently maturity,
performance, tools, libraries and user friendliness.
The CTP release of F# is unquestionably a huge
improvement over the reliability of previous versions of the
F# distribution (which used to take down the whole of VS
2005 regularly) but a lot of bugs remain. We found so
many serious bugs in the initial CTP release that we did not
even bother advertising or supporting it. For example, we
discovered that F# said 1/1=2 and the reason turned out to
be a bug in F#'s arbitrary-precision integer divide! I am still
finding more bugs in F# than I have the time to report. On
the up side, I believe Microsoft have addressed every
single bug I have ever reported.
The performance of the F# compiler leaves a lot to be
desired. We stopped developing the old DirectX version of
our F# for Visualization library in part because the F#
development environment ground to a halt on its 50kLOC
code base. Now that the library is WPF based it is under
10kLOC again but development is still seriously hindered
by the poor performance of the development environment.
In particular, the F# development environment typically fails
to use 7 of my cores which is a glaring anti-advert in the
face of functional programming for multicore computing.
Lack of tools is an obvious problem. The product release
will address this by including full GUI designer support.
We have been hampered by the lack of libraries not only
for F# but for the whole .NET platform, which is only seeing
use in a few specific domains despite being a
general-purpose framework. For example, we found no
FFTW bindings, no BLAS and LAPACK bindings and no
implementations of many basic data structures like priority
queues. Instead we found a bewildering array of extremely
poor quality software, much of which was commercial. See
Windale's O(n^2) "FFT" product, for example.
User friendliness is also a serious problem: the compiler
messages are often incomprehensible and, worse, can
contain a lot of internal details that the programmer should
not even be aware of. Such bugs are a real nuisance for
newbies whose progress can be completely blocked by
them. There are also a variety of glaring design flaws, such
as the use of "move up" and "move down" menu items to
move source files around in a project.
Finally, F# inherits some limitations from .NET that might
put developers off. For me, lack of structural typing is a
really unfortunate shortcoming that unnecessarily bloats a
lot of code with superfluous type definitions and
long-winded references to namespaces, even in F#.
OCaml's polymorphic variants are a Godsend. For
example, the OCaml Journal and F#.NET Journal both just
published articles about triangulated irregular networks
from computer graphics and despite having
pre-implemented vectors and heaps the F# version still
managed to be substantially longer because Windows
Presentation Foundation is so laborious to use for simple
3D visualizations compared to OCaml's LablGL bindings to
OpenGL.
Cheers, Jon Harrop
-------
Hahaha, I think I'll stay with Lisp. :-)
Note for the reader, 'we' is Jon Harrop, his wife
and his sock puppets. He is trying to sell his F# and OCAML
offerings here on comp.lang.lisp for quite some time. During that
time he largely failed to learn any Lisp.
On Jan 14, 1:39 am, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:
> On Jan 14, 12:45 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > ······@corporate-world.lisp.de wrote:
>
> ...
>
> > The only reason that is possible in F# is that it makes libraries like WPF
> > easy to use and those libraries are generations ahead of anything that is
> > available for Lisp. Moreover, they run out of the box on hundreds of
> > millions of machines. To top it all off, everything I need as a developer
> > is free.
>
> ....
>
> -------
>
> http://stackoverflow.com/questions/161125/whats-wrong-with-f
>
> The main problems with F# are currently maturity,
> performance, tools, libraries and user friendliness.
>
> The CTP release of F# is unquestionably a huge
> improvement over the reliability of previous versions of the
> F# distribution (which used to take down the whole of VS
> 2005 regularly) but a lot of bugs remain. We found so
> many serious bugs in the initial CTP release that we did not
> even bother advertising or supporting it. For example, we
> discovered that F# said 1/1=2 and the reason turned out to
> be a bug in F#'s arbitrary-precision integer divide! I am still
> finding more bugs in F# than I have the time to report. On
> the up side, I believe Microsoft have addressed every
> single bug I have ever reported.
>
> The performance of the F# compiler leaves a lot to be
> desired. We stopped developing the old DirectX version of
> our F# for Visualization library in part because the F#
> development environment ground to a halt on its 50kLOC
> code base. Now that the library is WPF based it is under
> 10kLOC again but development is still seriously hindered
> by the poor performance of the development environment.
> In particular, the F# development environment typically fails
> to use 7 of my cores which is a glaring anti-advert in the
> face of functional programming for multicore computing.
>
> Lack of tools is an obvious problem. The product release
> will address this by including full GUI designer support.
>
> We have been hampered by the lack of libraries not only
> for F# but for the whole .NET platform, which is only seeing
> use in a few specific domains despite being a
> general-purpose framework. For example, we found no
> FFTW bindings, no BLAS and LAPACK bindings and no
> implementations of many basic data structures like priority
> queues. Instead we found a bewildering array of extremely
> poor quality software, much of which was commercial. See
> Windale's O(n^2) "FFT" product, for example.
>
> User friendliness is also a serious problem: the compiler
> messages are often incomprehensible and, worse, can
> contain a lot of internal details that the programmer should
> not even be aware of. Such bugs are a real nuisance for
> newbies whose progress can be completely blocked by
> them. There are also a variety of glaring design flaws, such
> as the use of "move up" and "move down" menu items to
> move source files around in a project.
>
> Finally, F# inherits some limitations from .NET that might
> put developers off. For me, lack of structural typing is a
> really unfortunate shortcoming that unnecessarily bloats a
> lot of code with superfluous type definitions and
> long-winded references to namespaces, even in F#.
> OCaml's polymorphic variants are a Godsend. For
> example, the OCaml Journal and F#.NET Journal both just
> published articles about triangulated irregular networks
> from computer graphics and despite having
> pre-implemented vectors and heaps the F# version still
> managed to be substantially longer because Windows
> Presentation Foundation is so laborious to use for simple
> 3D visualizations compared to OCaml's LablGL bindings to
> OpenGL.
>
> Cheers, Jon Harrop
>
> -------
>
> Hahaha, I think I'll stay with Lisp. :-)
Bulls eye. Who could thought that our favourite amphibian is capable
of criticizing the given from god language such F-dumb.
bobi
>
> Note for the reader, 'we' is Jon Harrop, his wife
> and his sock puppets. He is trying to sell his F# and OCAML
> offerings here on comp.lang.lisp for quite some time. During that
> time he largely failed to learn any Lisp.
······@corporate-world.lisp.de wrote:
> http://stackoverflow.com/questions/161125/whats-wrong-with-f
>
> The main problems with F# are currently maturity,
> performance, tools, libraries and user friendliness.
>
> Hahaha, I think I'll stay with Lisp. :-)
Lisp has all of those problems and many more of its own.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> ······@corporate-world.lisp.de wrote:
>
> The only reason that is possible in F# is that it makes libraries like WPF
> easy to use and those libraries are generations ahead of anything that is
> available for Lisp.
WPF is for graphs and charts, as I understand it.
There are some charting libraries for Common Lisp,
but the ones I've seen a pretty simple. It's true
that there are problems with Lisp libraries. I hope
that we'll be discussing this at the Lisp conference.
Frog talk removed
On Jan 13, 6:48 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Slobodan Blazeski wrote:
> > On Jan 13, 4:07 am, Jon Harrop <····@ffconsultancy.com> wrote:
> >> I would say that they failed to track important changes (e.g. lack of SMP
> >> when multicore machines have been ubiquitous for years) and they are
> >> undead.
>
> > It's not too late still. Dual core machines are standard and usually
> > one core is for the OS and background services.
>
> I already have 8 cores. Most people have 4 cores. My laptop before last had
> 2 cores...
I couldn't find statistics so but looking at Dell offering, seems
that 2 cores are still majority, with quad cores mostly on desktops.
If you have good data post the link.
>
> >> > * Windows PCs
>
> >> They cannot possibly hope to compete with Microsoft's offerings.
>
> > They MUST compete with Microsoft'f offerings and use their advantages
> > in their specific niches.
>
> In other words, use a specific niche to avoid competing directly with
> Microsoft.
No competing directly against Microsoft. MS has Visual Source Safe and
Team System source control but there are many vendors competing with
it and doing quite Ok.Hiding will get you nowhere.
In a big market small company only needs to take a part of the it. If
it's product it's not a platform, or a horizontal market. I switched 4
source controls in less than a year, but I can't switch windows,
because it's a platform.
>
> >> > * Macs
>
> >> The OS X market is tiny and shrinking.
>
> > No Mac is relevant again and growing.
> >http://marketshare.hitslink.com/report.aspx?qprid=11
>
> Other data shows OS X below 4% and shrinking:
>
> http://news.softpedia.com/news/Windows-Vista-Windows-XP-Linux-Mac-OS-...
>
> Consider that Leopard has sold only a few million copies compared to 140M
> for Vista.
Mac machines are high end, so if your numbers are right you're
comparing 140 mil Ford vs ~10M Mercedes.
Ignoring ~10M wealthy customers isn't very smart.
>
> >> The problem isn't the application domains that they are trying to provide
> >> for. The problem is that they are offering only Lisp to paying customers
> >> who have many more alluring alternatives available for free.
>
> > I agree for people interested in learning new languages. They don't
> > have much money and want their toys free.
> > But company not willing to spend few hundreds bucks on a tool,
> > pleeease? Money is not a problem, it's the perception of why using
> > this weird thing?
>
> People don't leap at the idea of paying money for something that is worse.
>
> >> They could have built upon a better foundation like the JVM, as opposed
> >> to Greenspunning their own VMs, but Clojure has beaten them to it, and is
> >> free.
>
> > They aren't Greenspunning, lisp is just working better under it's own
> > VM than JVM.
>
> No, it isn't. Witness the fact that the JVM has a concurrent GC and
> Lispworks still does not.
That's not an valid argument. Lisp is different from Java, JVM might
not run it well. Maybe Clojure folks could enlighten us a little
bit.Your advice sounds like suggesting that Prolog implementation
should dump WAM and use JVM, but Prolog uses unification unlike Java
and it needs to be very efficient in it. Franz was once thinking about
adopting .Net for Allegro but they found it won't fit. Maybe Duane
could explain you why. Lisp implementors are very smart people , and
if adopting JVM or .Net or whatever was a good choice they would
probably do it.
Bobi
> No competing directly against Microsoft. MS has Visual Source Safe and
> Team System source control but there are many vendors competing with
> it and doing quite Ok.Hiding will get you nowhere.
> In a big market small company only needs to take a part of the it. If
> it's product it's not a platform, or a horizontal market. I switched 4
> source controls in less than a year, but I can't switch windows,
> because it's a platform.
Microsoft uses customized Perforce (internally), and I believe Team
System might be based on it (not sure). Visual Source Safe is shit - not
usable at all.
Perforce is the best I've used. Some of my art colleagues are claiming
AlienBrain is even better (more or less it was created for the graphic
artists, animatiors and modelers).
On Jan 13, 10:13 pm, "Dimiter \"malkia\" Stanev" <······@mac.com>
wrote:
> > No competing directly against Microsoft. MS has Visual Source Safe and
> > Team System source control but there are many vendors competing with
> > it and doing quite Ok.Hiding will get you nowhere.
> > In a big market small company only needs to take a part of the it. If
> > it's product it's not a platform, or a horizontal market. I switched 4
> > source controls in less than a year, but I can't switch windows,
> > because it's a platform.
>
> Microsoft uses customized Perforce (internally), and I believe Team
> System might be based on it (not sure). Visual Source Safe is shit - not
> usable at all.
Same for the TeamSystem, piece of crup.
>
> Perforce is the best I've used. Some of my art colleagues are claiming
> AlienBrain is even better (more or less it was created for the graphic
> artists, animatiors and modelers).
Well it better be it costs an arm and leg http://www.alienbrain.com/pricing
What could you recommend for single person project? And I don't have
$12,000 to spend.
bobi
Slobodan Blazeski wrote:
> On Jan 13, 10:13 pm, "Dimiter \"malkia\" Stanev" <······@mac.com>
> wrote:
>>> No competing directly against Microsoft. MS has Visual Source Safe and
>>> Team System source control but there are many vendors competing with
>>> it and doing quite Ok.Hiding will get you nowhere.
>>> In a big market small company only needs to take a part of the it. If
>>> it's product it's not a platform, or a horizontal market. I switched 4
>>> source controls in less than a year, but I can't switch windows,
>>> because it's a platform.
>> Microsoft uses customized Perforce (internally), and I believe Team
>> System might be based on it (not sure). Visual Source Safe is shit - not
>> usable at all.
> Same for the TeamSystem, piece of crup.
>> Perforce is the best I've used. Some of my art colleagues are claiming
>> AlienBrain is even better (more or less it was created for the graphic
>> artists, animatiors and modelers).
> Well it better be it costs an arm and leg http://www.alienbrain.com/pricing
> What could you recommend for single person project? And I don't have
> $12,000 to spend.
>
> bobi
I'm poking GIT, but haven't done much with it (same with SVN, Darcs, etc.).
My experience (7+) years is with perforce, 1 year with CVS (nightmare!)
and 1 year with VSS (even bigger one).
For personal needs I believe GIT, Darcs or BitKeeper is the proper
choice (allows your filesystem to serve as depot itself - I mean it has
been invented in the past - files versioning, and even Common Lisp
runtime supports it).
I'm actually thinking whether it won't be a good idea to have local GIT
on my work machine, which still syncs to P4 - this way if P4 is down or
locked, I can still locally create patches - sometimes there is need to
submit certain source file, but not in one patch, but several - for
documentation needs, or for various branch ones.
Anyway that got a little off topic....
Btw - there are really cool P4 (through COM) bindings for LispWorks
Windows - I've used them on last project, wrote some simple Lisp
Application that parses all *.cpp *.h files and adds debugging markers
to every function (I was profiling the FMOD source code specifically),
and later it removed them.
Dimiter "malkia" Stanev wrote:
> Perforce is the best I've used.
Another vote for Perforce here.
> For personal needs I believe GIT, Darcs or BitKeeper is the proper
> choice (allows your filesystem to serve as depot itself - I mean it
> has been invented in the past - files versioning, and even Common
> Lisp runtime supports it).
The filesystem is the depot for Perforce as well. And you can use
Perforce for free, with a two user and five client workspace limit.
(For personal use, that's really no problem as you only need one
normal user and one super user.) I've been using it on my home
machine for a year and a half with no problems.
And p4v, the Perforce visual client, is great. Its branching and
merge visualization is top notch.
Walter
P.S. My apologies if you already knew the above. :)
On Jan 15, 1:05 am, WalterGR <········@gmail.com> wrote:
> Dimiter "malkia" Stanev wrote:
> > Perforce is the best I've used.
>
> Another vote for Perforce here.
>
> > For personal needs I believe GIT, Darcs or BitKeeper is the proper
> > choice (allows your filesystem to serve as depot itself - I mean it
> > has been invented in the past - files versioning, and even Common
> > Lisp runtime supports it).
>
> The filesystem is the depot for Perforce as well. And you can use
> Perforce for free, with a two user and five client workspace limit.
> (For personal use, that's really no problem as you only need one
> normal user and one super user.) I've been using it on my home
> machine for a year and a half with no problems.
>
> And p4v, the Perforce visual client, is great. Its branching and
> merge visualization is top notch.
>
> Walter
>
> P.S. My apologies if you already knew the above. :)
Thanks to everybody for the recommendations, but it seems there is
some problems with perforce and my visual studio installation,or I
didn't setup something properly.
Anyway I will try mercurial, I always wanted to see how it works.
bobi
Slobodan Blazeski wrote:
> On Jan 13, 6:48 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Slobodan Blazeski wrote:
>> > On Jan 13, 4:07 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> >> I would say that they failed to track important changes (e.g. lack of
>> >> SMP when multicore machines have been ubiquitous for years) and they
>> >> are undead.
>>
>> > It's not too late still. Dual core machines are standard and usually
>> > one core is for the OS and background services.
>>
>> I already have 8 cores. Most people have 4 cores. My laptop before last
>> had 2 cores...
> I couldn't find statistics so but looking at Dell offering, seems
> that 2 cores are still majority, with quad cores mostly on desktops.
> If you have good data post the link.
Dell's cheapest quad-core desktop is only £399:
. Intel Core 2 Quad-Core Q6600 Processor (2.4GHz, 8MB cache, 1066MHz FSB)
. Windows Vista Home Premium with Service Pack 1, 32-bit - English
. 256MB ATI Radeon HD 3450 graphics card
. 3072MB 800MHz Dual Channel DDR2 SDRAM [2x1024 + 2x512]
. 500GB (7200rpm) SATA Hard Drive
. DVD +/- RW Drive (read/write CD & DVD)
http://www1.euro.dell.com/content/products/productdetails.aspx/inspndt_530?c=uk&l=en&s=dhs&cs=ukdhs1&~oid=uk~en~20211~jan_inspndt_530_d015004~~
>> >> > * Windows PCs
>>
>> >> They cannot possibly hope to compete with Microsoft's offerings.
>>
>> > They MUST compete with Microsoft'f offerings and use their advantages
>> > in their specific niches.
>>
>> In other words, use a specific niche to avoid competing directly with
>> Microsoft.
>
> No competing directly against Microsoft. MS has Visual Source Safe and
> Team System source control but there are many vendors competing with
> it and doing quite Ok. Hiding will get you nowhere.
If you compete directly with them they are likely to either leverage their
monopoly to lock you out (e.g. Netscape, Lotus) or they will simply steal
your work (e.g. Stac).
>> >> > * Macs
>>
>> >> The OS X market is tiny and shrinking.
>>
>> > No Mac is relevant again and growing.
>> >http://marketshare.hitslink.com/report.aspx?qprid=11
>>
>> Other data shows OS X below 4% and shrinking:
>>
>> http://news.softpedia.com/news/Windows-Vista-Windows-XP-Linux-Mac-OS-...
>>
>> Consider that Leopard has sold only a few million copies compared to 140M
>> for Vista.
>
> Mac machines are high end...
The last time I looked, none of Apple's machines could even boot Mac OS X if
you put a current generation graphics card in them. Even the highest-spec
Mac Pro was shipping with a graphics card that was a generation out of
date.
Macs are not high end...
>> >> They could have built upon a better foundation like the JVM, as
>> >> opposed to Greenspunning their own VMs, but Clojure has beaten them to
>> >> it, and is free.
>>
>> > They aren't Greenspunning, lisp is just working better under it's own
>> > VM than JVM.
>>
>> No, it isn't. Witness the fact that the JVM has a concurrent GC and
>> Lispworks still does not.
>
> That's not an valid argument...
Yes it is.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Frog talk removed
On Jan 14, 2:26 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> >> >> > * Windows PCs
>
> >> >> They cannot possibly hope to compete with Microsoft's offerings.
>
> >> > They MUST compete with Microsoft'f offerings and use their advantages
> >> > in their specific niches.
>
> >> In other words, use a specific niche to avoid competing directly with
> >> Microsoft.
>
> > No competing directly against Microsoft. MS has Visual Source Safe and
> > Team System source control but there are many vendors competing with
> > it and doing quite Ok. Hiding will get you nowhere.
>
> If you compete directly with them they are likely to either leverage their
> monopoly to lock you out (e.g. Netscape, Lotus) or they will simply steal
> your work (e.g. Stac).
That was in the 90s, now if you take all the MS employees togather
they can't make a single descent product. MS only products that are
making money are Office, Windows, SQL server and maybe Navision.
Everything else bleeds money, like xbox. Even in the 90s MS failed to
beat Intuit even when it was giving their product for free. MS has the
platform but with advent of internet, it's not so valuable anymore. if
the product is crappy like the god damn IE8 which crushes on wikipedia
pages and you can't uninstall it from Windows server, well then I
don't care if it has MS sticker I will download and install something
else. BTW writing from Opera.
bobi
Jon Harrop <···@ffconsultancy.com> writes:
>>> >> > * Macs
>>>
>>> >> The OS X market is tiny and shrinking.
>>>
>>> > No Mac is relevant again and growing.
>>> >http://marketshare.hitslink.com/report.aspx?qprid=11
>>>
>>> Other data shows OS X below 4% and shrinking:
>>>
>>> http://news.softpedia.com/news/Windows-Vista-Windows-XP-Linux-Mac-OS-...
>>>
>>> Consider that Leopard has sold only a few million copies compared to 140M
>>> for Vista.
>>
>> Mac machines are high end...
>
> The last time I looked, none of Apple's machines could even boot Mac OS X if
> you put a current generation graphics card in them. Even the highest-spec
> Mac Pro was shipping with a graphics card that was a generation out of
> date.
>
> Macs are not high end...
Yes they are.
It is high end to have a good graphic card with a good driver and good
software running it, with less bugs, compared to having to integrate
hardware out of the factory the same day, that is untested and
unproved, without uptodate drivers and buggy software.
High end quality implies that you spend some time on tuning and
refining the configuration and software, and therefore that you don't
get the latest stuff, which is generally reserved to test pilots and
other kinds of broken necks.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>>>> >> > * Macs
>>>>
>>>> >> The OS X market is tiny and shrinking.
>>>>
>>>> > No Mac is relevant again and growing.
>>>> >http://marketshare.hitslink.com/report.aspx?qprid=11
>>>>
>>>> Other data shows OS X below 4% and shrinking:
>>>>
>>>>
http://news.softpedia.com/news/Windows-Vista-Windows-XP-Linux-Mac-OS-...
>>>>
>>>> Consider that Leopard has sold only a few million copies compared to
>>>> 140M for Vista.
>>>
>>> Mac machines are high end...
>>
>> The last time I looked, none of Apple's machines could even boot Mac OS X
>> if you put a current generation graphics card in them. Even the
>> highest-spec Mac Pro was shipping with a graphics card that was a
>> generation out of date.
>>
>> Macs are not high end...
>
> Yes they are.
No, they aren't.
> It is high end to have a good graphic card...
Mac OS X cannot even handle the latest generation of graphics cards.
> High end quality implies that you spend some time on tuning and
> refining the configuration and software, and therefore that you don't
> get the latest stuff, which is generally reserved to test pilots and
> other kinds of broken necks.
Nonsense.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Pascal J. Bourguignon wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>>>>>>> * Macs
>>>>>>> The OS X market is tiny and shrinking.
>>>>>> No Mac is relevant again and growing.
>>>>>> http://marketshare.hitslink.com/report.aspx?qprid=11
>>>>> Other data shows OS X below 4% and shrinking:
>>>>>
>>>>>
> http://news.softpedia.com/news/Windows-Vista-Windows-XP-Linux-Mac-OS-...
>>>>> Consider that Leopard has sold only a few million copies compared to
>>>>> 140M for Vista.
>>>> Mac machines are high end...
>>> The last time I looked, none of Apple's machines could even boot Mac OS X
>>> if you put a current generation graphics card in them. Even the
>>> highest-spec Mac Pro was shipping with a graphics card that was a
>>> generation out of date.
>>>
>>> Macs are not high end...
>> Yes they are.
>
> No, they aren't.
>
>> It is high end to have a good graphic card...
>
> Mac OS X cannot even handle the latest generation of graphics cards.
>
>> High end quality implies that you spend some time on tuning and
>> refining the configuration and software, and therefore that you don't
>> get the latest stuff, which is generally reserved to test pilots and
>> other kinds of broken necks.
>
> Nonsense.
>
High-end could mean - low-latency especially when comes to Audio -
nothing beats the Mac Platform, when comes to popular OS-s (BeOS does
not count). Even with ASIO the things are not that good on the Windows side.
I yet have to see an Audio Designer, Engineer to use Windows (yes there
are) it's just that I have not seen one - all I've seen have used Mac OS
X (or Mac OS 7, 8 or 9 in the past).
Not sure whether it's the timer, the interrupts, or the how audio is
handled in the system - but this is what they preffer.
On Thu, 15 Jan 2009, Dimiter "malkia" Stanev wrote:
> Jon Harrop wrote:
>> Pascal J. Bourguignon wrote:
>>> Jon Harrop <···@ffconsultancy.com> writes:
>>>>>>>>> * Macs
>>>>>>>> The OS X market is tiny and shrinking.
>>>>>>> No Mac is relevant again and growing.
>>>>>>> http://marketshare.hitslink.com/report.aspx?qprid=11
>>>>>> Other data shows OS X below 4% and shrinking:
>>>>>>
>>>>>>
>> http://news.softpedia.com/news/Windows-Vista-Windows-XP-Linux-Mac-OS-...
>>>>>> Consider that Leopard has sold only a few million copies compared to
>>>>>> 140M for Vista.
>>>>> Mac machines are high end...
>>>> The last time I looked, none of Apple's machines could even boot Mac OS X
>>>> if you put a current generation graphics card in them. Even the
>>>> highest-spec Mac Pro was shipping with a graphics card that was a
>>>> generation out of date.
>>>>
>>>> Macs are not high end...
>>> Yes they are.
>>
>> No, they aren't.
>>
>>> It is high end to have a good graphic card...
>>
>> Mac OS X cannot even handle the latest generation of graphics cards.
>>
>>> High end quality implies that you spend some time on tuning and
>>> refining the configuration and software, and therefore that you don't
>>> get the latest stuff, which is generally reserved to test pilots and
>>> other kinds of broken necks.
>>
>> Nonsense.
>>
>
> High-end could mean - low-latency especially when comes to Audio - nothing
> beats the Mac Platform, when comes to popular OS-s (BeOS does not count).
> Even with ASIO the things are not that good on the Windows side.
>
> I yet have to see an Audio Designer, Engineer to use Windows (yes there are)
> it's just that I have not seen one - all I've seen have used Mac OS X (or Mac
> OS 7, 8 or 9 in the past).
>
> Not sure whether it's the timer, the interrupts, or the how audio is handled
> in the system - but this is what they preffer.
>
Linux handles latency very well too, probably much better than macosx.
(so, yes, one popular OS beats the mac on low-latency). But you have to
patch the kernel, find the right hardware, and so on. For sound
installations, linux is probably more common than mac. And for some
specific things, like wavefield synthesis, you would be crazy to use
something else than linux, if I have understood correctly.
On 2009-01-15 15:53:15 -0500, "Kjetil S. Matheussen"
<··············@notam02.no> said:
> Linux handles latency very well too, probably much better than macosx.
> (so, yes, one popular OS beats the mac on low-latency). But you have to
> patch the kernel, find the right hardware, and so on.
Yes and musicians are the kernel-patching sort so...
--
Raffael Cavallaro, Ph.D.
On Thu, 15 Jan 2009, Raffael Cavallaro wrote:
> On 2009-01-15 15:53:15 -0500, "Kjetil S. Matheussen"
> <··············@notam02.no> said:
>
>> Linux handles latency very well too, probably much better than macosx.
>> (so, yes, one popular OS beats the mac on low-latency). But you have to
>> patch the kernel, find the right hardware, and so on.
>
> Yes and musicians are the kernel-patching sort so...
I know many musicians, including myself, who are, so yes, that's right.
From: Dimiter "malkia" Stanev
Subject: Re: OT. Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gkoc0v$p0d$1@news.motzarella.org>
Kjetil S. Matheussen wrote:
>
>
> On Thu, 15 Jan 2009, Raffael Cavallaro wrote:
>
>> On 2009-01-15 15:53:15 -0500, "Kjetil S. Matheussen"
>> <··············@notam02.no> said:
>>
>>> Linux handles latency very well too, probably much better than macosx.
>>> (so, yes, one popular OS beats the mac on low-latency). But you have
>>> to patch the kernel, find the right hardware, and so on.
>>
>> Yes and musicians are the kernel-patching sort so...
>
> I know many musicians, including myself, who are, so yes, that's right.
>
Yes obviously people like you would be using it, but imagine yourself in
a studio of 300+ people, where your machine needs to be administrated,
kept up to date, etc. etc. and most likely using custom linux filter
won't be an option.
In our studio - Windows XP SP2 is used mostly for non-audio work, and
Mac OS X for audio, linux is just here & there.
Really a customized solution would give you the best (there were some
argument time ago on the linux groups which thread management is better
for latency, and which one for throughput), but in general Mac OS X is
there, good enough, not perfect, without all that.
Middle ground.
Windows XP then is not reliable as far as my people are telling me. Not
sure why, it could be their religious thing, it could be the diversity
of hardware Windows XP runs on, and no one knows for sure what's good
and not (vs. dedicated Apple hardware).
All in all in VISTA everything is ^2 crappier, including the audio handling.
So here you got it for HIGH-END machines. People do use Macs, because
for certtain specific tasks, without much customizing, they excel at
doing things other _stock_ machines can't do.
On Jan 15, 10:09 pm, "Kjetil S. Matheussen"
<··············@notam02.no> wrote:
> On Thu, 15 Jan 2009, Raffael Cavallaro wrote:
> > On 2009-01-15 15:53:15 -0500, "Kjetil S. Matheussen"
> > <··············@notam02.no> said:
>
> >> Linux handles latency very well too, probably much better than macosx.
> >> (so, yes, one popular OS beats the mac on low-latency). But you have to
> >> patch the kernel, find the right hardware, and so on.
>
> > Yes and musicians are the kernel-patching sort so...
>
> I know many musicians, including myself, who are, so yes, that's right.
And I know many musicians, including myself(ok ex musician), that
aren't, so no it's not.
Seriously what kind of software is must have in that industry ? And on
what platform it usually sells?
bobi
On 2009-01-15 16:09:36 -0500, "Kjetil S. Matheussen"
<··············@notam02.no> said:
> On Thu, 15 Jan 2009, Raffael Cavallaro wrote:
>
>> On 2009-01-15 15:53:15 -0500, "Kjetil S. Matheussen"
>> <··············@notam02.no> said:
>>
>>> Linux handles latency very well too, probably much better than macosx.
>>> (so, yes, one popular OS beats the mac on low-latency). But you have to
>>> patch the kernel, find the right hardware, and so on.
>>
>> Yes and musicians are the kernel-patching sort so...
>
> I know many musicians, including myself, who are, so yes, that's right.
"many" is not a majority. I sincerely doubt that a majority of
musicians who use computers for recording work have ever compiled a
custom OS kernel.
As another anecdotal data point, my daughter is a recent graduate of a
leading university with a degree in music. She and most of her fellow
concentrators use their computers to record their performances and/or
compositions. None of them uses linux, let alone compiles custom
kernels. Macs on the other hand are quite commonplace in recording
contexts.
--
Raffael Cavallaro, Ph.D.
On Tue, 13 Jan 2009 17:48:42 +0000, Jon Harrop <···@ffconsultancy.com>
wrote:
>Slobodan Blazeski wrote:
>> On Jan 13, 4:07�am, Jon Harrop <····@ffconsultancy.com> wrote:
>>> I would say that they failed to track important changes (e.g. lack of SMP
>>> when multicore machines have been ubiquitous for years) and they are
>>> undead.
>>
>> It's not too late still. Dual core machines are standard and usually
>> one core is for the OS and background services.
>
>I already have 8 cores. Most people have 4 cores. My laptop before last had
>2 cores...
Developers maybe. Most *users* still are on 2 cores or less.
George
George Neuner wrote:
> On Tue, 13 Jan 2009 17:48:42 +0000, Jon Harrop <···@ffconsultancy.com>
> wrote:
>>Slobodan Blazeski wrote:
>>> On Jan 13, 4:07 am, Jon Harrop <····@ffconsultancy.com> wrote:
>>>> I would say that they failed to track important changes (e.g. lack of
>>>> SMP when multicore machines have been ubiquitous for years) and they
>>>> are undead.
>>>
>>> It's not too late still. Dual core machines are standard and usually
>>> one core is for the OS and background services.
>>
>>I already have 8 cores. Most people have 4 cores. My laptop before last
>>had 2 cores...
>
> Developers maybe. Most *users* still are on 2 cores or less.
There are 28 million tri-core XBox 360s, 17 million (effectively) six-core
Playstation 3s. Then you've got the quad core Cortex A8 based phones and
netbooks. Maybe there are still a lot of users with <=2 cores but I'm not
convinced...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Jan 14, 5:24 am, Jon Harrop <····@ffconsultancy.com> wrote:
> George Neuner wrote:
> > On Tue, 13 Jan 2009 17:48:42 +0000, Jon Harrop <····@ffconsultancy.com>
> > wrote:
> >>Slobodan Blazeski wrote:
> >>> On Jan 13, 4:07 am, Jon Harrop <····@ffconsultancy.com> wrote:
> >>>> I would say that they failed to track important changes (e.g. lack of
> >>>> SMP when multicore machines have been ubiquitous for years) and they
> >>>> are undead.
>
> >>> It's not too late still. Dual core machines are standard and usually
> >>> one core is for the OS and background services.
>
> >>I already have 8 cores. Most people have 4 cores. My laptop before last
> >>had 2 cores...
>
> > Developers maybe. Most *users* still are on 2 cores or less.
Definately developers and gamers, and they don't buy 399 crup with
256MB graphic cards.
Most models are stil dual core, even more in laptops than desktops and
the switching was reached. now the desktop sales are in the minority.
>
> There are 28 million tri-core XBox 360s, 17 million (effectively) six-core
> Playstation 3s. Then you've got the quad core Cortex A8 based phones and
> netbooks. Maybe there are still a lot of users with <=2 cores but I'm not
> convinced...
And 140 million vista that are running on dual and some single core
and quad core.
Not to mentions the still alive XP has 2/3 of the market and is full
of single core and dual cores machines.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
Slobodan Blazeski wrote:
> On Jan 14, 5:24 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> There are 28 million tri-core XBox 360s, 17 million (effectively)
>> six-core Playstation 3s. Then you've got the quad core Cortex A8 based
>> phones and netbooks. Maybe there are still a lot of users with <=2 cores
>> but I'm not convinced...
>
> And 140 million vista that are running on dual and some single core
> and quad core. Not to mentions the still alive XP has 2/3 of the market
> and is full of single core and dual cores machines.
You are just repeating an unsubstantiated claim.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Jan 15, 7:03 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Slobodan Blazeski wrote:
> > On Jan 14, 5:24 am, Jon Harrop <····@ffconsultancy.com> wrote:
> >> There are 28 million tri-core XBox 360s, 17 million (effectively)
> >> six-core Playstation 3s. Then you've got the quad core Cortex A8 based
> >> phones and netbooks. Maybe there are still a lot of users with <=2 cores
> >> but I'm not convinced...
>
> > And 140 million vista that are running on dual and some single core
> > and quad core. Not to mentions the still alive XP has 2/3 of the market
> > and is full of single core and dual cores machines.
>
> You are just repeating an unsubstantiated claim.
Which claim exactly?
140 mil vista is from your data.
2/3 running XP is from .Net applications. Last info XP is 85.22%
http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=10
45 millions consoles is from your above post and they're irrelevant to
lisp, since people develop for them on custom SDK.
bobi
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
Slobodan Blazeski wrote:
> On Jan 15, 7:03 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Slobodan Blazeski wrote:
>> > On Jan 14, 5:24 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> >> There are 28 million tri-core XBox 360s, 17 million (effectively)
>> >> six-core Playstation 3s. Then you've got the quad core Cortex A8 based
>> >> phones and netbooks. Maybe there are still a lot of users with <=2
>> >> cores but I'm not convinced...
>>
>> > And 140 million vista that are running on dual and some single core
>> > and quad core. Not to mentions the still alive XP has 2/3 of the market
>> > and is full of single core and dual cores machines.
>>
>> You are just repeating an unsubstantiated claim.
> Which claim exactly?
> 140 mil vista is from your data.
That says nothing of the number of cores.
> 2/3 running XP is from .Net applications. Last info XP is 85.22%
>
http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=10
> 45 millions consoles is from your above post and they're irrelevant to
> lisp, since people develop for them on custom SDK.
Wasn't Naughtydog the nearest Lisp got to fame recently?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Wed, 14 Jan 2009 04:24:35 +0000, Jon Harrop <···@ffconsultancy.com>
wrote:
>George Neuner wrote:
>> On Tue, 13 Jan 2009 17:48:42 +0000, Jon Harrop <···@ffconsultancy.com>
>> wrote:
>>>Slobodan Blazeski wrote:
>>>> On Jan 13, 4:07�am, Jon Harrop <····@ffconsultancy.com> wrote:
>>>>> I would say that they failed to track important changes (e.g. lack of
>>>>> SMP when multicore machines have been ubiquitous for years) and they
>>>>> are undead.
>>>>
>>>> It's not too late still. Dual core machines are standard and usually
>>>> one core is for the OS and background services.
>>>
>>>I already have 8 cores. Most people have 4 cores. My laptop before last
>>>had 2 cores...
>>
>> Developers maybe. Most *users* still are on 2 cores or less.
>
>There are 28 million tri-core XBox 360s, 17 million (effectively) six-core
>Playstation 3s. Then you've got the quad core Cortex A8 based phones and
>netbooks. Maybe there are still a lot of users with <=2 cores but I'm not
>convinced...
Yeah, but there were nearly a billion single core PC's sold from
2000-2008 and most of them are assumed to be still in use. Only
developers and techno-weenies upgrade for the fun of it - everybody
else waits until their budget allows it or some new software requires
it.
George
Slobodan Blazeski schrieb:
> They aren't Greenspunning, lisp is just working better under it's own
> VM than JVM.
Um, can you please explain more about this?
This seems to me like the statement that Lisp programs run faster if the
guy who wrote them has brown eyes.
Andr�
--
On 14 Jan., 19:01, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Slobodan Blazeski schrieb:
>
> > They aren't Greenspunning, lisp is just working better under it's own
> > VM than JVM.
>
> Um, can you please explain more about this?
> This seems to me like the statement that Lisp programs run faster if the
> guy who wrote them has brown eyes.
>
> André
> --
Common Lisp is a different language than Java. Scheme is a different
language.
Lisp dialects have things like dynamic types, different class
inheritance, different method dispatch,
multiple values, closures, special variables, lots of conses,
continuations, unwind-protects, etc.
In contrast to that the instruction set and data representation of the
JVM is built
to support Java and its constructs.
Historically the best performance has been seen by native code
compilers with special runtimes.
The JVM has got some advantages due to large investments in making it
faster (garbage collection,
compilers, etc.) - but there are still the limitations of the JVM
instruction set.
See for example the discussion around JSR 292 (Supporting Dynamically
Typed Languages on the JVM).
I see now discussions that JSR 292 does not help much. Well, that was
expected for languages
like Common Lisp (with things like multiple values, multiple
dispatch, ...).
On Jan 14, 7:47 pm, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:
> On 14 Jan., 19:01, André Thieme <address.good.until.
>
> ···········@justmail.de> wrote:
> > Slobodan Blazeski schrieb:
>
> > > They aren't Greenspunning, lisp is just working better under it's own
> > > VM than JVM.
>
> > Um, can you please explain more about this?
> > This seems to me like the statement that Lisp programs run faster if the
> > guy who wrote them has brown eyes.
>
> > André
> > --
>
> Common Lisp is a different language than Java. Scheme is a different
> language.
>
> Lisp dialects have things like dynamic types, different class
> inheritance, different method dispatch,
> multiple values, closures, special variables, lots of conses,
> continuations, unwind-protects, etc.
> In contrast to that the instruction set and data representation of the
> JVM is built
> to support Java and its constructs.
>
> Historically the best performance has been seen by native code
> compilers with special runtimes.
> The JVM has got some advantages due to large investments in making it
> faster (garbage collection,
> compilers, etc.) - but there are still the limitations of the JVM
> instruction set.
>
> See for example the discussion around JSR 292 (Supporting Dynamically
> Typed Languages on the JVM).
> I see now discussions that JSR 292 does not help much. Well, that was
> expected for languages
> like Common Lisp (with things like multiple values, multiple
> dispatch, ...).
I wonder do you have some info on parrot VM especially re lispy
languages?
bobi
······@corporate-world.lisp.de wrote:
> Historically the best performance has been seen by native code
> compilers with special runtimes.
That is no longer true, e.g. F# runs circles around OCaml for most
applications and F# is nowhere near as heavily optimized.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 15 Jan., 19:01, Jon Harrop <····@ffconsultancy.com> wrote:
> ······@corporate-world.lisp.de wrote:
> > Historically the best performance has been seen by native code
> > compilers with special runtimes.
>
> That is no longer true, e.g. F# runs circles around OCaml for most
> applications and F# is nowhere near as heavily optimized.
You are in comp.lang.lisp.
If fraction of time spent by group members reading and writing in this
topic would instead spent on making asdf more sane, it would
definitely help to make lisp more popular. Finally I'm approaching a
conclusion that a flexibility of asdf and flexibility of lisp do allow
to make asdf really useful. All what we need is to unleash asdf power,
describe good practices for newbies and use it for ourselves.
Feel free to join my efforts in this direction:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/fd2de3b608be626c/82f075ead0af3f12#82f075ead0af3f12
······@corporate-world.lisp.de wrote:
> On 15 Jan., 19:01, Jon Harrop <····@ffconsultancy.com> wrote:
>> ······@corporate-world.lisp.de wrote:
>> > Historically the best performance has been seen by native code
>> > compilers with special runtimes.
>>
>> That is no longer true, e.g. F# runs circles around OCaml for most
>> applications and F# is nowhere near as heavily optimized.
>
> You are in comp.lang.lisp.
A comparison of the performance of parallelized code in Clojure and SBCL
would be more relevant but I don't have the data and the result is almost
certainly the same as OCaml vs F#.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop schrieb:
> ······@corporate-world.lisp.de wrote:
>> On 15 Jan., 19:01, Jon Harrop <····@ffconsultancy.com> wrote:
>>> ······@corporate-world.lisp.de wrote:
>>>> Historically the best performance has been seen by native code
>>>> compilers with special runtimes.
>>> That is no longer true, e.g. F# runs circles around OCaml for most
>>> applications and F# is nowhere near as heavily optimized.
>> You are in comp.lang.lisp.
>
> A comparison of the performance of parallelized code in Clojure and SBCL
> would be more relevant but I don't have the data and the result is almost
> certainly the same as OCaml vs F#.
This is hard to say in general.
In lots of cases you may be very right. Cases, which are interesting for
humans and not proof of concepts.
From http://www.franz.com/support/faq/#s-mp and specifically
http://www.franz.com/support/faq/#smpimpl we can find:
�Large amounts of the SBCL library have not been inspected for
thread-safety. Some of the obviously unsafe areas have large locks
around them, so compilation and fasl loading, for example, cannot be
parallelized. Work is ongoing in this area.�
So, for those cases there would be no real concurrency going on.
Same is true for Allegro and Lispworks. Lispworks puts a huge lock
around the system that in fact only one thread is running at the same
time.
In those cases the small run-time penalty that Clojure code has
compared to compiled CL code may not be noticed anymore when the
program runs on 8 cores (and this time really concurrent).
This will be put even more into the background with the next generations
of multicore processors. In the next decade there will be CPUs with
100+ cores.
Although even F#/Clojure/Erlang don�t help if some algorithms simply
are not parallelizable.
What we should keep in mind is that Clojure wants to make
concurrency easy (easier). Ultimate performance was not the most
important aspect.
Btw, if you run your code on only one core, does the OCaml code
then run faster than your F# code?
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
> Although even F#/Clojure/Erlang don�t help if some algorithms simply
> are not parallelizable.
And some algorithms are simply hard to parallelize no matter what - for
example take LZW compression, or any dictionary-based compression - any
finite state machine.
So it could be that we would have to scrap things that are good now, for
others that are good to be parallelized (data, algorithms & structures).
Dimiter "malkia" Stanev wrote:
> So it could be that we would have to scrap things that are good now, for
> others that are good to be parallelized (data, algorithms & structures).
Absolutely. However, will we adopt data structures and algorithms that are
good specifically for *managed* parallelism, e.g. GC friendly data
structures?
Given the dominance of managed languages (Java/C#), I think that is highly
likely but there is almost no literature describing how this might be done.
Indeed, even the basic performance characteristics of Microsoft's current
GC on 16 cores or more is essentially unknown, at least outside MS.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Agreed.
André Thieme wrote:
> Btw, if you run your code on only one core, does the OCaml code
> then run faster than your F# code?
Strongly dependent on what exactly you're doing. Single threaded code
running on a single code that allocates heavily can be up to 5x faster in
OCaml than F#. Numerical code is often several times faster in F# than in
OCaml because the CLR automates lots of productive optimizations like CSE
and hoisting of loop invariants. Heavily abstracted code also tends to be a
lot faster in F# than OCaml because the JIT compiler can remove the
overhead of the abstractions after linking. F# also lets you inline
higher-order functions, which can completely remove the overhead of
function dispatch and can make F# up to 20x faster than OCaml precisely
because you're not paying for the unnecessary bit-twiddling hacks that Kaz
referred to.
The JVM has different performance characteristics to Microsoft's CLR but I
believe the results will be comparable. Once Clojure implements the usual
optimizations found in Lisp compilers, I would not be surprised to see it
running circles around conventional compilers like SBCL, particularly when
it comes to parallelism on multicores.
Incidentally, Mono is extremely slow compared to .NET so don't try to infer
anything from benchmark results that use Mono instead, e.g. F# on the
shootout.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Jan 16, 11:42 am, Jon Harrop <····@ffconsultancy.com> wrote:
...
> The JVM has different performance characteristics to Microsoft's CLR but I
> believe the results will be comparable. Once Clojure implements the usual
> optimizations found in Lisp compilers, I would not be surprised to see it
> running circles around conventional compilers like SBCL, particularly when
> it comes to parallelism on multicores.
You might want to report back when you have written any Lisp
application to demonstrate
that.
From: Pascal J. Bourguignon
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <87r635yb1l.fsf@galatea.local>
Andr� Thieme <······························@justmail.de> writes:
> Slobodan Blazeski schrieb:
>
>> They aren't Greenspunning, lisp is just working better under it's own
>> VM than JVM.
>
> Um, can you please explain more about this?
> This seems to me like the statement that Lisp programs run faster if the
> guy who wrote them has brown eyes.
You never wrote an interpreter?
and an interpreter in that interpreter?
and another one over?
It's all turtles, not rabbits!
--
__Pascal Bourguignon__
On Jan 14, 7:01 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Slobodan Blazeski schrieb:
>
> > They aren't Greenspunning, lisp is just working better under it's own
> > VM than JVM.
>
> Um, can you please explain more about this?
> This seems to me like the statement that Lisp programs run faster if the
> guy who wrote them has brown eyes.
>
> André
> --
Different languages work best with different things under the hood.
Ex 1 scheme requires tail call elimination( and every cl worthy it's
name has it), so if you're chosen VM isn't providing that you will
blow up your stack in something that is normal way of looping for a
schemer.
Ex 2 Prolog relies on unification, so you need WAM or something like
that makes programming with backtracking feasible.
Ex 3 q/kdb regularly works with tables of hundreds of gigabytes if
your target VM has problem with anything larget then 100 MB you're
doomed.
ex 4 Scheme has continuations, could your VM support them efficiently
or will die when grab one from a deep nested stack?
ex 5 OCaml needs fast pattern matching, could everything be supplied
via library?
The usual car comparison, you can't expect landrover, porche and kia
to share a same engine? Landrover expect extreme reliability under
harshest conditions, porche wants speed and kia wants very good miles
per gallon efficiency. You could somewhat tweak landrover engine to
goes for speed or for good mileage but this kind of engine will loose
against a specialist designed specifically for speed or efficiency.
Else why would Porche make their own engines instead of using one from
Golf, there are millions of them and they're cheap, proven , parts are
easy to find etc etc. Do you think that Porche engineers are
greenspunning their engine? No they have a different needs.
bobi
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gko05j$d3e$1@opal.icpnet.pl>
thus spoke Slobodan Blazeski <·················@gmail.com>:
> ex 4 Scheme has continuations, could your VM support them efficiently
> or will die when grab one from a deep nested stack?
Stack? What stack? CPS-transformation seems to be the only robust
implementation choice.
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
Stanis� aw Halik <·······@test123.ltd.pl> wrote:
+---------------
| thus spoke Slobodan Blazeski <·················@gmail.com>:
| > ex 4 Scheme has continuations, could your VM support them efficiently
| > or will die when grab one from a deep nested stack?
|
| Stack? What stack? CPS-transformation seems to be the only robust
| implementation choice.
+---------------
1. There are other robust choices: A-normalization, SSA, etc.
2. Even CPS-transformed Scheme has a "stack", it's just that
the stack is hidden in the environments of the continuations
themselves, which is where the information about where to
"return" to is encoded.
3. Slobodan's "grab one from a deep nested stack" also addresses
the issues of invoking a continuation *other* than the normal
"next thing to do", such a continuation explictly reified by
the user (with CALL/CC) or a continuation reified by some
exception-handling system. CPS-transformed code always needs
to be able to handle the case of the normal continuation
being *abandoned* and some other continuation called instead.
[And, indeed, this is one of the advantages touted for CPS,
that it makes that abandonment easier!]
So Slobodan's question seems perfectly reasonable to me:
How (or how well) does your VM support abandonment of the
current "normal" continuation and the invocation of some
different continuation which was created much higher in
the dynamic function-calling nesting level [a.k.a. "stack"]?
And specfically for Scheme, How (or how well) does your VM
support the invocation of the *same* continuation a *second*
(or third, or fourth) time, when that continuation was originally
created & captured deep in the dynamic function-calling nesting
level [a.k.a. "stack"] but was not invoked the second time until
that dynamic function nesting had already been completely unwound?
If your VM cannot support "use many times" continuations,
then it cannot support Scheme.
CL, of course, supports "escaping" continuations [exceptions
and other non-local transfers of control], but *only* those.
Still, getting one's VM to support even "just" those can be
quote a challenge, since that includes such things as this:
(tagbody
restart
...
(some-function (lambda() (go restart)) other-args...)
...)
where SOME-FUNCTION is certainly permitted to FUNCALL it's
first argument, or even pass it off into a very deeply-nested
set of function calls, one of which FUNCALLs the LAMBDA with
the GO in it, forcing a stack-unwind which properly restores all
of the intermediate dynamically-bound variables and executes all
of the intermediate UNWIND-PROTECT cleanup blocks. Can your VM
support that?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jan 16, 2:30 am, ····@rpw3.org (Rob Warnock) wrote:
> StanisÅ aw Halik <·······@test123.ltd.pl> wrote:
> +---------------
> | thus spoke Slobodan Blazeski <·················@gmail.com>:
> | > ex 4 Scheme has continuations, could your VM support them efficiently
> | > or will die when grab one from a deep nested stack?
> |
> | Stack? What stack? CPS-transformation seems to be the only robust
> | implementation choice.
> +---------------
>
> 1. There are other robust choices: A-normalization, SSA, etc.
>
> 2. Even CPS-transformed Scheme has a "stack", it's just that
> the stack is hidden in the environments of the continuations
> themselves, which is where the information about where to
> "return" to is encoded.
>
> 3. Slobodan's "grab one from a deep nested stack" also addresses
> the issues of invoking a continuation *other* than the normal
> "next thing to do", such a continuation explictly reified by
> the user (with CALL/CC) or a continuation reified by some
> exception-handling system. CPS-transformed code always needs
> to be able to handle the case of the normal continuation
> being *abandoned* and some other continuation called instead.
> [And, indeed, this is one of the advantages touted for CPS,
> that it makes that abandonment easier!]
>
> So Slobodan's question seems perfectly reasonable to me:
> How (or how well) does your VM support abandonment of the
> current "normal" continuation and the invocation of some
> different continuation which was created much higher in
> the dynamic function-calling nesting level [a.k.a. "stack"]?
>
> And specfically for Scheme, How (or how well) does your VM
> support the invocation of the *same* continuation a *second*
> (or third, or fourth) time, when that continuation was originally
> created & captured deep in the dynamic function-calling nesting
> level [a.k.a. "stack"] but was not invoked the second time until
> that dynamic function nesting had already been completely unwound?
>
> If your VM cannot support "use many times" continuations,
> then it cannot support Scheme.
>
> CL, of course, supports "escaping" continuations [exceptions
> and other non-local transfers of control], but *only* those.
> Still, getting one's VM to support even "just" those can be
> quote a challenge, since that includes such things as this:
>
> (tagbody
> restart
> ...
> (some-function (lambda() (go restart)) other-args...)
> ...)
>
> where SOME-FUNCTION is certainly permitted to FUNCALL it's
> first argument, or even pass it off into a very deeply-nested
> set of function calls, one of which FUNCALLs the LAMBDA with
> the GO in it, forcing a stack-unwind which properly restores all
> of the intermediate dynamically-bound variables and executes all
> of the intermediate UNWIND-PROTECT cleanup blocks. Can your VM
> support that?
>
> -Rob
After you explained my statements they sound much more
understandable :), even to me . So thank you very much. Next time, If
you don't mind, I will mail you my convulated & quite of often
confused thoughts for clarification and recension before posting them.
cheers
bobi
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
On Jan 15, 7:44 pm, Stanis³aw Halik <·······@test123.ltd.pl> wrote:
> thus spoke Slobodan Blazeski <·················@gmail.com>:
>
> > ex 4 Scheme has continuations, could your VM support them efficiently
> > or will die when grab one from a deep nested stack?
>
> Stack? What stack? CPS-transformation seems to be the only robust
> implementation choice.
But not everybody wants to use it for various reasons.
bobi
On 2009-01-14, André Thieme <······························@justmail.de> wrote:
> Slobodan Blazeski schrieb:
>
>> They aren't Greenspunning, lisp is just working better under it's own
>> VM than JVM.
>
> Um, can you please explain more about this?
> This seems to me like the statement that Lisp programs run faster if the
> guy who wrote them has brown eyes.
There is a big semantic gap between what Lisp requires and the JVM.
The JVM is designed to support the C-like semantics of Java (Von-Neumann-style
computing based on manipulating word-sized quantities), while outlawing the
low-level memory twiddling supported by real C.
Lisp works best when you can target the machine directoy and take advantage of
the freedom of the machine langauge to design your own types.
In the JVM, how do you pack extra bits into a pointer to indicate type?
I can do that in just about any assembly language easily, without violating any
instruction set architecture spec.
I can do that in C---by violating ANSI C, true, but in a way that's still
portable to many compilers.
How do you write a function for the JVM where the argument can be a 32 bit word
that could either be a pointer to an object, or, say, a 31 bit integer?
Would any byte code like that be able to pass the required safety checks?
Kaz Kylheku wrote:
> On 2009-01-14, André Thieme <······························@justmail.de>
> wrote:
>> Slobodan Blazeski schrieb:
>>
>>> They aren't Greenspunning, lisp is just working better under it's own
>>> VM than JVM.
>>
>> Um, can you please explain more about this?
>> This seems to me like the statement that Lisp programs run faster if the
>> guy who wrote them has brown eyes.
>
> There is a big semantic gap between what Lisp requires and the JVM.
No there isn't.
> The JVM is designed to support the C-like semantics of Java
> (Von-Neumann-style computing based on manipulating word-sized quantities),
> while outlawing the low-level memory twiddling supported by real C.
>
> Lisp works best when you can target the machine directoy...
Languages work best if they can leverage existing VMs.
> In the JVM, how do you pack extra bits into a pointer to indicate type?
You don't.
> I can do that in just about any assembly language easily, without
> violating any instruction set architecture spec.
>
> I can do that in C---by violating ANSI C, true, but in a way that's still
> portable to many compilers.
>
> How do you write a function for the JVM where the argument can be a 32 bit
> word that could either be a pointer to an object, or, say, a 31 bit
> integer?
You don't.
> Would any byte code like that be able to pass the required safety checks?
The "features" you've cited are nothing more than outdated hacks. Lisp does
not require them as you originally stated and they have more disadvantages
than advantages.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-01-15, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> On 2009-01-14, André Thieme <······························@justmail.de>
>> wrote:
>>> Slobodan Blazeski schrieb:
>>>
>>>> They aren't Greenspunning, lisp is just working better under it's own
>>>> VM than JVM.
>>>
>>> Um, can you please explain more about this?
>>> This seems to me like the statement that Lisp programs run faster if the
>>> guy who wrote them has brown eyes.
>>
>> There is a big semantic gap between what Lisp requires and the JVM.
>
> No there isn't.
>
>> The JVM is designed to support the C-like semantics of Java
>> (Von-Neumann-style computing based on manipulating word-sized quantities),
>> while outlawing the low-level memory twiddling supported by real C.
>>
>> Lisp works best when you can target the machine directoy...
>
> Languages work best if they can leverage existing VMs.
Bullshit.
>> In the JVM, how do you pack extra bits into a pointer to indicate type?
>
> You don't.
So you have to waste space by sticking it elsewhere.
>> I can do that in just about any assembly language easily, without
>> violating any instruction set architecture spec.
>>
>> I can do that in C---by violating ANSI C, true, but in a way that's still
>> portable to many compilers.
>>
>> How do you write a function for the JVM where the argument can be a 32 bit
>> word that could either be a pointer to an object, or, say, a 31 bit
>> integer?
>
> You don't.
>
>> Would any byte code like that be able to pass the required safety checks?
>
> The "features" you've cited are nothing more than outdated hacks.
Complete bullshit.
> Lisp does
> not require them as you originally stated and they have more disadvantages
> than advantages.
Complete bullshit.
Kaz Kylheku wrote:
> On 2009-01-15, Jon Harrop <···@ffconsultancy.com> wrote:
>> Languages work best if they can leverage existing VMs.
>
> Bullshit.
Clojure, Scala and F# are overwhelming counter examples.
>>> In the JVM, how do you pack extra bits into a pointer to indicate type?
>>
>> You don't.
>
> So you have to waste space by sticking it elsewhere.
You don't encode type information yourself if you're building upon a modern
VM. Indeed, that is the whole point...
>>> Would any byte code like that be able to pass the required safety
>>> checks?
>>
>> The "features" you've cited are nothing more than outdated hacks.
>
> Complete bullshit.
How do you explain the fact that they are only found in previous generation
of compilers like SBCL, OCaml and Haskell but not modern compilers like
Clojure, Scala and F#?
>> Lisp does not require them as you originally stated and they have more
>> disadvantages than advantages.
>
> Complete bullshit.
They were dropped by programming language developers for a reason. The
latest breed of esoteric languages build upon existing VMs and whip the
previous generation of languages in virtually all areas as a consequence.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-01-15, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> On 2009-01-15, Jon Harrop <···@ffconsultancy.com> wrote:
>>> Languages work best if they can leverage existing VMs.
>>
>> Bullshit.
>
> Clojure, Scala and F# are overwhelming counter examples.
>
>>>> In the JVM, how do you pack extra bits into a pointer to indicate type?
>>>
>>> You don't.
>>
>> So you have to waste space by sticking it elsewhere.
>
> You don't encode type information yourself if you're building upon a modern
> VM. Indeed, that is the whole point...
If your'e building a statically typed language on top of a VM for those kinds
of languages, yes. You're discussing this as if we're talking about
implementing a static language. Check the headers, this is comp.lang.lisp.
In Lisp, a value can be anything at all. The JVM doesn't adequately support
this concept, except in some terribly inefficient way, like representing
everything as a reference to an Object base class.
>>>> Would any byte code like that be able to pass the required safety
>>>> checks?
>>>
>>> The "features" you've cited are nothing more than outdated hacks.
>>
>> Complete bullshit.
>
> How do you explain the fact that they are only found in previous generation
> of compilers like SBCL, OCaml and Haskell but not modern compilers like
> Clojure, Scala and F#?
Idiot, by the fact that those ``previous generation'' compilers are the
real thing for real machine language?
Whereas the the latter are toy translators for some VM, and not a ``new
generation'' of anything?
>>> Lisp does not require them as you originally stated and they have more
>>> disadvantages than advantages.
>>
>> Complete bullshit.
>
> They were dropped by programming language developers for a reason.
Blah blah, changing the technical topic to your bullshit popularity obsession
again.
Can't you fuck off with that just for /once/ already!
Kaz Kylheku wrote:
> On 2009-01-15, Jon Harrop <···@ffconsultancy.com> wrote:
>> You don't encode type information yourself if you're building upon a
>> modern VM. Indeed, that is the whole point...
>
> If your'e building a statically typed language on top of a VM for those
> kinds of languages, yes. You're discussing this as if we're talking about
> implementing a static language. Check the headers, this is comp.lang.lisp.
>
> In Lisp, a value can be anything at all. The JVM doesn't adequately
> support this concept, except in some terribly inefficient way, like
> representing everything as a reference to an Object base class.
So the generic case where Lisp compilers' rudimentary type inference hits a
brick wall wastes slightly more space on a mainstream VM. On the other
hand, you inherit a more efficient concurrent GC than any Lisp compiler
will ever get. The benefits far outweigh the costs...
>>>>> Would any byte code like that be able to pass the required safety
>>>>> checks?
>>>>
>>>> The "features" you've cited are nothing more than outdated hacks.
>>>
>>> Complete bullshit.
>>
>> How do you explain the fact that they are only found in previous
>> generation of compilers like SBCL, OCaml and Haskell but not modern
>> compilers like Clojure, Scala and F#?
>
> Idiot, by the fact that those ``previous generation'' compilers are the
> real thing for real machine language?
>
> Whereas the the latter are toy translators for some VM, and not a ``new
> generation'' of anything?
More people are using those "toys" in the real world than any of your
beloved "real compilers" => the outdated hacks you cited are nothing more
than an academic curiosity.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gknt2l$fpv$1@news.motzarella.org>
Kaz Kylheku schrieb:
> On 2009-01-14, André Thieme <······························@justmail.de> wrote:
>> Slobodan Blazeski schrieb:
>>
>>> They aren't Greenspunning, lisp is just working better under it's own
>>> VM than JVM.
>> Um, can you please explain more about this?
>> This seems to me like the statement that Lisp programs run faster if the
>> guy who wrote them has brown eyes.
>
> There is a big semantic gap between what Lisp requires and the JVM.
>
> The JVM is designed to support the C-like semantics of Java (Von-Neumann-style
> computing based on manipulating word-sized quantities), while outlawing the
> low-level memory twiddling supported by real C.
>
> Lisp works best when you can target the machine directoy and take advantage of
> the freedom of the machine langauge to design your own types.
>
> In the JVM, how do you pack extra bits into a pointer to indicate type?
>
> I can do that in just about any assembly language easily, without violating any
> instruction set architecture spec.
>
> I can do that in C---by violating ANSI C, true, but in a way that's still
> portable to many compilers.
>
> How do you write a function for the JVM where the argument can be a 32 bit word
> that could either be a pointer to an object, or, say, a 31 bit integer?
Okay, I see that I understood the word “better” in the usual context,
but you (and others) read something different, that tends into the
direction of efficiency.
Better means for me, that (+ 7 3) returns a stronger 10. One that shines
a bit more, while a (+ 7 3) sometimes could be more like a 9.
You gave examples of how an implementation of Lisp might require more
memory. Yes, I agree that this is very possible. The implementor of that
Lisp is not as free as if he could work on the pure metal.
But this argument could be taken forward to the question why not
implementing Lisp in hardware? This could give you even more freedom.
You don’t have to live with the descision of the hardware producers.
Why does a Byte consist of 8 bits? Why not having a FPU that internally
works with 297 bit numbers, instead of 32?
So:
“Lisp is working better if it was built in hardware, not software”.
I just see that Clojure works very good. Some people would even argue,
that it works “better” than CL, whatever “better” means. And Clojure
runs on a JVM and is without a doubt Lisp. ABCL also compiles to the
code. So, it obviously is possible.
One could argue, that it is much easier to implement a GC. This can be
done in about zero seconds, because there already is one.
One can list several advantages that the JVM offers and from there
conclude that Lisp “just works better” on the JVM.
While I understand your explanations and appreciate that you took your
time to answer it, I still keep my opinion, that the statement of
Slobodan was nonsense in this case.
The very problem lies in the relativeness of the word “better”.
He states it as if he talks about a fact. But it was just an opinion as
I see it.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On 15 Jan., 18:50, André Thieme <address.good.until.
···········@justmail.de> wrote:
>
> Okay, I see that I understood the word “better” in the usual context,
> but you (and others) read something different, that tends into the
> direction of efficiency.
'Better' means different things for people. In the context of
a programming language what better means is best determined
by how an implementation supports applications. Since users
have different applications, better means something different.
We can also talk about 'better' meaning the implementor
of the programming language had less to do. For me as
a user I don't care that much how hard it was for the
implementor. Did he had to write a GC or did he reuse one?
I don't care much about the cost, but about how the
GC runs my application and if it can be tuned
to run my application well (yes, GC tuning is
necessary, also in the Java world).
> Better means for me, that (+ 7 3) returns a stronger 10. One that shines
> a bit more, while a (+ 7 3) sometimes could be more like a 9.
That's an unusual definition of better. I would expect that
basic arithmetic gives the same results in every conforming
implementation of a certain programming language.
For me 'better' would result from comparing be a multitude of features
that
are summed up:
* memory usage on disk
* memory usage in RAM
* application performance
* garbage collection behaviour (incremental, full)
* robustness/speed of interfacing to the OS
* robustness/speed interfacing to some other libraries I need
* support for debugging
* tool support (low level debugger, performance tools, ...)
etc. etc.
Where the native code compiler (Jon, we are talking about Lisp here),
usually shines is performance, GC performance, knobs
where the thing can be tweaked, ...
> You gave examples of how an implementation of Lisp might require more
> memory. Yes, I agree that this is very possible. The implementor of that
> Lisp is not as free as if he could work on the pure metal.
> But this argument could be taken forward to the question why not
> implementing Lisp in hardware?
Because the special hardware is not there. The implementor has the
choice
between an implementation that runs on metal we have or
on some kind of virtual machine. For the latter the implementor
can use an existing virtual machine (there are several to
choose from, not just the JVM).
> This could give you even more freedom.
> You don’t have to live with the descision of the hardware producers.
> Why does a Byte consist of 8 bits? Why not having a FPU that internally
> works with 297 bit numbers, instead of 32?
Do you see special hardware? I don't. (Besides my old Ivory machines).
Case closed. Lisp vendors are no longer in the hardware business.
There are no customers paying for that.
But there is different hardware. There are lots of Intel-PCs running
Windows, Mac OS, some kind of Unix/Linux, ... That's a platform.
Not special hardware that does not exist and likely will not
exist soon.
> So:
> “Lisp is working better if it was built in hardware, not software”.
That might be true. But it is extremely unrealistic to achieve.
A native implementation of Lisp on an Intel Box is not
unrealistic. Many exist.
> I just see that Clojure works very good. Some people would even argue,
> that it works “better” than CL, whatever “better” means.
You have to say what better means. Clojure probably (I haven't tested
it)
works very well as you say. Especially one thing it does much
better than non-JVM implementations of Lisp: direct interfacing
to Java libraries. That's very useful for some people. Clojure
is probably also a cleaner language as for example Common Lisp.
That helps, too. The concurrency features might also
help to improve application performance.
> And Clojure
> runs on a JVM and is without a doubt Lisp. ABCL also compiles to the
> code. So, it obviously is possible.
Nobody doubts that. The result might even run very well, given that
several JVM implementations have been optimized to run large
application servers and the software on top of that.
> One could argue, that it is much easier to implement a GC. This can be
> done in about zero seconds, because there already is one.
I can implement a full Lisp language on top of a CL implementation.
Zero work.
> One can list several advantages that the JVM offers and from there
> conclude that Lisp “just works better” on the JVM.
Why not go the route and list the advantages? I have listed some
above.
What else?
> While I understand your explanations and appreciate that you took your
> time to answer it, I still keep my opinion, that the statement of
> Slobodan was nonsense in this case.
> The very problem lies in the relativeness of the word “better”.
> He states it as if he talks about a fact. But it was just an opinion as
> I see it.
You still have to say what is important for you that sums up into
'better'. If it is performance, that can be checked by benchmark
suites and application benchmarks. If it is something more
'soft' like 'the implementor could reuse the JVM GC' say it.
That fact remains that the performance of a Lisp on the JVM might
be GOOD ENOUGH. Lots of software has been written with much
slower platforms. I would not argue that the JVM provides
the best performance, that's likely not the case. But it provides
enough
performance that Lisp can run on top of it (various Schemes,
ABCL, Clojure, ...). It's better for you if it provides
the features that YOU need to write applications.
The best thing to show off Clojure is to write software
with it and announce it here. What are you writing?
I found for example this much more interesting than
your arguments so far:
http://groups.google.com/group/clojure/browse_thread/thread/85649a134cf22655#
Luc Prefontaine
Hi everyone,
as of yesterday pm, Clojure is running in a live system in a big
veterinarian hospital.
We designed an HL7 message bus to link several services within the
hospital.
Presently we link the medical record system with the radiology
department.
The main benefit is to avoid re-keying information about patient
and
requests in every system.
...
That's the stuff I find much more interesting. Users with
applications.
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
······@corporate-world.lisp.de schrieb:
> On 15 Jan., 18:50, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>
> For me 'better' would result from comparing be a multitude of features
> that
> are summed up:
>
> * memory usage on disk
> * memory usage in RAM
> * application performance
> * garbage collection behaviour (incremental, full)
> * robustness/speed of interfacing to the OS
> * robustness/speed interfacing to some other libraries I need
> * support for debugging
> * tool support (low level debugger, performance tools, ...)
> etc. etc.
>
> Where the native code compiler (Jon, we are talking about Lisp here),
> usually shines is performance, GC performance, knobs
> where the thing can be tweaked, ...
The JVM can potentially outperform native compilers.
During runtime it can find out information that allows it to rearrange
and rewrite the code in such a way that it will perform better.
This can�t be known as long the program is not running.
Common Lisp could do the same as well in principle, as (compile ..) is
available during runtime too. But to my knowledge there is currently no
thing as the JVMs HotSpot for any CL. At least in Lispworks Pro it�s not
available, and when I worked with Allegro Enterprise one year ago it
also did not have such a thing.
> But there is different hardware. There are lots of Intel-PCs running
> Windows, Mac OS, some kind of Unix/Linux, ... That's a platform.
> Not special hardware that does not exist and likely will not
> exist soon.
Although in my opinion those are the plattforms of the past.
At least for me it makes much more sense to target a plattform that
abstracts the operating system and hardware away.
>> I just see that Clojure works very good. Some people would even argue,
>> that it works �better� than CL, whatever �better� means.
>
> You have to say what better means. Clojure probably (I haven't tested
> it) works very well as you say. Especially one thing it does much
> better than non-JVM implementations of Lisp: direct interfacing
> to Java libraries. That's very useful for some people. Clojure
> is probably also a cleaner language as for example Common Lisp.
> That helps, too. The concurrency features might also
> help to improve application performance.
The concurrency features can also greatly improve programmers
productivity, when concurrency is on the agenda.
No meetings to decide what resources need to be shared/locked, no locks
in the code, reduced debugging times, etc.
>> One can list several advantages that the JVM offers and from there
>> conclude that Lisp �just works better� on the JVM.
>
> Why not go the route and list the advantages? I have listed some
> above. What else?
* easy to target many kinds of hardware (32/64 Bit, amd, sun, intel,
mobile phone, tv, ...) and operating systems (Win, Lin, osx, Android,
Unix)
* tons of libs available in the JVM (I think more than for anything
else). Nothing improves productivity more than having the lib that
does the job.
* can mix Clojure code with pure Java which can compete with and often
outperform CL/C++
These are important points in my opinion, to see the JVM as a good
candidate as a plattform for Lisps.
Points that are important for you:
> * memory usage on disk
A little GUI application that I wrote today was 617kb in its .jar file.
If I had written it with Lispworks instead the minimum size would have
been around 7MB I think. That�s at least the smallest we get with a good
delivery level.
> * memory usage in RAM
I think there was a small Lisp on the C64...
But then again, the Java Mirco Edition can also run in just a few kilobytes.
> * application performance
Typical Clojure code will be a bit slower than compiled CL code.
But we should not forget that this Clojure code is also doing something
else, namely providing persistent datastructures, in programs that can
trivially parallelized.
For cases where it is really needed replace the slow 3 lines Clojure
code with 3... hmm.. 25 lines of Java code that do the same and usually
outperform C++ code, or SBCL compiled code.
> * garbage collection behaviour (incremental, full)
About 1,5 years ago we tested Allegros GC against that of the JVM.
It was about 20 minutes (Allegro) vs 20 seconds (Java).
> * robustness/speed of interfacing to the OS
> * robustness/speed interfacing to some other libraries I need
The robustness of the JVM is pretty good. It makes a big difference
if 900.000 people test software or if it�s 621.
Interfacing is excellent. As Java is not a multi-paradigm language
there exists more or less one way to do things. The consequence is that
most libs work perfectly with each other. Typically no problems such as:
�Oh, this does not work in my implementation/version�.
> * support for debugging
There exist plenty debuggers that you can attach to your JVM.
I use JSwat which allows me to step through my Clojure programs line by
line, with break points and all that stuff.
> * tool support (low level debugger, performance tools, ...)
The tool support for the JVM is fantastic.
Very nice profiler:
http://www.yourkit.com/features/index.jsp
The NetBeans GUI builder is way more advanced than everything I have
seen so far. I know the GUI builders from Borland C++, Lispworks,
Allegro and Visual Studio.
There are tools for byte code obfuscation, for visualization, and and and.
And what is also so nice is that it does not longer matter under what
OS you are developing in a team. In principle some of my workmates could
use OSX while I work under Windows Vista. Some others may prefer Open
Solaris.
>> While I understand your explanations and appreciate that you took your
>> time to answer it, I still keep my opinion, that the statement of
>> Slobodan was nonsense in this case.
>> The very problem lies in the relativeness of the word �better�.
>> He states it as if he talks about a fact. But it was just an opinion as
>> I see it.
>
> You still have to say what is important for you that sums up into
> 'better'. If it is performance, that can be checked by benchmark
> suites and application benchmarks. If it is something more
> 'soft' like 'the implementor could reuse the JVM GC' say it.
I gave mostly examples of what I like in the Java plattform (not the
language).
What I like about Clojure is basically what you already mentioned:
clean and together with Erlang and Haskell probably the best language
for concurrency. What I also like very much is the functional flair
and the nice reader macros for accessing the most typical data structures.
> That fact remains that the performance of a Lisp on the JVM might
> be GOOD ENOUGH. Lots of software has been written with much
> slower platforms. I would not argue that the JVM provides
> the best performance, that's likely not the case. But it provides
> enough performance that Lisp can run on top of it (various Schemes,
> ABCL, Clojure, ...). It's better for you if it provides
> the features that YOU need to write applications.
I think it was Rich Hickey himself who said that Clojure is currently
the most performant dynamic language for the JVM.
> The best thing to show off Clojure is to write software
> with it and announce it here. What are you writing?
Would be nice yes, but I can�t make announcements about it here, because
it is confidential. I just can say that I am writing Clojure code nearly
every day.
It just is mostly for professional use and I don�t want to talk about it
here. One thing that I would like to do soon though is to port my system
for Genetic Programming to Clojure.
This is more for fun, and I think I will concentrate for performance
reasons to continue developing it under SBCL. GP is absolutely trivially
parallelizable, so I won�t have any problems. Clojure is nice for helping
in hard problems. But GP can be done so easy that the penalty hit of
using Clojure is most likely too big. I can�t say it for sure yet as I
will have to wait and see the results. It is just a guess now (but a not
so badly informed one).
> That's the stuff I find much more interesting. Users with
> applications.
If you allow me to add: applications about which the users can talk. ;-)
I do both, Lispworks and Clojure. Not talking about it doesn�t mean it
does not happen.
Andr�
--
On Jan 16, 1:47 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
>
> The JVM can potentially outperform native compilers.
> During runtime it can find out information that allows it to rearrange
> and rewrite the code in such a way that it will perform better.
> This can’t be known as long the program is not running.
> Common Lisp could do the same as well in principle, as (compile ..) is
> available during runtime too. But to my knowledge there is currently no
> thing as the JVMs HotSpot for any CL. At least in Lispworks Pro it’s not
> available, and when I worked with Allegro Enterprise one year ago it
> also did not have such a thing.
'Could'. Does it? Currently I haven't seen a JVM based Lisp
outperforming
native code compilers. Show one and present your findings on some
Lisp conference/meeting.
Last time I looked, SUNs JVM implementation was not the fastest.
> > But there is different hardware. There are lots of Intel-PCs running
> > Windows, Mac OS, some kind of Unix/Linux, ... That's a platform.
> > Not special hardware that does not exist and likely will not
> > exist soon.
>
> Although in my opinion those are the plattforms of the past.
Really? Java can't open a file without those. Not even does
it get a keypress or can display a window without those.
Last I looked Java and its infrastructure did not
do too well for general purpose client applications. I see
companies developing special inhouse apps in Java,
but most of the time Java just runs on some app server.
There the Java infrastructure is used, but IMHO in
large companies much of that is bloated ugly object
spaghetti code creating a huge maintenance nightmare.
> At least for me it makes much more sense to target a plattform that
> abstracts the operating system and hardware away.
For the client this is often the browser plus Javascript.
That's the platform. On the server it does not matter much.
You are exchanging one platform for another. Actually x86
is already virtualized and abstracted. I'm running Windows
and Linux under Mac OS X in VMWare. I would have to install
Java under Linux. But then I would run a VM on top
of a virtualized hardware/OS? I know, that way SUN sells
its hardware.
> >> I just see that Clojure works very good. Some people would even argue,
> >> that it works “better” than CL, whatever “better” means.
>
> > You have to say what better means. Clojure probably (I haven't tested
> > it) works very well as you say. Especially one thing it does much
> > better than non-JVM implementations of Lisp: direct interfacing
> > to Java libraries. That's very useful for some people. Clojure
> > is probably also a cleaner language as for example Common Lisp.
> > That helps, too. The concurrency features might also
> > help to improve application performance.
>
> The concurrency features can also greatly improve programmers
> productivity, when concurrency is on the agenda.
> No meetings to decide what resources need to be shared/locked, no locks
> in the code, reduced debugging times, etc.
Great. So your application benefits from that? Anything to report?
> >> One can list several advantages that the JVM offers and from there
> >> conclude that Lisp “just works better” on the JVM.
>
> > Why not go the route and list the advantages? I have listed some
> > above. What else?
>
> * easy to target many kinds of hardware (32/64 Bit, amd, sun, intel,
> mobile phone, tv, ...) and operating systems (Win, Lin, osx, Android,
> Unix)
> * tons of libs available in the JVM (I think more than for anything
> else). Nothing improves productivity more than having the lib that
> does the job.
I'm pretty sure that there is more code in C and compatible with C
calling semantics.
> * can mix Clojure code with pure Java which can compete with and often
> outperform CL/C++
>
> These are important points in my opinion, to see the JVM as a good
> candidate as a plattform for Lisps.
>
> Points that are important for you:
> > * memory usage on disk
>
> A little GUI application that I wrote today was 617kb in its .jar file.
> If I had written it with Lispworks instead the minimum size would have
> been around 7MB I think. That’s at least the smallest we get with a good
> delivery level.
Why is the jar so large?
> > * memory usage in RAM
>
> I think there was a small Lisp on the C64...
> But then again, the Java Mirco Edition can also run in just a few kilobytes.
>
> > * application performance
>
> Typical Clojure code will be a bit slower than compiled CL code.
> But we should not forget that this Clojure code is also doing something
> else, namely providing persistent datastructures, in programs that can
> trivially parallelized.
> For cases where it is really needed replace the slow 3 lines Clojure
> code with 3... hmm.. 25 lines of Java code that do the same and usually
> outperform C++ code, or SBCL compiled code.
Yeah, and SBCL calls C code or assembler where needed.
> > * garbage collection behaviour (incremental, full)
>
> About 1,5 years ago we tested Allegros GC against that of the JVM.
> It was about 20 minutes (Allegro) vs 20 seconds (Java).
I have no idea what you have tested.
> > * robustness/speed of interfacing to the OS
> > * robustness/speed interfacing to some other libraries I need
>
> The robustness of the JVM is pretty good. It makes a big difference
> if 900.000 people test software or if it’s 621.
> Interfacing is excellent. As Java is not a multi-paradigm language
> there exists more or less one way to do things. The consequence is that
> most libs work perfectly with each other. Typically no problems such as:
> “Oh, this does not work in my implementation/version”.
My experience is different. Yes, I have worked with Java developers.
> > * support for debugging
>
> There exist plenty debuggers that you can attach to your JVM.
> I use JSwat which allows me to step through my Clojure programs line by
> line, with break points and all that stuff.
>
> > * tool support (low level debugger, performance tools, ...)
>
> The tool support for the JVM is fantastic.
> Very nice profiler:http://www.yourkit.com/features/index.jsp
>
> The NetBeans GUI builder is way more advanced than everything I have
> seen so far. I know the GUI builders from Borland C++, Lispworks,
> Allegro and Visual Studio.
>
> There are tools for byte code obfuscation, for visualization, and and and.
> And what is also so nice is that it does not longer matter under what
> OS you are developing in a team. In principle some of my workmates could
> use OSX while I work under Windows Vista. Some others may prefer Open
> Solaris.
>
> >> While I understand your explanations and appreciate that you took your
> >> time to answer it, I still keep my opinion, that the statement of
> >> Slobodan was nonsense in this case.
> >> The very problem lies in the relativeness of the word “better”.
> >> He states it as if he talks about a fact. But it was just an opinion as
> >> I see it.
>
> > You still have to say what is important for you that sums up into
> > 'better'. If it is performance, that can be checked by benchmark
> > suites and application benchmarks. If it is something more
> > 'soft' like 'the implementor could reuse the JVM GC' say it.
>
> I gave mostly examples of what I like in the Java plattform (not the
> language).
> What I like about Clojure is basically what you already mentioned:
> clean and together with Erlang and Haskell probably the best language
> for concurrency. What I also like very much is the functional flair
> and the nice reader macros for accessing the most typical data structures.
>
> > That fact remains that the performance of a Lisp on the JVM might
> > be GOOD ENOUGH. Lots of software has been written with much
> > slower platforms. I would not argue that the JVM provides
> > the best performance, that's likely not the case. But it provides
> > enough performance that Lisp can run on top of it (various Schemes,
> > ABCL, Clojure, ...). It's better for you if it provides
> > the features that YOU need to write applications.
>
> I think it was Rich Hickey himself who said that Clojure is currently
> the most performant dynamic language for the JVM.
>
> > The best thing to show off Clojure is to write software
> > with it and announce it here. What are you writing?
>
> Would be nice yes, but I can’t make announcements about it here, because
> it is confidential. I just can say that I am writing Clojure code nearly
> every day.
> It just is mostly for professional use and I don’t want to talk about it
> here. One thing that I would like to do soon though is to port my system
> for Genetic Programming to Clojure.
> This is more for fun, and I think I will concentrate for performance
> reasons to continue developing it under SBCL. GP is absolutely trivially
> parallelizable, so I won’t have any problems. Clojure is nice for helping
> in hard problems. But GP can be done so easy that the penalty hit of
> using Clojure is most likely too big.
penalty hit???
> I can’t say it for sure yet as I
> will have to wait and see the results. It is just a guess now (but a not
> so badly informed one).
>
> > That's the stuff I find much more interesting. Users with
> > applications.
>
> If you allow me to add: applications about which the users can talk. ;-)
> I do both, Lispworks and Clojure. Not talking about it doesn’t mean it
> does not happen.
Let us know about it when you are allowed to tell something...
>
> André
> --
······@corporate-world.lisp.de wrote:
> On Jan 16, 1:47 am, André Thieme <address.good.until.
> ···········@justmail.de> wrote:
>>
>> The JVM can potentially outperform native compilers.
>> During runtime it can find out information that allows it to rearrange
>> and rewrite the code in such a way that it will perform better.
>> This can’t be known as long the program is not running.
>> Common Lisp could do the same as well in principle, as (compile ..) is
>> available during runtime too. But to my knowledge there is currently no
>> thing as the JVMs HotSpot for any CL. At least in Lispworks Pro it’s not
>> available, and when I worked with Allegro Enterprise one year ago it
>> also did not have such a thing.
>
> 'Could'. Does it? Currently I haven't seen a JVM based Lisp
> outperforming native code compilers. Show one and present your findings on
> some Lisp conference/meeting.
Start with programs that allocate heavily from multiple threads.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
BTW this is my latest interaction with JVM, Windows Server 2003 R2
Quad Core, 4 GB RAM, NVIDIA GeForce 7300 GT . I decided to try Clojure
so I downloaded it, unzipped and at it didn't wanted to start and my
system locked COMPLETELY so I had to do a hard reboot. Ok maybe my
version was outdated java 6 Update 7 so I tried to uninstall it, and
once again my system locked COMPLETELY so I had to do another hard
reboot. Ok maybe it doesn't want to uninstall old versions so I
installed latest Update 11, tested via http://www.java.com/en/download/help/testvm.xml,
which said that everything is Ok so I started Clojure again and guess
what? It locked again. F**hen 4 Hard reboots later I'm damn sure that
I don't want lisp to move toward JVM, ever. And I don't give a damn
how advanced Sun claimed to be. Damn thing is unreliable resource
hog.
bobi
Slobodan Blazeski schrieb:
> BTW this is my latest interaction with JVM, Windows Server 2003 R2
> Quad Core, 4 GB RAM, NVIDIA GeForce 7300 GT . I decided to try Clojure
> so I downloaded it, unzipped and at it didn't wanted to start and my
> system locked COMPLETELY so I had to do a hard reboot. Ok maybe my
> version was outdated java 6 Update 7 so I tried to uninstall it, and
> once again my system locked COMPLETELY so I had to do another hard
> reboot. Ok maybe it doesn't want to uninstall old versions so I
> installed latest Update 11, tested via http://www.java.com/en/download/help/testvm.xml,
> which said that everything is Ok so I started Clojure again and guess
> what? It locked again. F**hen 4 Hard reboots later I'm damn sure that
> I don't want lisp to move toward JVM, ever. And I don't give a damn
> how advanced Sun claimed to be. Damn thing is unreliable resource hog.
Some thousand users of Clojure managed to install Java and Clojure.
Either they all did something wrong or...
Millions of people managed to install Java on Win 2003.
Billions of installations of Java were made in the past decade.
But honestly, I had a computer in early November which had hardware error.
I discoverd it during the installation of Java. The machine crashed
without warning at some point during the insallation.
On the 8 boxes it worked perfectly, of course, without any problems.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Jan 16, 9:49 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Slobodan Blazeski schrieb:
>
> > BTW this is my latest interaction with JVM, Windows Server 2003 R2
> > Quad Core, 4 GB RAM, NVIDIA GeForce 7300 GT . I decided to try Clojure
> > so I downloaded it, unzipped and at it didn't wanted to start and my
> > system locked COMPLETELY so I had to do a hard reboot. Ok maybe my
> > version was outdated java 6 Update 7 so I tried to uninstall it, and
> > once again my system locked COMPLETELY so I had to do another hard
> > reboot. Ok maybe it doesn't want to uninstall old versions so I
> > installed latest Update 11, tested viahttp://www.java.com/en/download/help/testvm.xml,
> > which said that everything is Ok so I started Clojure again and guess
> > what? It locked again. F**hen 4 Hard reboots later I'm damn sure that
> > I don't want lisp to move toward JVM, ever. And I don't give a damn
> > how advanced Sun claimed to be. Damn thing is unreliable resource hog.
>
> Some thousand users of Clojure managed to install Java and Clojure.
> Either they all did something wrong or...
>
> Millions of people managed to install Java on Win 2003.
> Billions of installations of Java were made in the past decade.
>
> But honestly, I had a computer in early November which had hardware error.
> I discoverd it during the installation of Java. The machine crashed
> without warning at some point during the insallation.
> On the 8 boxes it worked perfectly, of course, without any problems.
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
I have never seen so much broken and bad software until I was forced
to do some Java stuff in previous work. Any language whose *main*
selling point is to seamlessly inter operate with such software is by
definition uninteresting.
On Jan 16, 9:49 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Slobodan Blazeski schrieb:
>
> > BTW this is my latest interaction with JVM, Windows Server 2003 R2
> > Quad Core, 4 GB RAM, NVIDIA GeForce 7300 GT . I decided to try Clojure
> > so I downloaded it, unzipped and at it didn't wanted to start and my
> > system locked COMPLETELY so I had to do a hard reboot. Ok maybe my
> > version was outdated java 6 Update 7 so I tried to uninstall it, and
> > once again my system locked COMPLETELY so I had to do another hard
> > reboot. Ok maybe it doesn't want to uninstall old versions so I
> > installed latest Update 11, tested viahttp://www.java.com/en/download/help/testvm.xml,
> > which said that everything is Ok so I started Clojure again and guess
> > what? It locked again. F**hen 4 Hard reboots later I'm damn sure that
> > I don't want lisp to move toward JVM, ever. And I don't give a damn
> > how advanced Sun claimed to be. Damn thing is unreliable resource hog.
>
> Some thousand users of Clojure managed to install Java and Clojure.
> Either they all did something wrong or...
>
> Millions of people managed to install Java on Win 2003.
> Billions of installations of Java were made in the past decade.
>
> But honestly, I had a computer in early November which had hardware error.
> I discoverd it during the installation of Java. The machine crashed
> without warning at some point during the insallation.
> On the 8 boxes it worked perfectly, of course, without any problems.
Even more, as a bonus for downloading and installing the JRE you
get the MSN toolbar for free!
http://www.microsoft.com/presspass/press/2008/nov08/11-10LiveJREMPR.mspx
http://blogs.msdn.com/livesearch/archive/2008/11/11/sun-shines-on-the-msn-toolbar.aspx
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
······@corporate-world.lisp.de schrieb:
> On Jan 16, 1:47 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>
>> The JVM can potentially outperform native compilers.
>> During runtime it can find out information that allows it to rearrange
>> and rewrite the code in such a way that it will perform better.
>> This can�t be known as long the program is not running.
>> Common Lisp could do the same as well in principle, as (compile ..) is
>> available during runtime too. But to my knowledge there is currently no
>> thing as the JVMs HotSpot for any CL. At least in Lispworks Pro it�s not
>> available, and when I worked with Allegro Enterprise one year ago it
>> also did not have such a thing.
>
> 'Could'. Does it? Currently I haven't seen a JVM based Lisp
> outperforming
> native code compilers. Show one and present your findings on some
> Lisp conference/meeting.
Well, on December 11th I gave you the results of my timings of your code.
It was this (incorrect or not correctly named) find-factors function:
> (defun find-factors (number)
> (loop with i = 2
> when (zerop (rem number i)) do (format t "~a " i)
> while (<= (incf i) (truncate number i))))
> CL-USER 48 > (time (find-factors 600851475143))
> Timing the evaluation of (FIND-FACTORS 600851475143)
> 71 839 1471 6857 59569 104441 486847
> User time = 0.076
> System time = 0.001
> Elapsed time = 0.063
> Allocation = 112888 bytes
> 20 Page faults
> NIL
In my Lispworks Professional 32-Bit version it took 400 msecs.
The 64-Bit version is much faster, as you showed.
But still, on my machine SBCL could do it within 200 msecs, also 32-Bit.
My Clojure program took around 105 msecs and the Java code did the job
in 16 msecs.
http://groups.google.de/group/comp.lang.lisp/msg/261d4df228270ce3
So, I have seen the JVM outperforming two different native Lisp
compilers. At least this one example exists.
But I and my colleagues did other timings as well. Yes, mostly micro
benchmarks and we don�t want to conclude too much from that.
Obviously noone will pay us to write big projects and compare them.
One could compare AllegroServe vs Tomcat or Jetty, although Tomcat can
do much more, so the comparison would not be really fair.
Maybe next week I�ll find some time to test cryptography performance
and xml-rpc servers, etc.
So you think people on Lisp conferences would be interested in a list
of tasks in which the JVM outperforms CL compilers?
Anyway, I think for several tasks Clojure can still be less efficient
than Lisp. One reason is that the core data structures are immutable
and can�t always make changes in place.
This is obviously much better for concurrent applications. Clojures
data structures perform well in such an environment. Most of the time
no full copying needs to be done. Also there is this nice transaction
system with automatic retries. In CL one would probably use locks
to protect mutable ressources. So, back in single-core land.
> Last time I looked, SUNs JVM implementation was not the fastest.
Can you suggest which one I could use? Which is the fastest?
I would like to run my tests in that JVM then.
>>> But there is different hardware. There are lots of Intel-PCs running
>>> Windows, Mac OS, some kind of Unix/Linux, ... That's a platform.
>>> Not special hardware that does not exist and likely will not
>>> exist soon.
>> Although in my opinion those are the plattforms of the past.
>
> Really? Java can't open a file without those. Not even does
> it get a keypress or can display a window without those.
Yes. Like the VMs of CL.
> Last I looked Java and its infrastructure did not
> do too well for general purpose client applications.
Could you please tell me more about that?
I am not really into making general purpose client apps.
Some small swing GUIs, nothing spectecular.
If I would need it, CRUD is available for me in NetBeans:
http://www.netbeans.org/kb/60/java/swing-app-beans-binding-screencast.html
(create, read, update, delete)
> I see companies developing special inhouse apps in Java,
Yes, I am currently doing this, although that is not my
main focus. And I don�t do it in Java but in Clojure.
But I use the NetBeans GUI Builder and write one-liners
(for handling events) directly in Java then. No big deal.
>> At least for me it makes much more sense to target a plattform that
>> abstracts the operating system and hardware away.
>
> For the client this is often the browser plus Javascript.
> That's the platform. On the server it does not matter much.
On the server the JVM is pretty strong.
For the client side in the browser Java has nice offerings.
Nice libs that abstract a lot of the Javascript away.
JavaFX is now coming and maybe has a chance to get a little bit
market share against Flash.
For Lisp it is unfortunately not looking so good.
Some webdevelopment frameworks with nearly no documentation, and
often technically not very up-to-date anymore.
Only a few days ago a colleague and I were trying to find a SOAP
server that runs under Lispworks, or a REST server.
But in NetBeans+Clojure it�s trivial:
http://www.netbeans.org/kb/docs/websvc/rest.html
(there are pictures for those who don�t want to read)
> Great.
Yes.
> So your application benefits from that?
Sure.
> Anything to report?
No, not for the public.
>>>> One can list several advantages that the JVM offers and from there
>>>> conclude that Lisp �just works better� on the JVM.
>>> Why not go the route and list the advantages? I have listed some
>>> above. What else?
>> * easy to target many kinds of hardware (32/64 Bit, amd, sun, intel,
>> mobile phone, tv, ...) and operating systems (Win, Lin, osx, Android,
>> Unix)
>> * tons of libs available in the JVM (I think more than for anything
>> else). Nothing improves productivity more than having the lib that
>> does the job.
>
> I'm pretty sure that there is more code in C and compatible with C
> calling semantics.
I am not so sure. Possible though.
But if I try to imagine who many billions lines of code were written in
the past decade in Java...
> Why is the jar so large?
Images and some other 3rd party libs/dependencies.
> Yeah, and SBCL calls C code or assembler where needed.
The JVM can do the same.
But as Java is often not far away from C it does not really matter too
much. Plus that the JVM is still far from having reached it�s max
performance. Sun was able to constantly improve the JVM performance.
One could compare the man-hours per year that go into improvements of
the JVM and all accumulated man-hours per year that go into Allegro,
Lispworks, sbcl, cmucl, clisp and Corman Lisp.
>> This is more for fun, and I think I will concentrate for performance
>> reasons to continue developing it under SBCL. GP is absolutely trivially
>> parallelizable, so I won�t have any problems. Clojure is nice for helping
>> in hard problems. But GP can be done so easy that the penalty hit of
>> using Clojure is most likely too big.
>
> penalty hit???
In this context I meant the speed-disadvantage of using persistent data
structures. Plus that all clojure code always gets compiled.
For several cases this is not wanted in GP.
I�ll have to see how it will actually perform.
But for now I think I�m better off with sbcl.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Jan 16, 11:45 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> ······@corporate-world.lisp.de schrieb:
>
>
>
> > On Jan 16, 1:47 am, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
>
> >> The JVM can potentially outperform native compilers.
> >> During runtime it can find out information that allows it to rearrange
> >> and rewrite the code in such a way that it will perform better.
> >> This can’t be known as long the program is not running.
> >> Common Lisp could do the same as well in principle, as (compile ..) is
> >> available during runtime too. But to my knowledge there is currently no
> >> thing as the JVMs HotSpot for any CL. At least in Lispworks Pro it’s not
> >> available, and when I worked with Allegro Enterprise one year ago it
> >> also did not have such a thing.
>
> > 'Could'. Does it? Currently I haven't seen a JVM based Lisp
> > outperforming
> > native code compilers. Show one and present your findings on some
> > Lisp conference/meeting.
>
> Well, on December 11th I gave you the results of my timings of your code.
> It was this (incorrect or not correctly named) find-factors function:
>
> > (defun find-factors (number)
> > (loop with i = 2
> > when (zerop (rem number i)) do (format t "~a " i)
> > while (<= (incf i) (truncate number i))))
>
> > CL-USER 48 > (time (find-factors 600851475143))
> > Timing the evaluation of (FIND-FACTORS 600851475143)
> > 71 839 1471 6857 59569 104441 486847
> > User time = 0.076
> > System time = 0.001
> > Elapsed time = 0.063
> > Allocation = 112888 bytes
> > 20 Page faults
> > NIL
>
> In my Lispworks Professional 32-Bit version it took 400 msecs.
> The 64-Bit version is much faster, as you showed.
The 64bit version is faster, but maybe my computer is also faster
running
LispWorks 32bit?
> But still, on my machine SBCL could do it within 200 msecs, also 32-Bit.
> My Clojure program took around 105 msecs and the Java code did the job
> in 16 msecs.http://groups.google.de/group/comp.lang.lisp/msg/261d4df228270ce3
Your program did something different. Either I write a equivalent
version
of your code, or you write an equivalent version of my code.
> So, I have seen the JVM outperforming two different native Lisp
> compilers. At least this one example exists.
It does different things.
...
> So you think people on Lisp conferences would be interested in a list
> of tasks in which the JVM outperforms CL compilers?
That would be very interesting to see. Definitely a good paper
for a Lisp conference/meeting/symposium.
> Anyway, I think for several tasks Clojure can still be less efficient
> than Lisp. One reason is that the core data structures are immutable
> and can’t always make changes in place.
> This is obviously much better for concurrent applications. Clojures
> data structures perform well in such an environment. Most of the time
> no full copying needs to be done. Also there is this nice transaction
> system with automatic retries. In CL one would probably use locks
> to protect mutable ressources. So, back in single-core land.
A lock does not mean that one is in single-core land. A lock
would mean that only one thread could change a certain data
object at any one time (and all reads have to wait until
the change is done). Other threads could still
be doing something different. LOCKs are not WITHOUT-INTERRUPTS
or WITHOUT-PREEMPTION.
> > Last time I looked, SUNs JVM implementation was not the fastest.
>
> Can you suggest which one I could use? Which is the fastest?
> I would like to run my tests in that JVM then.
Last I looked, which is some time ago, for example IBMs implementation
was much faster for some apps. Or BEA's JRockit. At that time
my experts said that SUN's JVM was not competitive speedwise
on x86 architectures (Intel, AMD).
> > Last I looked Java and its infrastructure did not
> > do too well for general purpose client applications.
>
> Could you please tell me more about that?
I haven't seen that many client application using Java (besides the
Java IDEs
and inhouse apps).
I haven't seen a rush lately. At Apple for example the Cocoa UI
interface
for Java is no longer developed...
> I am not really into making general purpose client apps.
> Some small swing GUIs, nothing spectecular.
> If I would need it, CRUD is available for me in NetBeans:http://www.netbeans.org/kb/60/java/swing-app-beans-binding-screencast...
> (create, read, update, delete)
>
> > I see companies developing special inhouse apps in Java,
>
> Yes, I am currently doing this, although that is not my
> main focus. And I don’t do it in Java but in Clojure.
> But I use the NetBeans GUI Builder and write one-liners
> (for handling events) directly in Java then. No big deal.
Another topic for a presentation at a Lisp meeting/conference/...
> >> At least for me it makes much more sense to target a plattform that
> >> abstracts the operating system and hardware away.
>
> > For the client this is often the browser plus Javascript.
> > That's the platform. On the server it does not matter much.
>
> On the server the JVM is pretty strong.
Yep.
> For the client side in the browser Java has nice offerings.
> Nice libs that abstract a lot of the Javascript away.
> JavaFX is now coming and maybe has a chance to get a little bit
> market share against Flash.
> For Lisp it is unfortunately not looking so good.
> Some webdevelopment frameworks with nearly no documentation, and
> often technically not very up-to-date anymore.
> Only a few days ago a colleague and I were trying to find a SOAP
> server that runs under Lispworks, or a REST server.
> But in NetBeans+Clojure it’s trivial:http://www.netbeans.org/kb/docs/websvc/rest.html
> (there are pictures for those who don’t want to read)
Makes sense.
...
> > I'm pretty sure that there is more code in C and compatible with C
> > calling semantics.
>
> I am not so sure. Possible though.
> But if I try to imagine who many billions lines of code were written in
> the past decade in Java...
Nah. Much of the stuff written in Java is inhouse apps (minus the
mobile phone stuff).
Many of the libraries also have died already or are on life support.
SAP now pays SUN money to maintain an old JDK, because they
can't or don't want to port their code to newer JDKs.
The reusable infrastructure is smaller compared to C. Neither Windows,
Linus, Mac OS X,
FreeBSD have useful infrastructure (file system, scheduler, window
system,
graphics driver, OpenGL, DirectX, web browser, ...) written in Java.
All the Java stuff is on top of what the OS offers. Microsoft has the
CLR.
Apple uses C/Objective C.
Example: if I want to write a CAD system in Lisp, the JVM does not
give me
any advantage. I can use the OpenGL lib directly from Lisp. Moving
Lisp
to the JVM and interfacing OpenGL from there? Why?
..
> But as Java is often not far away from C it does not really matter too
> much. Plus that the JVM is still far from having reached it’s max
> performance. Sun was able to constantly improve the JVM performance.
> One could compare the man-hours per year that go into improvements of
> the JVM and all accumulated man-hours per year that go into Allegro,
> Lispworks, sbcl, cmucl, clisp and Corman Lisp.
Yes, and some investment should pay back. But it was necessary,
because
the JVM infrastructure is generally bringing a speed penalty.
Unless one is doing something against it, interpreting an
instruction set on top of a processor is slower than
compiling directly for the processor. Then one needs
JIT compilers, but they also have a difficult job.
A whole-program or file compiler can do more optimizations than
a JIT compiler that compiles batches of VM instructions.
Then there is a startup penalty, because the JIT compiler compiles
code upon startup. To work against that one needs to
add another phase where the code gets precompiled.
Then there is the problem that in Lisp one tends to
do also compile time code generation or code replacement.
Then the JIT compiler has do something against filling its caches.
But the focus for (Common) Lisp is different. Java and the JVM
are there to support static imperative OO. The JVM was
not designed to be a general purpose VM, but a VM
specially targetted at Java. Lisp is there
to support dynamic multi-paradigm code. I tend to run much
of my code unoptimized with full safety, full debug infos,
full interactivity, etc. The JVM was not built to support
that. You can load code in Java, unloading it is already more
difficult...
...
> In this context I meant the speed-disadvantage of using persistent data
> structures. Plus that all clojure code always gets compiled.
> For several cases this is not wanted in GP.
> I’ll have to see how it will actually perform.
> But for now I think I’m better off with sbcl.
Again, think about presenting some of your findings...
On 2009-01-15, André Thieme <······························@justmail.de> wrote:
> Kaz Kylheku schrieb:
>> On 2009-01-14, André Thieme <······························@justmail.de> wrote:
>>> Slobodan Blazeski schrieb:
>>>
>>>> They aren't Greenspunning, lisp is just working better under it's own
>>>> VM than JVM.
>>> Um, can you please explain more about this?
>>> This seems to me like the statement that Lisp programs run faster if the
>>> guy who wrote them has brown eyes.
>>
>> There is a big semantic gap between what Lisp requires and the JVM.
>>
>> The JVM is designed to support the C-like semantics of Java (Von-Neumann-style
>> computing based on manipulating word-sized quantities), while outlawing the
>> low-level memory twiddling supported by real C.
>>
>> Lisp works best when you can target the machine directoy and take advantage of
>> the freedom of the machine langauge to design your own types.
>>
>> In the JVM, how do you pack extra bits into a pointer to indicate type?
>>
>> I can do that in just about any assembly language easily, without violating any
>> instruction set architecture spec.
>>
>> I can do that in C---by violating ANSI C, true, but in a way that's still
>> portable to many compilers.
>>
>> How do you write a function for the JVM where the argument can be a 32 bit word
>> that could either be a pointer to an object, or, say, a 31 bit integer?
>
> Okay, I see that I understood the word better in the usual context,
> but you (and others) read something different, that tends into the
> direction of efficiency.
> Better means for me, that (+ 7 3) returns a stronger 10. One that shines
If we are targetting native hardware, Lisp has no disadvantage.
If we are targetting the JVM, Lisp has a definite disadvantage compared
to the kinds of programming languages for which the JVM is designed as
a back end.
Someone cynical might remark that the JVM is deliberately designed that way to
stifle competition to Java from other kinds of programming languages.
There is a big difference between some performance disadvantage that comes as a
result of making a tradoff of your own choosing, versus one that is shoved down
your throat by the platform.
How you design the basic representation of fundamental types isn't some ``oh
well'' optimization question. You have to settle that before doing anything
else.
> a bit more, while a (+ 7 3) sometimes could be more like a 9.
What?
> You gave examples of how an implementation of Lisp might require more
> memory.
More memory and more execution time.
> Yes, I agree that this is very possible. The implementor of that
> Lisp is
... hogtied by platform.
> I just see that Clojure works very good. Some people would even argue,
Clojure will be of greater interest to me when its ANSI Lisp support becomes
more mature. Right now, that part of Clojure doesn't work so well.
Kaz Kylheku wrote:
> On 2009-01-15, André Thieme <······························@justmail.de>
> wrote:
>> You gave examples of how an implementation of Lisp might require more
>> memory.
>
> More memory and more execution time.
There is overwhelming evidence to the contrary: the was disproven years ago.
>> Yes, I agree that this is very possible. The implementor of that
>> Lisp is
>
> ... hogtied by platform.
Pure fantasy.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Jan 15, 6:50 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Okay, I see that I understood the word “better” in the usual context,
No you don't understand anything, grab a copy of SICP or Art of
Interpreter and write one for yourself. Naive implementation is only a
weekend of work.
> but you (and others) read something different, that tends into the
> direction of efficiency.
> Better means for me, that (+ 7 3) returns a stronger 10. One that shines
> a bit more, while a (+ 7 3) sometimes could be more like a 9.
>
> You gave examples of how an implementation of Lisp might require more
> memory. Yes, I agree that this is very possible. The implementor of that
> Lisp is not as free as if he could work on the pure metal.
> But this argument could be taken forward to the question why not
> implementing Lisp in hardware? This could give you even more freedom.
> You don’t have to live with the descision of the hardware producers.
> Why does a Byte consist of 8 bits? Why not having a FPU that internally
> works with 297 bit numbers, instead of 32?
> So:
> “Lisp is working better if it was built in hardware, not software”.
>
> I just see that Clojure works very good. Some people would even argue,
> that it works “better” than CL, whatever “better” means. And Clojure
> runs on a JVM and is without a doubt Lisp. ABCL also compiles to the
> code. So, it obviously is possible.
From http://common-lisp.net/project/armedbear/ if situation improved
please correct me:
ABCL's CLOS is intolerably slow and does not handle on-the-fly
redefinition of classes correctly. There is no support for the long
form of DEFINE-METHOD-COMBINATION, and certain other required CLOS
features are also missing. Enough CLOS is there to run ASDF and CL-
PPCRE, if you're in no hurry. There's no MOP worth mentioning.
Landrover engine is possible in Porche and Kia, but it's not a right
thing.
>
> One could argue, that it is much easier to implement a GC. This can be
> done in about zero seconds, because there already is one.
Not all GC are made the same.Plugging existing Gc like Boehm
http://en.wikipedia.org/wiki/Boehm_garbage_collector brings
constraints that might or might not be acceptable:
For example from the author of Ypsilon scheme, very cool
implementation of r6rs:
For example, we can not use Boehm Garbage Collector, which doesn't
support†game consoles or arcade games, as we also develop games for
such machines. Also, we cannot depend on Java, VisualBasic, or C#.
Therefore, all existing implementations were out of consideration. So,
I decided to develop a new original implementation. It is Ypsilon.
http://www.littlewingpinball.com/contents/en/ypsilon.html
> One can list several advantages that the JVM offers and from there
> conclude that Lisp “just works better” on the JVM.
According to http://common-lisp.net/~dlw/LispSurvey.html only one
implementation Armed Bear works on JVM. So the majority of common lisp
users think that JVM is bad idea, though there are some users who
prefer it. So if you're member of the JVM camp good for your, enjoy
Clojure or ABCL or whatever works for you. But the rest of us
disagree.
bobi
On Jan 16, 9:51 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jan 15, 6:50 pm, André Thieme <······························@justmail.de> wrote:
> > Okay, I see that I understood the word “better” in the usual context,
>
> No you don't understand anything, grab a copy of SICP or Art of
> Interpreter and write one for yourself. Naive implementation is only a
> weekend of work.
>
>
>
>
>
> > but you (and others) read something different, that tends into the
> > direction of efficiency.
> > Better means for me, that (+ 7 3) returns a stronger 10. One that shines
> > a bit more, while a (+ 7 3) sometimes could be more like a 9.
>
> > You gave examples of how an implementation of Lisp might require more
> > memory. Yes, I agree that this is very possible. The implementor of that
> > Lisp is not as free as if he could work on the pure metal.
> > But this argument could be taken forward to the question why not
> > implementing Lisp in hardware? This could give you even more freedom.
> > You don’t have to live with the descision of the hardware producers.
> > Why does a Byte consist of 8 bits? Why not having a FPU that internally
> > works with 297 bit numbers, instead of 32?
> > So:
> > “Lisp is working better if it was built in hardware, not software”.
>
> > I just see that Clojure works very good. Some people would even argue,
> > that it works “better” than CL, whatever “better” means. And Clojure
> > runs on a JVM and is without a doubt Lisp. ABCL also compiles to the
> > code. So, it obviously is possible.
>
> Fromhttp://common-lisp.net/project/armedbear/if situation improved
> please correct me:
> ABCL's CLOS is intolerably slow and does not handle on-the-fly
> redefinition of classes correctly. There is no support for the long
> form of DEFINE-METHOD-COMBINATION, and certain other required CLOS
> features are also missing. Enough CLOS is there to run ASDF and CL-
> PPCRE, if you're in no hurry. There's no MOP worth mentioning.
>
> Landrover engine is possible in Porche and Kia, but it's not a right
> thing.
>
> > One could argue, that it is much easier to implement a GC. This can be
> > done in about zero seconds, because there already is one.
>
> Not all GC are made the same.Plugging existing Gc like Boehmhttp://en.wikipedia.org/wiki/Boehm_garbage_collectorbrings
> constraints that might or might not be acceptable:
> For example from the author of Ypsilon scheme, very cool
> implementation of r6rs:
>
> For example, we can not use Boehm Garbage Collector, which doesn't
> support†game consoles or arcade games, as we also develop games for
> such machines. Also, we cannot depend on Java, VisualBasic, or C#.
> Therefore, all existing implementations were out of consideration. So,
> I decided to develop a new original implementation. It is Ypsilon.http://www.littlewingpinball.com/contents/en/ypsilon.html> One can list several advantages that the JVM offers and from there
> > conclude that Lisp “just works better” on the JVM.
>
> According tohttp://common-lisp.net/~dlw/LispSurvey.htmlonly one
> implementation Armed Bear works on JVM. So the majority of common lisp
> users think that JVM is bad idea, though there are some users who
> prefer it. So if you're member of the JVM camp good for your, enjoy
> Clojure or ABCL or whatever works for you. But the rest of us
> disagree.
>
> bobi
One more thing to add from Rich Hickey video 14:00
..It (Clojure) does not have proper tail call optimization . And
that's because JVM doesn't support it and Clojure uses JVM calling
both for performace and interoperability.
http://blip.tv/file/812787?filename=Richhickey-ClojureConcurrency252.flv
So next time you blow up your stack, thanks the JVM for that.
bobi
Slobodan Blazeski schrieb:
> On Jan 16, 9:51 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>> On Jan 15, 6:50 pm, Andr� Thieme <······························@justmail.de> wrote:
>>> Okay, I see that I understood the word �better� in the usual context,
>> No you don't understand anything, grab a copy of SICP or Art of
>> Interpreter and write one for yourself. Naive implementation is only a
>> weekend of work.
>> bobi
> One more thing to add from Rich Hickey video 14:00
> ..It (Clojure) does not have proper tail call optimization . And
> that's because JVM doesn't support it and Clojure uses JVM calling
> both for performace and interoperability.
> http://blip.tv/file/812787?filename=Richhickey-ClojureConcurrency252.flv
>
> So next time you blow up your stack, thanks the JVM for that.
For someone who accuses others of not understanding anything one could
think you would try to optimize your own knowledge base.
While it is true that the current version of the JVM does not support
tail calls, it does not mean that you constantly run into stack over-
flows.
Clojure offers several mechanisms to go in most cases around that
problem, as (recur ...) or trampolines.
Also keep in mind that Sun is working on Fortress, which will most
likely lead to built in TC support in the JVM.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
André Thieme wrote:
> While it is true that the current version of the JVM does not support
> tail calls, it does not mean that you constantly run into stack over-
> flows.
> Clojure offers several mechanisms to go in most cases around that
> problem, as (recur ...) or trampolines.
Lack of tail calls is an absolutely crippling problem. For example, the
developers of the Scala compiler have dozens of bugs filed against the
compiler from it stack overflowing precisely because it cannot support tail
calls (with reasonable efficiency) because the JVM lacks tail calls.
However, as long as you are restricting yourself to Common Lisp you are not
assured tail calls anyway.
> Also keep in mind that Sun is working on Fortress, which will most
> likely lead to built in TC support in the JVM.
Sun have been "working on" many things for many years and produced nothing
worth having. I for one am not pinning my hopes on anything done by Sun,
not least because they are going bankrupt and just laid off many thousands
of employees (again).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gktqup$5ga$1@news.motzarella.org>
Jon Harrop schrieb:
> André Thieme wrote:
>> Also keep in mind that Sun is working on Fortress, which will most
>> likely lead to built in TC support in the JVM.
>
> Sun have been "working on" many things for many years and produced nothing
> worth having. I for one am not pinning my hopes on anything done by Sun,
> not least because they are going bankrupt and just laid off many thousands
> of employees (again).
They are in the lead though.
One or two decades before Microsoft they had an OS that did not crash daily.
The JVM came out years before Microsoft had anything to offer. So, it
proves where the creative people sit.
And also Microsoft is now planning to lay off some thousand employees.
It will probably not the 15.000 about some blogs talked at first, but
still enough. Google bets on Java and uses its billions against Microsoft.
And the fast .NET still is not available for Linux and Mac.
It will force you to have a Windows server system, for which the
license costs are high enough. On top of that, the JVM is already open
sourced, so in the case that Sun loses it can be continued to develop.
If that should not happen, which is extremly unlikely with Java being
the most popular language in the world, that’s still not too bad for
Clojure programmers, as Clojure would simply get an implementation on
the then leading VM.
As a fast google search prooves, Java is about 340% more popular than
C#: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
So, this is a clear indication for people who like to draw conclusions
from google searches about popularity to find out which is the right way.
Uh.. wait a minute...
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On 18 Jan., 00:51, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Jon Harrop schrieb:
>
> > André Thieme wrote:
> >> Also keep in mind that Sun is working on Fortress, which will most
> >> likely lead to built in TC support in the JVM.
>
> > Sun have been "working on" many things for many years and produced nothing
> > worth having. I for one am not pinning my hopes on anything done by Sun,
> > not least because they are going bankrupt and just laid off many thousands
> > of employees (again).
>
> They are in the lead though.
> One or two decades before Microsoft they had an OS that did not crash daily.
> The JVM came out years before Microsoft had anything to offer. So, it
> proves where the creative people sit.
> And also Microsoft is now planning to lay off some thousand employees.
> It will probably not the 15.000 about some blogs talked at first, but
> still enough. Google bets on Java and uses its billions against Microsoft.
Java, but not the JVM.
http://en.wikipedia.org/wiki/Dalvik_virtual_machine
> And the fast .NET still is not available for Linux and Mac.
> It will force you to have a Windows server system, for which the
> license costs are high enough. On top of that, the JVM is already open
> sourced, so in the case that Sun loses it can be continued to develop.
> If that should not happen, which is extremly unlikely with Java being
> the most popular language in the world, that’s still not too bad for
> Clojure programmers, as Clojure would simply get an implementation on
> the then leading VM.
> As a fast google search prooves, Java is about 340% more popular than
> C#:http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> So, this is a clear indication for people who like to draw conclusions
> from google searches about popularity to find out which is the right way.
> Uh.. wait a minute...
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
On Jan 17, 3:51 pm, André Thieme wrote:
> They [Sun Microsystems] are in the lead though.
> One or two decades before Microsoft they had an OS that did not crash daily.
Lol. Where did you read your history? Slashdot?
Sun's OSes, and unixes in general, are the most crash prone, insecure,
fucked up OS there exists in history.
In fact, the original unix mantra is to favor crash, with fast reboot.
What the unix fuckheads are aware usually, is to compare unixes aged
at 20, to Microsoft's OS aged at 5 or 10 (e.g. Windows pre NT during
late 1990s). Then they say unixes is better. Better fuck their
assholes.
• Fast Food the Unix way
http://xahlee.org/UnixResource_dir/_fastfood_dir/fastfood.html
Xah
∑ http://xahlee.org/
☄
From: Maxwell Lol
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <87iqocg2pi.fsf@com.invalid>
Xah Lee <······@gmail.com> writes:
> Sun's OSes, and unixes in general, are the most crash prone, insecure,
> fucked up OS there exists in history.
I used Solaris for 15 years, and that is not my experience.
At one point my site had 1000 sun workstations.
I think I only experienced a kernel panic 1 or 2 times.
"Maxwell Lol" <······@com.invalid> wrote in message
···················@com.invalid...
> Xah Lee <······@gmail.com> writes:
>
> > Sun's OSes, and unixes in general, are the most crash prone, insecure,
> > fucked up OS there exists in history.
>
>
> I used Solaris for 15 years, and that is not my experience.
> At one point my site had 1000 sun workstations.
> I think I only experienced a kernel panic 1 or 2 times.
With 35 years in computers, 25 of that on UNIX, 10 years in mainframes.
I will say these points:
1. I had a customer with a complaint that his computer didn't work. Once
on site, he didn't even know where it was. We started at the failing
terminal, chased the cord through ceilings to another floor and into a
hot, filthy, stinking closet. We removed piles of old news papers and
magazines stored on top of the computer. I cleaned it, cooled it, and
after running 18 years, it was running again. That is UNIX.
2. Next, I was responsible for many UNIX systems for many years. My
"team" divided the systems. My systems were cleaned (maintained),
patched, and powered properly. On the other hand, my team did not
do what I did. The sat on their butts, complained to the boss, and got
many rewards. My systems ran without failures - totally. The team's
ran with constant outages and reported problems.
Fix your systems, patch to the latest level, and UNIX will run. If a
patch breaks something, remove it, call support, get a new patch.
Now, to the real world.
This is my experience in America: Managers reward by the number
of failures. If your systems never run, BUT, you MANAGE the
outages well, you will go to the top. If yours systems always run
without failures, you better get your resume updated. The "team"
will stay employed for their failures.
Old Man
With a lot of background:
UNIX is the greatest ever; corporate policies are the worst.
On Sun, 18 Jan 2009 18:18:22 GMT, "Old Man"
<···············@nowhere.com> wrote:
>Managers reward by the number
>of failures. If your systems never run, BUT, you MANAGE the
>outages well, you will go to the top. If yours systems always run
>without failures, you better get your resume updated. The "team"
>will stay employed for their failures.
Unfortunately this is true. IT teams tend to be graded by how quickly
they dispatch trouble tickets. If a team reports few, or worse, no
tickets, it means they are liars.
George
George Neuner wrote:
> On Sun, 18 Jan 2009 18:18:22 GMT, "Old Man"
> <···············@nowhere.com> wrote:
>
>> Managers reward by the number
>> of failures. If your systems never run, BUT, you MANAGE the
>> outages well, you will go to the top. If yours systems always run
>> without failures, you better get your resume updated. The "team"
>> will stay employed for their failures.
>
> Unfortunately this is true. IT teams tend to be graded by how quickly
> they dispatch trouble tickets. If a team reports few, or worse, no
> tickets, it means they are liars.
>
I took on a position where I was required to account for my time,
trouble tickets etc. After a few weeks in the job I had the dozen or so
servers (Solaris and Digital) running efficiently and trouble free, so
much so that my immediate superior told me to use some creative writing
in my weekly reports, as the board were wondering what I was doing with
my time and maybe my position was superfluous and could be accomplished
cheaper by farming it out. In truth they were correct, but the previous
admin was basically incompetent and had convinced my boss that unices
were prone to regular crashes and other various problems, thereby
guaranteeing him his job for years.
I tried the creative reporting idea for a short while but I couldn't
maintain the fiction for long and look at myself in the mirror with any
pride, so I resigned after telling my boss that a competent contractor
could keep their systems going for probably half my salary.
--
Rob
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BTW, FWIW, IMHO, AFAIK, yes. OTOH, AAMOF, maybe not. YMMV.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
On Jan 23, 12:02 am, Rob S <····@home.here> wrote:
> I took on a position where I was required to account for my time,
> trouble tickets etc. After a few weeks in the job I had the dozen or so
> servers (Solaris and Digital) running efficiently and trouble free, so
> much so that my immediate superior told me to use some creative writing
> in my weekly reports, as the board were wondering what I was doing with
> my time and maybe my position was superfluous and could be accomplished
> cheaper by farming it out. In truth they were correct, but the previous
> admin was basically incompetent and had convinced my boss that unices
> were prone to regular crashes and other various problems, thereby
> guaranteeing him his job for years.
>
> I tried the creative reporting idea for a short while but I couldn't
> maintain the fiction for long and look at myself in the mirror with any
> pride, so I resigned after telling my boss that a competent contractor
> could keep their systems going for probably half my salary.
Very sad, you're basically being punished for being honest. They
should give you at least some compensation for cutting costs down.
bobi
Slobodan Blazeski wrote:
> On Jan 23, 12:02 am, Rob S <····@home.here> wrote:
>> I took on a position where I was required to account for my time,
>> trouble tickets etc. After a few weeks in the job I had the dozen or so
>> servers (Solaris and Digital) running efficiently and trouble free, so
>> much so that my immediate superior told me to use some creative writing
>> in my weekly reports, as the board were wondering what I was doing with
>> my time and maybe my position was superfluous and could be accomplished
>> cheaper by farming it out. In truth they were correct, but the previous
>> admin was basically incompetent and had convinced my boss that unices
>> were prone to regular crashes and other various problems, thereby
>> guaranteeing him his job for years.
>>
>> I tried the creative reporting idea for a short while but I couldn't
>> maintain the fiction for long and look at myself in the mirror with any
>> pride, so I resigned after telling my boss that a competent contractor
>> could keep their systems going for probably half my salary.
>
> Very sad, you're basically being punished for being honest. They
> should give you at least some compensation for cutting costs down.
>
> bobi
Sometimes honesty _is_ the best policy. A few weeks after quitting that
job I got into subbing. One job was passed on to me by my previous boss,
which was to setup a small ISP for his cousin. Once we got it up and
going they offered me the admin job, which came with a reasonable salary
and some shares. The job turned out to be great fun, mainly because of
the people, and when we were gobbled up by a major ISP 5 years later my
shares enabled me to semi-retire. I now own 8 taxi licenses with the
largest taxi company in town. I have them all leased out which provides
a very comfortable income, and to keep my hand in I maintain the taxi
company's dispatch and office systems. On average I spend around 10
hours a week on them, which leaves me plenty of time to haunt newsgroups :-)
--
Rob
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Frequent lock ups are a symptom of not enough memory but only in the way
that nosebleeds are a symptom of gunshot wounds to the head.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
On Jan 26, 3:32 am, Rob S <····@my.home> wrote:
> Slobodan Blazeski wrote:
> > On Jan 23, 12:02 am, Rob S <····@home.here> wrote:
> >> I took on a position where I was required to account for my time,
> >> trouble tickets etc. After a few weeks in the job I had the dozen or so
> >> servers (Solaris and Digital) running efficiently and trouble free, so
> >> much so that my immediate superior told me to use some creative writing
> >> in my weekly reports, as the board were wondering what I was doing with
> >> my time and maybe my position was superfluous and could be accomplished
> >> cheaper by farming it out. In truth they were correct, but the previous
> >> admin was basically incompetent and had convinced my boss that unices
> >> were prone to regular crashes and other various problems, thereby
> >> guaranteeing him his job for years.
>
> >> I tried the creative reporting idea for a short while but I couldn't
> >> maintain the fiction for long and look at myself in the mirror with any
> >> pride, so I resigned after telling my boss that a competent contractor
> >> could keep their systems going for probably half my salary.
>
> > Very sad, you're basically being punished for being honest. They
> > should give you at least some compensation for cutting costs down.
>
> > bobi
>
> Sometimes honesty _is_ the best policy. A few weeks after quitting that
> job I got into subbing. One job was passed on to me by my previous boss,
> which was to setup a small ISP for his cousin. Once we got it up and
> going they offered me the admin job, which came with a reasonable salary
> and some shares. The job turned out to be great fun, mainly because of
> the people, and when we were gobbled up by a major ISP 5 years later my
> shares enabled me to semi-retire. I now own 8 taxi licenses with the
> largest taxi company in town. I have them all leased out which provides
> a very comfortable income, and to keep my hand in I maintain the taxi
> company's dispatch and office systems. On average I spend around 10
> hours a week on them, which leaves me plenty of time to haunt newsgroups :-)
>
> --
> Rob
Great. I'm glad good deed were rewarded.
bobi
From: =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gktrbg$8v3$1@news.motzarella.org>
André Thieme schrieb:
> It will probably not the 15.000 about some blogs talked at first,
It will probably not be the 15.000, about which some blogs talked at
first, ...
> And the fast .NET still is not available for Linux and Mac.
Only Mono is, which is too slow, as your say yourself.
> If that should not happen, which is extremly unlikely with Java being
> the most popular language in the world, that’s still not too bad for
> Clojure programmers, as Clojure would simply get an implementation on
> the then leading VM.
Btw, Rich Hickey at first started to implement Clojure on the JVM and
also on .NET. It was just not maintainable enough. Now all the Clojure
code is available and it should be trivial to translate, as Java and C#
are similar enough.
André
--
André Thieme wrote:
> Jon Harrop schrieb:
>> André Thieme wrote:
>>> Also keep in mind that Sun is working on Fortress, which will most
>>> likely lead to built in TC support in the JVM.
>>
>> Sun have been "working on" many things for many years and produced
>> nothing worth having. I for one am not pinning my hopes on anything done
>> by Sun, not least because they are going bankrupt and just laid off many
>> thousands of employees (again).
>
> They are in the lead though.
The CLR has had tail calls, value types and real parametric polymorphism for
the best part of a decade. The JVM still does not have them.
Today, F# is a long way ahead of anything available for the JVM.
> One or two decades before Microsoft they had an OS that did not crash
> daily.
Sun have posted billions of dollars losses while Microsoft posted billions
of dollars profit.
> The JVM came out years before Microsoft had anything to offer. So,
> it proves where the creative people sit.
But the JVM still lacks so many basic features.
> And also Microsoft is now planning to lay off some thousand employees.
Allegedly. Sun have already laid off thousands of employees.
> It will probably not the 15.000 about some blogs talked at first, but
> still enough.
That speculation is not a very strong argument.
> Google bets on Java and uses its billions against Microsoft.
Google are a one trick pony and continue to lose market share to Microsoft.
> And the fast .NET still is not available for Linux and Mac.
True.
> It will force you to have a Windows server system, for which the
> license costs are high enough. On top of that, the JVM is already open
> sourced, so in the case that Sun loses it can be continued to develop.
> If that should not happen, which is extremly unlikely with Java being
> the most popular language in the world, that’s still not too bad for
> Clojure programmers, as Clojure would simply get an implementation on
> the then leading VM.
Sun's code is an unmaintainable mess. That's why the open source community
are not developing it.
> As a fast google search prooves, Java is about 340% more popular than
> C#: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> So, this is a clear indication for people who like to draw conclusions
> from google searches about popularity to find out which is the right way.
> Uh.. wait a minute...
According to Google Trends, Java is 5x more searched for than C#:
http://www.google.com/trends?q=java%2Cc%23
However, according to ITJobsWatch the market share trends in the UK over the
past 4 years are C# 14%->30% and Java 36%->22%:
http://www.itjobswatch.co.uk/jobs/uk/csharp.do
http://www.itjobswatch.co.uk/jobs/uk/java.do
Microsoft target the rich market.
Microsoft are guilty of many things but they have realised the benefit of
building upon a solid foundation, created .NET and now provide the most
advanced core for software development in the world. I would like to see
real competition from a viable alternative as much as the next guy (I have
been a Linux user for many years and our company server still runs Linux)
but the fact is that Microsoft currently have no competition when it comes
to VMs.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gkvksa$12ch$1@opal.icpnet.pl>
thus spoke Jon Harrop <···@ffconsultancy.com>:
>> And the fast .NET still is not available for Linux and Mac.
> True.
Not like it's ever going to be - from Microsoft, that is.
> According to Google Trends, Java is 5x more searched for than C#:
> http://www.google.com/trends?q=java%2Cc%23
> However, according to ITJobsWatch the market share trends in the UK over the
> past 4 years are C# 14%->30% and Java 36%->22%:
> http://www.itjobswatch.co.uk/jobs/uk/csharp.do
> http://www.itjobswatch.co.uk/jobs/uk/java.do
Who cares about the market, anyway. I've noticed that the stuff I write
in my spare time is (fsvo) interesting, compared to stuff I do for a
living, which tends to be boring code solving irrelevant problems.
Programming shouldn't be something one does for a living.
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
On 2009-01-17, Jon Harrop <···@ffconsultancy.com> wrote:
> André Thieme wrote:
>> While it is true that the current version of the JVM does not support
>> tail calls, it does not mean that you constantly run into stack over-
>> flows.
>> Clojure offers several mechanisms to go in most cases around that
>> problem, as (recur ...) or trampolines.
>
> Lack of tail calls is an absolutely crippling problem.
Tail calling is just goto with parameter passing.
It can be obtained using a Lisp macro (like one I have written called
TAILPROG).
This gives you portable tail calling in any Common Lisp implementation.
The rest of your article only demonstrates that stupidity is a crippling
progblem for academic programmers.
Kaz Kylheku wrote:
> On 2009-01-17, Jon Harrop <···@ffconsultancy.com> wrote:
>> André Thieme wrote:
>>> While it is true that the current version of the JVM does not support
>>> tail calls, it does not mean that you constantly run into stack over-
>>> flows.
>>> Clojure offers several mechanisms to go in most cases around that
>>> problem, as (recur ...) or trampolines.
>>
>> Lack of tail calls is an absolutely crippling problem.
>
> Tail calling is just goto with parameter passing.
No, it isn't.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-01-18, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> On 2009-01-17, Jon Harrop <···@ffconsultancy.com> wrote:
>>> André Thieme wrote:
>>>> While it is true that the current version of the JVM does not support
>>>> tail calls, it does not mean that you constantly run into stack over-
>>>> flows.
>>>> Clojure offers several mechanisms to go in most cases around that
>>>> problem, as (recur ...) or trampolines.
>>>
>>> Lack of tail calls is an absolutely crippling problem.
>>
>> Tail calling is just goto with parameter passing.
>
> No, it isn't.
Please show a tail calling example in Lisp, or pseudocode, that you think does
not correspond to goto with parameter passing.
Kaz Kylheku wrote:
> On 2009-01-18, Jon Harrop <···@ffconsultancy.com> wrote:
>> Kaz Kylheku wrote:
>>> Tail calling is just goto with parameter passing.
>>
>> No, it isn't.
>
> Please show a tail calling example in Lisp, or pseudocode, that you think
> does not correspond to goto with parameter passing.
The "goto" is jump between instruction blocks that share a stack frame (i.e.
within a function or exception handler) and correspond to a branch or jump
assembly instruction. Tail calls jump between functions that do not
necessarily share a stack frame and the code generator is responsible for
overwriting the caller's stack frame with the callee's stack frame. Note,
in particular, that the callee may have a larger stack frame than the
caller.
So tail calls must handle all stack allocations which includes parameters
but also other entities such as struct return values.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Pascal J. Bourguignon
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <87hc3wvn82.fsf@galatea.local>
Jon Harrop <···@ffconsultancy.com> writes:
> Kaz Kylheku wrote:
>> On 2009-01-18, Jon Harrop <···@ffconsultancy.com> wrote:
>>> Kaz Kylheku wrote:
>>>> Tail calling is just goto with parameter passing.
>>>
>>> No, it isn't.
>>
>> Please show a tail calling example in Lisp, or pseudocode, that you think
>> does not correspond to goto with parameter passing.
>
> The "goto" is jump between instruction blocks that share a stack frame (i.e.
> within a function or exception handler) and correspond to a branch or jump
> assembly instruction. Tail calls jump between functions that do not
> necessarily share a stack frame and the code generator is responsible for
> overwriting the caller's stack frame with the callee's stack frame. Note,
> in particular, that the callee may have a larger stack frame than the
> caller.
>
> So tail calls must handle all stack allocations which includes parameters
> but also other entities such as struct return values.
You're looking implementation details here. You must see it at a more abtract level.
(block :exit
(let (a b c)
(tagbody
(setf a 1)
(setf b 2)
:small
(when (< 10 a) (return-from :exit b))
(setf a (+ a b))
(go :big)
:big
(setf c (* a b))
(setf a (- c a))
(setf b (- c b))
(go :small))))
Here, you can see that the :small 'block' uses only two slots in the
stack frame, while the :big 'block' uses three slots. However, all
stack allocations have been handled.
In any case, you only have to show us an expression with goto or with
tail calls, along with the proof that it cannot be translated into the
other form to prove your assertion. But I'll bet that whatever your
expression, we will be able to translate it into the other form
easily.
--
__Pascal Bourguignon__
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gkvl0q$12ch$2@opal.icpnet.pl>
thus spoke Pascal J. Bourguignon <···@informatimago.com>:
> You're looking implementation details here. You must see it at a more abtract level.
> (block :exit
> (let (a b c)
> (tagbody
> (setf a 1)
> (setf b 2)
>:small
> (when (< 10 a) (return-from :exit b))
> (setf a (+ a b))
> (go :big)
>:big
> (setf c (* a b))
> (setf a (- c a))
> (setf b (- c b))
> (go :small))))
[...]
It's not the same. Necessitates inlining and does away with the function
abstraction. A good compiler can even make RETURN-FROM a tail call at
the end of its corresponding block.
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
From: Pascal J. Bourguignon
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <878wp8uzur.fsf@galatea.local>
Stanisław Halik <·······@test123.ltd.pl> writes:
> thus spoke Pascal J. Bourguignon <···@informatimago.com>:
>
>> You're looking implementation details here. You must see it at a more abtract level.
>> (block :exit
>> (let (a b c)
>> (tagbody
>> (setf a 1)
>> (setf b 2)
>>:small
>> (when (< 10 a) (return-from :exit b))
>> (setf a (+ a b))
>> (go :big)
>>:big
>> (setf c (* a b))
>> (setf a (- c a))
>> (setf b (- c b))
>> (go :small))))
> [...]
>
> It's not the same.
The above code is the same as:
(block :exit
(labels ((small (a b)
(when (< 10 a) (return-from :exit b))
(big (+ a b) b))
(big (a b)
(let ((c (* a b)))
(small (- c a) (- c b)))))
(small 1 2)))
> Necessitates inlining and does away with the function
> abstraction. A good compiler can even make RETURN-FROM a tail call at
> the end of its corresponding block.
A good compiler will generate exactly the same code for both expression.
--
__Pascal Bourguignon__
On 2009-01-18, Pascal J. Bourguignon <···@informatimago.com> wrote:
> Stanisław Halik <·······@test123.ltd.pl> writes:
>
>> thus spoke Pascal J. Bourguignon <···@informatimago.com>:
>>
>>> You're looking implementation details here. You must see it at a more abtract level.
>>> (block :exit
>>> (let (a b c)
>>> (tagbody
>>> (setf a 1)
>>> (setf b 2)
>>>:small
>>> (when (< 10 a) (return-from :exit b))
>>> (setf a (+ a b))
>>> (go :big)
>>>:big
>>> (setf c (* a b))
>>> (setf a (- c a))
>>> (setf b (- c b))
>>> (go :small))))
>> [...]
>>
>> It's not the same.
>
> The above code is the same as:
>
> (block :exit
> (labels ((small (a b)
> (when (< 10 a) (return-from :exit b))
> (big (+ a b) b))
> (big (a b)
> (let ((c (* a b)))
> (small (- c a) (- c b)))))
> (small 1 2)))
(tailprog ()
((small (a b)
(if (< 10 a)
b
(big (+ a b) b)))
(big (a b)
(let ((c (* a b)))
(small (- c a) (- c b)))))
(small 1 2)))
-> 24
(macroexpand '(tailprog () ...))
->
(MACROLET
((SMALL (&REST ARGS) (CONS 'GOTO (CONS 'SMALL ARGS)))
(BIG (&REST ARGS) (CONS 'GOTO (CONS 'BIG ARGS))))
(LET NIL
(ARGTAGS NIL
(RETURN (PROGN (SMALL 1 2)))
(LABEL SMALL A B) (RETURN (PROGN (IF (< 10 A) B (BIG (+ A B) B))))
(LABEL BIG A B) (RETURN (PROGN (LET ((C (* A B)))
(SMALL (- C A) (- C B))))))))
(macroexpand '(ARGTAGS NIL ...))
->
(MACROLET
((GOTO (LABEL &REST ARGS)
(ARGTAGS-COMPILE-GOTO LABEL ARGS 'NIL
'((BIG (A B) (#:A3167 #:B3168) #:BIG3169)
(SMALL (A B) (#:A3164 #:B3165) #:SMALL3166)))))
(BLOCK NIL
(LET (#:A3167 #:B3168 #:A3164 #:B3165)
(TAGBODY
(RETURN (PROGN (SMALL 1 2)))
SMALL
(RETURN (PROGN (IF (< 10 A) B (BIG (+ A B) B))))
BIG
(RETURN (PROGN (LET ((C (* A B))) (SMALL (- C A) (- C B)))))
(RETURN-FROM NIL)
#:SMALL3166
(PSETF A #:A3164 B #:B3165)
(GO SMALL)
#:BIG3169
(PSETF A #:A3167 B #:B3168)
(GO BIG))))) ;
(argtags-compile-goto 'big '(3 4) 'nil
'((BIG (A B) (#:A3167 #:B3168) #:BIG3169)
(SMALL (A B) (#:A3164 #:B3165) #:SMALL3166)))
-> (PROGN (PSETF #:A3167 3 #:B3168 4) (GO #:BIG3169))
Some staff snipped for nice people not using google groups.
On Jan 18, 4:33 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Please read more carefully. I don’t suggest that the JVM is the best
> possible plattform for implementing a Lisp.
> I only say that your claim is BS. Your use of the word “better” is
> totally subjective. What I didn’t like is that you presented it as a fact.
> It’s okay to have that opinion, but in that case one could state it like
> that and maybe even give one or two reasons why one thinks so.
Let's do a little refactoring since this discussion is going nowhere.
This my (Slobodan Blazeski) opinion:
Moving major or all of lisp implementation towards JVM is a bad idea.
Exception: Having some lisp implementation that target JVM or CLR is a
nice to have.
;;; end of the opinion
This opinion that I believe you (Andre Thieme) are promoting: ;;; Feel
free to correct it if necessary
Moving major or all of lisp implementation towards JVM is a great
idea.
;;; end of the opinion
Why do I have mine opinion:
Facts:
1. Fact: All of the major implementation writers decided to stay away
from JVM. ;;; end of fact
My reasoning:
If the people who have a lot of experience( sometimes even decades)
decided to stay away from JVM, that means JVM is not a good idea to
start with or switch to. JVM might be a great idea for people who need
close interaction with Java world or smooth access to its libraries.
;;; end of reasoning
2. Fact: Implementation based on JVM will require installation of
right version of JVM (or CLR).
My reasoning:
Every dependencies brings additional piece in the puzzle, and adds
complexity with exponential growth. So having or installing JVM in
system is just another obstacle. JVM and CLR are like a moving
targets, they don't ship on almost every system as default and they
change versions too fast. Joel writes much better then me
http://www.joelonsoftware.com/articles/PleaseLinker.html
;;; end of reasoning
3. Fact: Vast majority of lisp users stay prefer non-JVM
implementations
My reasoning:
If most of the lispers prefer non-JVM based solutions then JVM doesn't
offer such benefits. If 1000 went to Franz with a check in their hands
for a JVM based Allegro I'm sure they will write one. If they don't
someone else will. So JVM is for minority if you're not part of it,
it's a bad idea.
;;; end of reasoning
4. Clojure & ABCL which are implementations based on JVM have flows in
important areas, that users of other implementations take for granted.
(For ABCL that's CLOS & MOP part, for Clojure tail calls)
;;; end of fact
My reasoning:
CLOS and to a lesser extent MOP are very important in the common lisp
world. Tail call optimization is very important in any lisp.In scheme
is required by standard and every common lisp implementation worthy
it's name supports it. Recur & trampoline are just temporary hacks,
until the implementation is doing them instead of forcing me to act as
human compiler, you don't have them.
Until someone solves them nobody knows how much work and time they
need, or they might stay open forever. So if someone ports or starts
with JVM he goes into uncharted waters.
;;; end of reasoning
You're welcomed present your facts and reasoning or challenge mine.
>
> And only because you were able to follow instructions of a first semester
> course on how to implement a trivial interpreter does not make you an
> expert.
But it makes me far more knowledgeable then people who didn't do even
that.
> Rich Hickey just implemented Clojure on the JVM. [snip]
But Rich Hickey isn't here saying that moving major or all of lisp
implementation towards JVM is a great idea. It's you, Andre Thieme
doing that. So it's the burden on you to prove it.
>
> > Until you educate yourself and gain experience IN IMPLEMENTING NOT
> > USING you're only doing wishful thinking from a perspective of a
> > USER.
>
> Again, bullshit.
> Do you also have to consume cocain before you can understand its effects
> very well?
Is implementing lisp causing addiction?
> You have no way to know how much I know about this matter. Please stop
> accusing people and playing the expert, okay? Thanks :-)
I'm not expert but I know more then you. If Duane, Garcia or Finley
told me something about implementing I would know that those people
know what the hell are they talking about. But you don't know anything
and don't even bother to spent at least 2 days of gaining at least the
simplest knowledge yet you stubbornly insisting that you are right.
People who made a hut knows the basics, those build palaces are
experts, the one who didn't build even a simplest bird house don't
know a shit. So build your bird house.
> >> Funny. Why is Jon not allowed to make conclusions from a simple google
> >> search, but others are? ;-)
> > Because Jon Harrop is a well known spammer. He's not here for
> > discussing lisp, he only wants to spam this newsgroup with his pond
> > staff.
>
> One “problem” with Jon is that he sometimes posts stuff that makes sense
> and is debatable.
That's when I reply to him and don't call him toad.
> He can be very serious and unprovocative, [snipped]
No Jon Harrop is a spammer, he only cares about selling his pond
leaves. The well written posts are only to hook people into
discussion. He doesn't care about lisp nor this newsgroup.
> > I didn't had a chance to try Clojure because of JVM problems mentioned
>
> Well, it could be an indicator for hardware problems.
> On one compi I also could not install the JRE/JDK. This machine had a
> hardware error. Typical signs are that your computer crashes or suddenly
> gets extremly slow/freezes. If that happens it is likely that there is a
> hardware defect.
Hm I don't think so but I will try on my laptop and see what will
happen. Is the latest version of JVM good or I need some specific
version?
bobi
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
Slobodan Blazeski schrieb:
> On Jan 18, 4:33 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
> This my (Slobodan Blazeski) opinion:
> Moving major or all of lisp implementation towards JVM is a bad idea.
> Exception: Having some lisp implementation that target JVM or CLR is a
> nice to have.
> ;;; end of the opinion
I agree with that.
I am glad that Rich targeted the JVM with Clojure, instead of programming
his own.
> This opinion that I believe you (Andre Thieme) are promoting: ;;; Feel
> free to correct it if necessary
> Moving major or all of lisp implementation towards JVM is a great
> idea.
> ;;; end of the opinion
Oh, this is not true.
I don�t want to suggest that Lisp X or Y should be implemented on the
JVM (or CLR or on the Erlang-VM, etc.).
My only message is, that I don�t believe, that �Lisp does work better in
its own VM�.
One of the reasons why I believe so is, because the word �better� was
not defined. I personally understand that better means, that it will
more often give correct results and that the computer just will be in
good mood.
> Why do I have mine opinion:
> Facts:
> 1. Fact: All of the major implementation writers decided to stay away
> from JVM. ;;; end of fact
> My reasoning:
> If the people who have a lot of experience( sometimes even decades)
> decided to stay away from JVM, that means JVM is not a good idea to
> start with or switch to. JVM might be a great idea for people who need
> close interaction with Java world or smooth access to its libraries.
> ;;; end of reasoning
Yes, sounds good.
But let�s not forget that basically all Implementors of CL did begin
with their work when the JVM did not even exist.
This is, in my opinion, also a very good reason for not implementing
Lisps on the JVM.
Rule of thumb: if something does not exist, don�t implement Software
on it.
And when Sun came out with the JVM it was simply total crap.
Lot�s of bugs, no Libs, extremly slow, nearly no books, 73 users.
Only since a few years it actually started to make sense to implement
languages on the JVM.
By that moment the Implementors of Lisp already spent 20.000 to 150.000
man hours into their code. They had customers and no ressources to spend
another 80k man-hours for porting their Lisp to the JVM.
> 2. Fact: Implementation based on JVM will require installation of
> right version of JVM (or CLR).
> My reasoning:
> Every dependencies brings additional piece in the puzzle, and adds
> complexity with exponential growth. So having or installing JVM in
> system is just another obstacle.
Yes. This is a disadvantage of using languages like Java, Lisp, C# or
Erlang. They all require their VM, and users need to either install it,
or people who deliver Software will have to put those into their
installers.
> 3. Fact: Vast majority of lisp users stay prefer non-JVM
> implementations
> My reasoning:
> If most of the lispers prefer non-JVM based solutions then JVM doesn't
> offer such benefits. If 1000 went to Franz with a check in their hands
> for a JVM based Allegro I'm sure they will write one. If they don't
> someone else will. So JVM is for minority if you're not part of it,
> it's a bad idea.
> ;;; end of reasoning
This reasoning is a bit problematic.
Simply because there existed no Lisps that were worth to mention on the
JVM.
So *of course* the number of Lispers who use a Lisp on the JVM is still
very small. But just wait until the number of Clojure users is 5x as big
as the number of CL users. Then you would have to tell the opposit.
Then one would say that most Lispers use and prefer a Lisp that runs on
the JVM, and that non-JVM is for a minority, and it�s a bad idea.
> 4. Clojure & ABCL which are implementations based on JVM have flows in
> important areas, that users of other implementations take for granted.
> (For ABCL that's CLOS & MOP part, for Clojure tail calls)
> ;;; end of fact
> My reasoning:
> CLOS and to a lesser extent MOP are very important in the common lisp
> world. Tail call optimization is very important in any lisp.In scheme
> is required by standard and every common lisp implementation worthy
> it's name supports it. Recur & trampoline are just temporary hacks,
> until the implementation is doing them instead of forcing me to act as
> human compiler, you don't have them.
> Until someone solves them nobody knows how much work and time they
> need, or they might stay open forever. So if someone ports or starts
> with JVM he goes into uncharted waters.
> ;;; end of reasoning
It�s right that Clojure has no CLOS and no MOP.
But this happened on *full intent*.
It is very important to support only one pagadigm of programming.
This results in Libs that usually interact much better with each other,
and are much easier to integrate.
If you have many styles, as in CL, then 3 people will find 4 solutions
for implementing the same thing.
One is doing it with CLOS, the other one purely functional. The next
guy implements an imperative solution, while the logic fan is doing it
in a highly declarative style.
We can also see that OOP was not the amazing weapon that people hoped
it would be. Nice for GUI, but for the rest of programming... no thanks.
The functional approach however looks in my opinion like the most
promising approach that we currently have.
Paul Graham already realized in the 90ies:
�With macros, closures, and run-time typing, Lisp transcends
object-oriented programming.�
He said this in the first Chapter of �ANSI Common Lisp�.
With �clojures� he meant specifically the functional paradigm, about
which he talks a lot in the first chapters:
http://lib.store.yahoo.net/lib/paulgraham/acl1.txt
http://lib.store.yahoo.net/lib/paulgraham/acl2.txt
> You're welcomed present your facts and reasoning or challenge mine.
I did. Although I don�t want to really challenge your reasoning and
opinions, but just state that I don�t demand for implementors to move to
the JVM.
In fact, we now have an excellent Lisp on the JVM, in the form of Clojure.
This is great news for Lispers, as this offers the realistic chance that
thousands of Lispers can get jobs in Java companies. At least in smaller
ones, because there the boss will happily trade the code complexity of
Lisp for a plus in productivity.
The code complexity is of course only imagination, but at least we can
say that the majority of Java programmers are no Lisp experts.
>> And only because you were able to follow instructions of a first semester
>> course on how to implement a trivial interpreter does not make you an
>> expert.
> But it makes me far more knowledgeable then people who didn't do even
> that.
No. It gives you an extra knowledge that requires a few days of reading
for programming experts.
This is of course some extra knowledge, but I find the word �far� far off.
>> Rich Hickey just implemented Clojure on the JVM. [snip]
> But Rich Hickey isn't here saying that moving major or all of lisp
> implementation towards JVM is a great idea. It's you, Andre Thieme
> doing that. So it's the burden on you to prove it.
What you said is only to some extent true. The part about Rich Hickey
is right. But the one about me is not.
I think I never said/wrote that I demand/wish/hope that major or all
Lisps will be transported to the JVM.
Again, I only disagree with your statement, that Lisp works better in
its own VM.
From that statement of mine one can not come to the logical conclusion,
that I think that Lisps work better in the JVM.
First lesson in the first semester in the math class in university
taught us that this is not correct.
> I'm not expert but I know more then you.
You only assume this. It may be true, but again you state this as a fact.
Two other possibilities exist though.
> If Duane, Garcia or Finley
> told me something about implementing I would know that those people
> know what the hell are they talking about.
I never saw Duane making such ridiculous statements such as
�Lisp works better in its own VM�.
> But you don't know anything
> and don't even bother to spent at least 2 days of gaining at least the
> simplest knowledge yet you stubbornly insisting that you are right.
Obviously I must know at least something, because otherwise I could not
write.
You don�t know how many days I spent with implementing Lisps.
You also are totally mislead in thinking that I think that implementing
Lisp on the JVM is �better�. I never said this and as I explained, this
does not follow logically.
We talk about very different things.
I complain that you made this statement about Lisp working better in
its own VM and made it sound as if it would be actually true.
Obviously this can not be true, because you used a relative word, and
relative words like �better� can only be used when expressing opinions.
> People who made a hut knows the basics, those build palaces are
> experts, the one who didn't build even a simplest bird house don't
> know a shit. So build your bird house.
Your arrogance and disrespect are no big help here.
> Hm I don't think so but I will try on my laptop and see what will
> happen. Is the latest version of JVM good or I need some specific
> version?
I personally installed the latest JVM on my systems, as this has no
disadvantage for me, but instead some advantages.
On Windows this is Java 6 Update 11. On Ubuntu I took what is in the
package system, and that is Java 6 Update 10.
Andr�
--
On 2009-01-20 14:57:14 -0500, Andr� Thieme
<······························@justmail.de> said:
> Tail calls have nothing to do with Lisp �working better� on the JVM at
> all. That�s an issue about the ease of implementing TCs and also a plus
> on program safety.
>
> Please guys, don�t get ridiculous.
Oh please! The *only* reason that clojure has the need for loop/recur
and trampoline is because the jvm doesn't do tail call optimization as
any scheme must. This is a clear expressive problem with the language
that is forced on it by the fact that it runs on the jvm - if I don't
want stack to explode I may *not* use an ordinary recursive function
(or mutually recursive functions) but must instead use a different form
- loop/recur or trampoline.
At least Rich Hickey is straightforward and honest about it - clojure
has this tail call issue because of the jvm; clojure has two
workarounds, loop/recur and trampoline; Rich Hickey would *clearly*
prefer that the jvm support tail calls properly so he could remove
loop/recur and trampoline from clojure.
--
Raffael Cavallaro, Ph.D.
On 2009-01-20 14:57:14 -0500, Andr� Thieme
<······························@justmail.de> said:
> For most typical business tasks a Lisp inside the JVM will make the
> programmer much more productive, as he can use quadrillions of Libs.
> Absolutely nothing increases productivity more than code that is already
> written.
> Integrating your app into SAP software? Running a SOAP server? Doing
> REST requests on Yahoo? Reading Excel files? All there.
And now we have the *real* reason that you want lisp on the jvm - not
because the jvm is particularly well suited as a lisp platform but
because of the *libraries*.
You shouldn't conflate arguments.
The existence of many java libraries only speaks to how *convenient* it
is to have a lisp on the jvm and says *nothing* about how well suited
the jvm is as an underlying platform on which to implement lisp.
--
Raffael Cavallaro, Ph.D.
Raffael Cavallaro schrieb:
> On 2009-01-20 14:57:14 -0500, Andr� Thieme
> <······························@justmail.de> said:
>
> Oh please! The *only* reason that clojure has the need for loop/recur
> and trampoline is because the jvm doesn't do tail call optimization
This is mostly true. But recur extends typical recursion, by enabling
anonymous functions to call themselves.
> This is a clear expressive problem with the
> language that is forced on it by the fact that it runs on the jvm -
> if I don't want stack to explode I may *not* use an ordinary
> recursive function (or mutually recursive functions) but must instead
> use a different form - loop/recur or trampoline.
This is correct. At this moment it is still true that Clojure
programmers need to learn a new idiom to code mutual recursive
functions.
This idiom is a bit more complex, so this is a disadvantage.
But let�s not forget that tail recursion itself already is a
�hack� for recursion. We already have to think about how to do tail
recursion, even in the simple case. We need to introduce an artificial
labels that needs a helper arg, and then put the call into the tail
position. We can�t do it like this:
(defun summing (n)
(if (zerop n)
0
(+ n (summing (1- n)))))
but need instead:
(defun summing2 (n)
(labels ((helper (n result)
(if (zerop n)
result
(helper (1- n) (+ result n)))))
(helper n 0)))
And when I do this in Lispworks, I get:
CL-USER 5 > (summing2 100)
Stack overflow (stack size 15997).
1 (continue) Extend stack by 50%.
2 Extend stack by 300%.
3 (abort) Return to level 0.
4 Return to top loop level 0.
(after compilation of summing2 it works of course)
As long something as summing2 is needed I personally see it as
an idiom, as a hack, that exists for practical reasons,
because we still don�t have infinite memory, or clever enough
compilers to make a summing2 out of summing under the hood *sigh*
Trampolines are not much worse than what I did in summing2.
> At least Rich Hickey is straightforward and honest about it - clojure
> has this tail call issue because of the jvm; clojure has two
> workarounds, loop/recur and trampoline; Rich Hickey would *clearly*
> prefer that the jvm support tail calls properly so he could remove
> loop/recur and trampoline from clojure.
Of course he would like the JVM to have TC support. But he won�t
removerecur, and I guess he will also keep trampolines.
But I think we should focus on my main criticism again.
That was: I don�t think that �Lisp works better in its own VM�.
Working better has nothing to do with tail call support, with
abstractions, with the ease of implementing the Lisp, with memory
consumption or with runtime efficiency.
All these things could have been named.
�When implementing Lisp in its own VM one could implement proper
support for tail recursion�.
I would agree here. When doing it in the JVM one could do it also, by
implementing your own VM inside the JVM. Or wait until Sun offers it.
But the statement itself is true.
�When implementing Lisp in its own VM it will save a bit more
memory�.
May be true. The JVM needs quite a good bit. But I don�t care, and in
fact remember of what Duane has explained in the past.
The understanding of what is �not much memory� has changed.
The 128kb days of RAM are over. 4GB DDR2-RAM ==> 76,90�.
I could not care less that Lynx only needs 800kb RAM and Firefox 270mb.
Of my 2 GB RAM I have most of the time 50+% free.
On business machines I can install as much as I need. The other day I
was corresponding with a guy whose machine has one terabyte (!) RAM.
But anyway, I would not have said anything if Slobo said something like
that about RAM.
Out of these possibilities he chose to say that Lisp will *work better*.
And sorry, this is BS.
He did not talk about tail recursion, and tail recursion has nothing to
do with Lisp working better.
Better means that the blue in your GUI will shine brighter, or that
(+ 10 5) results in a stronger, much clearer 15. One that looks good.
It can *as well* mean that all these components are given:
- correctness of results
- code runs fast
- offers great abstractions
- not much memory consumptions
- easy to implement
But that is all subjective and needs to be defined first. When this was
done, then the word �better� is not needed anymore.
Clojure so far offers in many cases correct results. Some of its new
code may contain bugs. But out of all libraries that one can use on the
JVM it has a strong position. Every year the Java libs are tested for
more man hours than all Lisp libs have gotten testing in the past 50
years all together.
Clojure is dynamic and young. It does not have the type inference skills
that (for example) SBCL has. But still, by giving some type hints I can
often come close to Java speed, which is for tons of stuff much faster
than SBCL.
One little example that Rainer gave was running faster in Clojure than
compiled Lispworks or SBCL code.
On my system I had these runtimes (all compiled code):
Lispworks: 400 msecs
SBCL: 200 msecs
Clojure: 100 msecs
Java: 16 msecs
Microbenchmarks don�t prove anything, but from what I have seen
Clojure is fast enough for many tasks. For concurrent code I think it
will leave many Lisps behind.
One thing on which I am working is my Genetic Programming system. I will
port it to Clojure for fun, but I'm pretty sure that my main
development will stay with SBCL, simply because it performs great.
Clojures great support for concurrency is not needed, because it is
trivial to parallelize my code in SBCL.
Abstractions.. very nice what Clojure offers. The JVM did not stop it
from being Lisp with macros.
I can for example say:
(def sums (lazy-cat [0] (map + sums (iterate inc 1))))
user> (take 10 abce)
(0 1 3 6 10 15 21 28 36 45)
user> (time (nth sums 80000))
"Elapsed time: 183.88838 msecs"
3200040000
user> (time (nth sums 80001))
"Elapsed time: 3.884468 msecs"
3200120001
Lots of stuff in Clojure supports lazyness, we have transactions, agents
(I just tested: it's no problem to have 8 million of them at the
same time),
multimethods that dispatch on anything I want, not just type, and the
newest cutting edge stuff: left folded enumerators.
I wrote a good bit of Clojure code now, and although it runs in the JVM
I must say it does not work worse than my Lisp code in Lispworks,
Allegro, Clisp or SBCL.
So, if we look at the list of candidates of what �runs better� means,
I can� find that Clojure, which runs in the JVM, works worse.
> And now we have the *real* reason that you want lisp on the jvm - not
> because the jvm is particularly well suited as a lisp platform but
> because of the *libraries*.
I think no programmer would dislike to have this big variety of libs
available. But you are wrong. It is not *the* reason why I like a Lisp
on the JVM.
It is *one* of them.
And on the JVM I like specifically Clojure.
This is for example because there is only one implementation right now.
That will allow me to use most Clojure libs written by others. I also
have only one system to learn.
It�s great that it is *not* a multiparadigm language. Fantastic for
interoperability with code of others. All co-workers will solve their
problems in functional style.
Easier to fix code in functional programs.
Excellent concurrency support.
Modern reader macros.
Amazing dictator. Hickey does not chat much or wastes time in c.l.l.,
where enough people talk BS, but instead he writes code. He fixes bugs
very fast, he is really engaged.
> You shouldn't conflate arguments.
WTF?!
You are doing exactly that in this very moment.
My criticism was concretly about this �Lisp works better in its
own VM� statement. I am not talking about tail calls, or the ease to
implement feature X or Y.
People are engaging me in other topics, such as implementing Lisp.
I don�t care at all how many problems the implementor had.
And Slobo did not originally talked about this. Besides that I even see
points that are in favour of the JVM for implementing Lisp, like the
already existing GC. And of course the libs. Those need to be
implemented as well. A Lisp without code is not worth much for me.
I would ask for a proof of that statement, but of course no one can give
it to me, as this statement is no real statement, but an opinion, which
was presented as a statement.
As I noticed that some people misunderstood the �better� and think it
could have to do with the difficulty of implementing Lisp, I went into
the discussion in some other directions. Although I don�t want to say
for sure that one and the same person, without any programming know-
ledge would be able to implement Lisp faster on the JVM. But I would
also not say that it is much more difficult. Perhaps a bit, don�t know.
And that�s not the topic I care about.
> The existence of many java libraries only speaks to how *convenient*
> it is to have a lisp on the jvm and says *nothing* about how well
> suited the jvm is as an underlying platform on which to implement
> lisp.
Slobo did not say that it is �easier to *implement* Lisp in its own
VM�.
He said it would be *working better*. I can�t stress this enough,
as some guys here are really confusing implementing Lisp and having it
working.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On 2009-01-21, André Thieme <······························@justmail.de> wrote:
> Raffael Cavallaro schrieb:
>> On 2009-01-20 14:57:14 -0500, André Thieme
>> <······························@justmail.de> said:
>>
>> Oh please! The *only* reason that clojure has the need for loop/recur
>> and trampoline is because the jvm doesn't do tail call optimization
>
> This is mostly true. But recur extends typical recursion, by enabling
> anonymous functions to call themselves.
>
>
>> This is a clear expressive problem with the
>> language that is forced on it by the fact that it runs on the jvm -
>> if I don't want stack to explode I may *not* use an ordinary
>> recursive function (or mutually recursive functions) but must instead
>> use a different form - loop/recur or trampoline.
>
> This is correct. At this moment it is still true that Clojure
> programmers need to learn a new idiom to code mutual recursive
> functions.
> This idiom is a bit more complex, so this is a disadvantage.
> But let’s not forget that tail recursion itself already is a
> “hack” for recursion. We already have to think about how to do tail
> recursion, even in the simple case. We need to introduce an artificial
> labels that needs a helper arg, and then put the call into the tail
> position. We can’t do it like this:
>
> (defun summing (n)
> (if (zerop n)
> 0
> (+ n (summing (1- n)))))
>
> but need instead:
>
> (defun summing2 (n)
> (labels ((helper (n result)
> (if (zerop n)
> result
> (helper (1- n) (+ result n)))))
> (helper n 0)))
>
> And when I do this in Lispworks, I get:
> CL-USER 5 > (summing2 100)
> Stack overflow (stack size 15997).
Rewriting to TAILPROG, almost closed eyes! All I'm doing is
transliterating the syntax (labels ...) to (tailprog () ...):
(defun summing2 (n)
(tailprog () ((helper (n result)
(if (zerop n)
result
(helper (1- n) (+ result n)))))
(helper n 0)))
(summing2 100) -> 5050
(summing2 1000000) -> 500000500000
(summing2 100000000) -> 5000000050000000
I didn't bother compiling the first two cases.
Are these the right results? I ``Gauss'' so. :) :) :)
> As long something as summing2 is needed I personally see it as
> an idiom, as a hack, that exists for practical reasons,
> because we still don’t have infinite memory, or clever enough
> compilers to make a summing2 out of summing under the hood *sigh*
> Trampolines are not much worse than what I did in summing2.
On the other hand, I don't regard TAILPROG as a hack, but a legitimate
abstraction for expressing a more disciplined form of goto. There is no
pretense that HELPER is a function. It is not and does not return, even if you
write code that uses it in a non-tail position. Such a situation deserves a
diagnostic (not currently implemented, future implementation).
HELPER is understood to be the label for a block of code which is the target of
an unconditional control transfer, accompanied by the passage of parameters.
When HELPER's block of code terminates, the TAILPROG construct terminates, and
passes out the result value. The termination does not go through
(helper n 0) initial form, but directly from HELPER.
So for instance it is understood that if the following change is made to the
inductive form (helper n 0):
(unwind-protect
(helper n 0)
(throw 'foo))
Then the transfer to HELPER never takes place, because this is roughly
equivalent to:
;; within some TAGBODY
(unwind-protect
(go some-label)
(throw 'foo))
The GO is a protected form, and it's performing a non-local control transfer in
order to reach the labelled block. Before that transfer can complete, the
cleanup form is evaluated, and this form hijacks the control transfer, taking
it way farther out to some catch, terminating TAILPROG in the process.
On Jan 21, 10:25 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2009-01-21, André Thieme <······························@justmail.de> wrote:
>
>
>
>
>
> > Raffael Cavallaro schrieb:
> >> On 2009-01-20 14:57:14 -0500, André Thieme
> >> <······························@justmail.de> said:
>
> >> Oh please! The *only* reason that clojure has the need for loop/recur
> >> and trampoline is because the jvm doesn't do tail call optimization
>
> > This is mostly true. But recur extends typical recursion, by enabling
> > anonymous functions to call themselves.
>
> >> This is a clear expressive problem with the
> >> language that is forced on it by the fact that it runs on the jvm -
> >> if I don't want stack to explode I may *not* use an ordinary
> >> recursive function (or mutually recursive functions) but must instead
> >> use a different form - loop/recur or trampoline.
>
> > This is correct. At this moment it is still true that Clojure
> > programmers need to learn a new idiom to code mutual recursive
> > functions.
> > This idiom is a bit more complex, so this is a disadvantage.
> > But let’s not forget that tail recursion itself already is a
> > “hack” for recursion. We already have to think about how to do tail
> > recursion, even in the simple case. We need to introduce an artificial
> > labels that needs a helper arg, and then put the call into the tail
> > position. We can’t do it like this:
>
> > (defun summing (n)
> > (if (zerop n)
> > 0
> > (+ n (summing (1- n)))))
>
> > but need instead:
>
> > (defun summing2 (n)
> > (labels ((helper (n result)
> > (if (zerop n)
> > result
> > (helper (1- n) (+ result n)))))
> > (helper n 0)))
>
> > And when I do this in Lispworks, I get:
> > CL-USER 5 > (summing2 100)
> > Stack overflow (stack size 15997).
>
> Rewriting to TAILPROG, almost closed eyes! All I'm doing is
> transliterating the syntax (labels ...) to (tailprog () ...):
>
> (defun summing2 (n)
> (tailprog () ((helper (n result)
> (if (zerop n)
> result
> (helper (1- n) (+ result n)))))
> (helper n 0)))
(compile (defun summing (n &optional (r 0))
(if (zerop n) r (summing (1- n) (+ r n)))))
>
> (summing2 100) -> 5050
>
> (summing2 1000000) -> 500000500000
>
> (summing2 100000000) -> 5000000050000000
>
> I didn't bother compiling the first two cases.
>
> Are these the right results? I ``Gauss'' so. :) :) :)
>
> > As long something as summing2 is needed I personally see it as
> > an idiom, as a hack, that exists for practical reasons,
> > because we still don’t have infinite memory, or clever enough
> > compilers to make a summing2 out of summing under the hood *sigh*
> > Trampolines are not much worse than what I did in summing2.
>
> On the other hand, I don't regard TAILPROG as a hack, but a legitimate
> abstraction for expressing a more disciplined form of goto. There is no
> pretense that HELPER is a function. It is not and does not return, even if you
> write code that uses it in a non-tail position. Such a situation deserves a
> diagnostic (not currently implemented, future implementation).
>
> HELPER is understood to be the label for a block of code which is the target of
> an unconditional control transfer, accompanied by the passage of parameters.
>
> When HELPER's block of code terminates, the TAILPROG construct terminates, and
> passes out the result value. The termination does not go through
> (helper n 0) initial form, but directly from HELPER.
>
> So for instance it is understood that if the following change is made to the
> inductive form (helper n 0):
>
> (unwind-protect
> (helper n 0)
> (throw 'foo))
>
> Then the transfer to HELPER never takes place, because this is roughly
> equivalent to:
>
> ;; within some TAGBODY
> (unwind-protect
> (go some-label)
> (throw 'foo))
>
> The GO is a protected form, and it's performing a non-local control transfer in
> order to reach the labelled block. Before that transfer can complete, the
> cleanup form is evaluated, and this form hijacks the control transfer, taking
> it way farther out to some catch, terminating TAILPROG in the process.
Slobodan Blazeski schrieb:
> (compile (defun summing (n &optional (r 0))
> (if (zerop n) r (summing (1- n) (+ r n)))))
>
That�s unprofessional and not clean. I would not allow this
to slip through a code review.
Okay for one-man projects though.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Jan 22, 6:55 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Slobodan Blazeski schrieb:
>
> > (compile (defun summing (n &optional (r 0))
> > (if (zerop n) r (summing (1- n) (+ r n)))))
>
> That’s unprofessional and not clean. I would not allow this
> to slip through a code review.
I'm sorry sir will work on my tacit solution with anonymous recursion
over the weekened.
bobi
On 2009-01-22, Slobodan Blazeski <·················@gmail.com> wrote:
> On Jan 21, 10:25 pm, Kaz Kylheku <········@gmail.com> wrote:
>> [ .. snip many lines ... ]
>> Rewriting to TAILPROG, almost closed eyes! All I'm doing is
>> transliterating the syntax (labels ...) to (tailprog () ...):
>>
>> (defun summing2 (n)
>> (tailprog () ((helper (n result)
>> (if (zerop n)
>> result
>> (helper (1- n) (+ result n)))))
>> (helper n 0)))
>
> (compile (defun summing (n &optional (r 0))
> (if (zerop n) r (summing (1- n) (+ r n)))))
Not sure what you're trying to assert here. Firstly, Common Lisp compilers
aren't required to support tail recursion. But never mind.
/Expressing/ something in TAILPROG, is not the same thing as expressing
it as recursion and then hoping that it compiles to iteration.
TAILPROG is guaranteed not to use storage for control transfers that grows in
proportion to the number of iterations, even for control transfers which are
/not/ in what you would call ``tail position''.
This is valid TAILPROG:
(tailprog () ((foo (a b c)
(if (or (some-function) (foo a b c))
(some-other-function))))
(foo 1 2 3))
The (foo a b c) call is not what would be considered a tail position in the
equivalent LABELS, so the recursive call eats space.
> [ .. snip many lines ... ]
Could you do a better job of trimming quoted material?
In particular, this latter material was clearly in a tail position of the
article, and its value not being used. You missed an opportunity to
optimize it away! :)
On Jan 22, 10:03 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2009-01-22, Slobodan Blazeski <·················@gmail.com> wrote:
[snip]
> >> (defun summing2 (n)
> >> (tailprog () ((helper (n result)
> >> (if (zerop n)
> >> result
> >> (helper (1- n) (+ result n)))))
> >> (helper n 0)))
>
> > (compile (defun summing (n &optional (r 0))
> > (if (zerop n) r (summing (1- n) (+ r n)))))
>
> Not sure what you're trying to assert here.
Golfing of course, and mine's shorter.BTW only with programmers mine's
shorter is something to to be proud of.
> Firstly, Common Lisp compilers
> aren't required to support tail recursion. But never mind.
Hey which side you're on? All the modern common lisp compilers support
TCO, if the there are exceptions the should be named and shamed.
[snip]
> Could you do a better job of trimming quoted material?
I'm trying but I use google groups so I often forget that not
everybody else is doing that.
> In particular, this latter material was clearly in a tail position of the
> article, and its value not being used. You missed an opportunity to
> optimize it away! :)
I'm not in a speed camp.
bobi
Premature optimization is the root of all evil.
Andr� Thieme <······························@justmail.de> wrote:
+---------------
| Raffael Cavallaro schrieb:
| > Oh please! The *only* reason that clojure has the need for loop/recur
| > and trampoline is because the jvm doesn't do tail call optimization
|
| This is mostly true. But recur extends typical recursion, by enabling
| anonymous functions to call themselves.
+---------------
You can easily implement the Y combinator in standard Scheme
or Common Lisp, which gets you exactly the same functionality.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <glac4c$ukf$3@news.motzarella.org>
Rob Warnock schrieb:
> You can easily implement the Y combinator in standard Scheme
> or Common Lisp, which gets you exactly the same functionality.
Yes. I mentioned this some days ago.
It’s just that we then end up with something like recur anyway.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On Jan 21, 7:22 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Raffael Cavallaro schrieb:
>
> > On 2009-01-20 14:57:14 -0500, André Thieme
> > <······························@justmail.de> said:
>
> > Oh please! The *only* reason that clojure has the need for loop/recur
> > and trampoline is because the jvm doesn't do tail call optimization
>
> This is mostly true. But recur extends typical recursion, by enabling
> anonymous functions to call themselves.
>
> > This is a clear expressive problem with the
> > language that is forced on it by the fact that it runs on the jvm -
> > if I don't want stack to explode I may *not* use an ordinary
> > recursive function (or mutually recursive functions) but must instead
> > use a different form - loop/recur or trampoline.
>
> This is correct. At this moment it is still true that Clojure
> programmers need to learn a new idiom to code mutual recursive
> functions.
> This idiom is a bit more complex, so this is a disadvantage.
> But let’s not forget that tail recursion itself already is a
> “hack” for recursion. We already have to think about how to do tail
> recursion, even in the simple case. We need to introduce an artificial
> labels that needs a helper arg,
No we don't. There's something called &optional in common lisp. See my
answer to Kaz as example.
>and then put the call into the tail
> position. We can’t do it like this:
>
> (defun summing (n)
> (if (zerop n)
> 0
> (+ n (summing (1- n)))))
>
> but need instead:
>
> (defun summing2 (n)
> (labels ((helper (n result)
> (if (zerop n)
> result
> (helper (1- n) (+ result n)))))
> (helper n 0)))
>
> And when I do this in Lispworks, I get:
> CL-USER 5 > (summing2 100)
>
> Stack overflow (stack size 15997).
> 1 (continue) Extend stack by 50%.
> 2 Extend stack by 300%.
> 3 (abort) Return to level 0.
> 4 Return to top loop level 0.
>
> (after compilation of summing2 it works of course)
So? How do you expect lispworks to give you helpful debug information
if it removes the stack.
>
> As long something as summing2 is needed I personally see it as
> an idiom, as a hack, that exists for practical reasons,
> because we still don’t have infinite memory, or clever enough
> compilers to make a summing2 out of summing under the hood *sigh*
> Trampolines are not much worse than what I did in summing2.
Recur is already unacceptable. How much worse do you need?
>
> > At least Rich Hickey is straightforward and honest about it - clojure
> > has this tail call issue because of the jvm; clojure has two
> > workarounds, loop/recur and trampoline; Rich Hickey would *clearly*
> > prefer that the jvm support tail calls properly so he could remove
> > loop/recur and trampoline from clojure.
>
> Of course he would like the JVM to have TC support. But he won’t
> removerecur, and I guess he will also keep trampolines.
Rich Hickey seems like a smart guy, I doubt he'll keep seomething so
stupid unless there's a millions lines of Clojure that need it for
backward compatibility.
>
> But I think we should focus on my main criticism again.
We should focus on you being stubborn to deny everything that doesn't
fit your nonexisting knowledge of how implementations of lisp or any
other language work, combined with arguing everybody who bothers to
prove you the opposite. Not to mention dodging answer of what kind of
experience you have in implementing lisp or any other langauge, that I
repeated several times.
Even froggy understood that you don't know what hell are you talking
about, nevertheless you continue with your: my pride is hurt so I'll
just continue to post my already several times ripped to pieces
garbage, attitude. Grow up.
bobi
Slobodan Blazeski schrieb:
> On Jan 21, 7:22 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> This idiom is a bit more complex, so this is a disadvantage.
>> But let�s not forget that tail recursion itself already is a
>> �hack� for recursion. We already have to think about how to do tail
>> recursion, even in the simple case. We need to introduce an artificial
>> labels that needs a helper arg,
> No we don't. There's something called &optional in common lisp. See my
> answer to Kaz as example.
Ah, you begin to show us more about your competency in programming.
Now after you babbled about how experienced you are, you disqualify
yourself with statements like these.
>> As long something as summing2 is needed I personally see it as
>> an idiom, as a hack, that exists for practical reasons,
>> because we still don�t have infinite memory, or clever enough
>> compilers to make a summing2 out of summing under the hood *sigh*
>> Trampolines are not much worse than what I did in summing2.
> Recur is already unacceptable. How much worse do you need?
Why don� you stop to bring yourself in even more embarrassing
situations?
Or can you offer a good explanation *why* recur is unacceptable?
>>> At least Rich Hickey is straightforward and honest about it - clojure
>>> has this tail call issue because of the jvm; clojure has two
>>> workarounds, loop/recur and trampoline; Rich Hickey would *clearly*
>>> prefer that the jvm support tail calls properly so he could remove
>>> loop/recur and trampoline from clojure.
>> Of course he would like the JVM to have TC support. But he won�t
>> removerecur, and I guess he will also keep trampolines.
> Rich Hickey seems like a smart guy, I doubt he'll keep seomething so
> stupid unless there's a millions lines of Clojure that need it for
> backward compatibility.
Exactly because he is clever he said:
http://clojure-log.n01se.net/date/2008-10-18.html#10:00-10:01
Only a very uninformed person can make such embarrassing claims.
>> But I think we should focus on my main criticism again.
> We should focus on you being stubborn to deny everything that doesn't
> fit your nonexisting knowledge of how implementations of lisp or any
> other language work, combined with arguing everybody who bothers to
> prove you the opposite. Not to mention dodging answer of what kind of
> experience you have in implementing lisp or any other langauge, that I
> repeated several times.
> Even froggy understood that you don't know what hell are you talking
> about, nevertheless you continue with your: my pride is hurt so I'll
> just continue to post my already several times ripped to pieces
> garbage, attitude. Grow up.
I am sorry if I hurt your pride.
It seems to be that way.
But really, you posted some very confused stuff.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Jan 22, 7:26 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Slobodan Blazeski schrieb:
>
> > On Jan 21, 7:22 pm, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> This idiom is a bit more complex, so this is a disadvantage.
> >> But let’s not forget that tail recursion itself already is a
> >> “hack” for recursion. We already have to think about how to do tail
> >> recursion, even in the simple case. We need to introduce an artificial
> >> labels that needs a helper arg,
> > No we don't. There's something called &optional in common lisp. See my
> > answer to Kaz as example.
>
> Ah, you begin to show us more about your competency in programming.
> Now after
..I showed you how to write elegant solution instead of tickering with
unneeded labels you fail to get it. When you posted your code you
made a challenge (*) and Kaz & I took it. The current score is that
you're 4 strokes behind me. Unless you could make better( usually
shorter but it could be more efficient) solution you lost.Getting
personal just shows how immature you are and not being able to accept
defeat.
> >> As long something as summing2 is needed I personally see it as
> >> an idiom, as a hack, that exists for practical reasons,
> >> because we still don’t have infinite memory, or clever enough
> >> compilers to make a summing2 out of summing under the hood *sigh*
> >> Trampolines are not much worse than what I did in summing2.
> > Recur is already unacceptable. How much worse do you need?
> Why don’ you stop to bring yourself in even more embarrassing
> situations?
I don't I enjoy batting you.
> Or can you offer a good explanation *why* recur is unacceptable?
Because it's implementation hack of doing something that's compilers'
job. I could bet that when clojure improves, it's users will be able
to code as lispers ans schemers are doing now.
>
> >>> At least Rich Hickey is straightforward and honest about it - clojure
> >>> has this tail call issue because of the jvm; clojure has two
> >>> workarounds, loop/recur and trampoline; Rich Hickey would *clearly*
> >>> prefer that the jvm support tail calls properly so he could remove
> >>> loop/recur and trampoline from clojure.
> >> Of course he would like the JVM to have TC support. But he won’t
> >> removerecur, and I guess he will also keep trampolines.
> > Rich Hickey seems like a smart guy, I doubt he'll keep seomething so
> > stupid unless there's a millions lines of Clojure that need it for
> > backward compatibility.
>
> Exactly because he is clever he said:http://clojure-log.n01se.net/date/2008-10-18.html#10:00-10:01
I can't accept this without a prove, give me an example of a function
that is better with recur compared with the common lisp version. And
will see what's the right way to do it.
>
> >> But I think we should focus on my main criticism again.
> > We should focus on you being stubborn to deny everything that doesn't
> > fit your nonexisting knowledge of how implementations of lisp or any
> > other language work, combined with arguing everybody who bothers to
> > prove you the opposite. Not to mention dodging answer of what kind of
> > experience you have in implementing lisp or any other langauge, that I
> > repeated several times.
> > Even froggy understood that you don't know what hell are you talking
> > about, nevertheless you continue with your: my pride is hurt so I'll
> > just continue to post my already several times ripped to pieces
> > garbage, attitude. Grow up.
>
> I am sorry if I hurt your pride.
Actually I'm having a really good time batting you.
BTW:
(INCF *doging-answer-of-what-kind-of-experience-you-kave-in-
implementing-lisp*)
bobi
(*) This http://en.wikipedia.org/wiki/Perl#Perl_golf but in lisp. I
learned very much from this small exercises.
Slobodan Blazeski schrieb:
> On Jan 22, 7:26 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Slobodan Blazeski schrieb:
>>
>>> On Jan 21, 7:22 pm, Andr� Thieme <address.good.until.
>>> ···········@justmail.de> wrote:
>>>> This idiom is a bit more complex, so this is a disadvantage.
>>>> But let�s not forget that tail recursion itself already is a
>>>> �hack� for recursion. We already have to think about how to do tail
>>>> recursion, even in the simple case. We need to introduce an artificial
>>>> labels that needs a helper arg,
>>> No we don't. There's something called &optional in common lisp. See my
>>> answer to Kaz as example.
>> Ah, you begin to show us more about your competency in programming.
>> Now after
> ..I showed you how to write elegant solution instead of tickering with
> unneeded labels you fail to get it.
Your solution was not elegant. It exposes an optional argument to the
user. This is also bad documentation. A tool that generates docs from
your code would want a description for that argument.
> When you posted your code you made a challenge (*) and Kaz & I took it.
> The current score is that you're 4 strokes behind me.
Why 4?
The version that I produced was much longer, in keystrokes:
(defun summing2 (n)
(labels ((helper (n result)
(if (zerop n)
result
(helper (1- n) (+ result n)))))
(helper n 0)))
vs.
(defun summing (n &optional (r 0))
(if (zerop n)
r
(summing (1- n) (+ r n))))
Thats:
(count "(defun summing (n) (labels ((helper (n result) (if (zerop n)
result (helper (1- n) (+ result n))))) (helper n 0)))") ==> 114
(count "(defun summing (n &optional (r 0)) (if (zerop n) r (summing (1-
n) (+ r n))))") ==> 77
If we exchange your r with result we get still just 92 chars for your
version.
In Clojure I could suggest for example:
(defn summing [n]
((fn [n r]
(if (zero? n)
r
(recur (dec n) (+ r n))))
n 0))
That is
(count "(defn summing [n] ((fn [n r] (if (zero? n) r (recur (dec n) (+ r
n)))) n 0))") ==> 76
So, one shorter than your solution.
Or with loop, same length:
(defn summink [n]
(loop [i n
r 0]
(if (zero? i)
r
(recur (dec i) (+ r i)))))
Or just:
(defn summing [n] (reduce + (range (inc n))))
or
(defn summing [n] (apply + (range (inc n))))
or I could have a collection of all sums, with implicit memoization:
(def sums (lazy-cat [0] (map + sums (iterate inc 1))))
user> (take 10 abce)
(0 1 3 6 10 15 21 28 36 45)
user> (time (nth sums 80000))
"Elapsed time: 183.88838 msecs"
3200040000
user> (time (nth sums 80001))
"Elapsed time: 3.884468 msecs"
3200120001
When looking at the size of code and still offering correctness, then
your version wins. One could only save some more chars by shortening the
name of the function itself.
> Unless you could make better (usually
> shorter but it could be more efficient) solution you lost. Getting
> personal just shows how immature you are and not being able to accept
> defeat.
My criticism about how professional your solution is, is nothing personal.
You will have to admit that it is bad style to misuse &optional to
just safe a labels. It also does not a good job at documenting the code.
People will expect that it sometimes will make sense to call that
function with an argument for the optional parameter.
>> Why don� you stop to bring yourself in even more embarrassing
>> situations?
> I don't I enjoy batting you.
Well okay, that was indeed personal. Sorry for that. *sigh*
I just did not like these comparisons about penis length.
Or in other words: experience with implementing Lisp, which has not much
to do with the original statement that started all this:
�[...] lisp is just working better under it's own VM than JVM.�
Note that the original statement was not something like:
�it�s easier to implement Lisp with its own VM instead of the JVM�.
I gave some arguments that suggest that even if you would have made
that statement, it is not definitly clear that it would be true.
But my criticism is that �working better� is not an objective fact.
Clojure is really working, and I don�t see that only because it runs
on the JVM makes it work worse.
>> Or can you offer a good explanation *why* recur is unacceptable?
> Because it's implementation hack of doing something that's compilers'
> job. I could bet that when clojure improves, it's users will be able
> to code as lispers ans schemers are doing now.
It is not so much Clojure that has to improve. It would not cost very
much time to give Clojure full support for tail calls, if the JVM would
offer them.
But yes, as soon they are in, people will use them for mutual recursive
functions.
But for the most typical case of recursion, namely functions that call
themselfs, I still suggest to use recur.
>>> Rich Hickey seems like a smart guy, I doubt he'll keep seomething so
>>> stupid unless there's a millions lines of Clojure that need it for
>>> backward compatibility.
>> Exactly because he is clever he said:http://clojure-log.n01se.net/date/2008-10-18.html#10:00-10:01
> I can't accept this without a prove, give me an example of a function
> that is better with recur compared with the common lisp version. And
> will see what's the right way to do it.
I did not say that recur is *better*. I just say it is not worse, as you
suggested. recur will ensure that there are no problems with the stack
and is fast. And in fact, it offers two features that I personally really
regard as �better�:
1) anon functions can recursively call themself. No need for a Y combinator.
2) there is an idiomatic way for the most typical kind of recursion.
You can use the search function of your editor to find the next recur,
you can automatically count the number of recurs, etc.
Whenever you see it, you will know a recursive call takes place.
So, even when the JVM gets full support for tail recursion, I think and
hope that most Clojurists will continue to use recur.
And here I would like to metion again my dream of abstracting tail
recursion away, with great compiler technology. I would like to have:
(defn summing [n]
(if (zero? n)
0
(+ n (summing (dec n)))))
That�s close to math, no artificial result parameter needed, no helper
function, no dirty optional argument. Just nice code.
Unfortunately not safe for the stack with todays compilers.
Or am I wrong? Can the Stalin Scheme compiler optimize functions like
that to do gotos under the hood?
> Actually I'm having a really good time batting you.
Uh! Didn�t you say a few paragraphs above that you don�t enjoy it? ;-)
> BTW:
> (INCF *doging-answer-of-what-kind-of-experience-you-kave-in-
> implementing-lisp*)
About as much as you. Probably a bit less, I don�t know how much
knowledge we gained while learning about it. I spent +/- six months
with that issue, over the course of several years.
For my genetic programming engine I implemented a few evals, to make
it faster (yes, for several tasks an interpreter is indeed more
efficient than a compiler *shrugs*).
But still, I don�t think this is too important for the discussion
itself. I also had three jobs so far in which I used Common Lisp
professionally, starting some years ago. And currently I am a senior
developer with Lisp, in the area of artificial intelligence.
I am thankful that I am one of the few who love Lisp and actually
have the opportunity to get paid work to use it.
I even left two times my city to get a Lisp job, and one time I
even left Germany. But it was worth it.
So, while I am no Duane or Weitz or Pitman, I believe to now have
enough experience to give my informed opinion.
I don�t care if my discussion partners ever had a professional Lisp
job or how many years they spent with it.
And although I see a great future for Clojure, and although I personally
prefer it over CL for my interests, it does not mean that I dislike CL.
I think it�s fair to say that a person who even leaves his/her country
to get a CL job, is very interested in Lisp. I see no problems with
enjoying *both* at the same time.
> (*) This http://en.wikipedia.org/wiki/Perl#Perl_golf but in lisp. I
> learned very much from this small exercises.
Ah okay.
If you want to learn Clojure you could for example solve a few tasks
from http://projecteuler.net/ with it.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Jan 23, 11:24 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> [snipped]
I hope you'll tell your grandchildren how you wrote 100 billions lines
of code, and that you kept all your methods private, you were extra
careful about inheritance, used sealed classes, didn't delay anything
until run time etc etc. Now that I know that you're Java kind of
person in heart(*) posing as lisper, we don't have a mutual reference
point to continue this discussion. Something like two religious
fundamentalists talking which god is greater. It's pointless.
And by the way there is a shorter solution than:
(defun summing (n &optional (r 0))
(if (zerop n) r (summing (1-n) (+ r n))))
and no it's not this one, below is just the same, actually little
worse, since there's one token more.
(defun s (n &optional (r 0))
(if (= n 0) r (s (1- n) (+ r n))))
To give you some idea of what golfing and expressiveness in several
languages consists of I recommend you read this article:
http://pozorvlak.livejournal.com/89208.html it will explain my
reference point of valuing languages.
cheers
bobi
(*) In heart as in something you (sometimes subconsciously) believe in
that is the right way to do it. For example I'm a common lisp
programmer, I believe in common lisp way of things. But few months ago
I understood that I'm a schemer in heart. Though I still label my self
as common lisper, and I still believe that feature rich language is
better than a minimalistic one, lisp1 and continuations are something
I envy schemers.
On Jan 25, 11:39 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jan 23, 11:24 pm, André Thieme <······························@justmail.de> wrote:
> > [snipped]
>
> I hope you'll tell your grandchildren how you wrote 100 billions lines
> of code, and that you kept all your methods private, you were extra
> careful about inheritance, used sealed classes, didn't delay anything
> until run time etc etc. Now that I know that you're Java kind of
> person in heart(*) posing as lisper, we don't have a mutual reference
> point to continue this discussion. Something like two religious
> fundamentalists talking which god is greater. It's pointless.
>
> And by the way there is a shorter solution than:
> (defun summing (n &optional (r 0))
> (if (zerop n) r (summing (1-n) (+ r n))))
> and no it's not this one, below is just the same, actually little
> worse, since there's one token more.
> (defun s (n &optional (r 0))
> (if (= n 0) r (s (1- n) (+ r n))))
> To give you some idea of what golfing and expressiveness in several
> languages consists of I recommend you read this article:http://pozorvlak.livejournal.com/89208.htmlit will explain my
Sorry wrong link, it only shows golfing this one is better for
comparing different languages:
http://pozorvlak.livejournal.com/91293.html?thread=807837
> reference point of valuing languages.
>
> cheers
> bobi
>
> (*) In heart as in something you (sometimes subconsciously) believe in
> that is the right way to do it. For example I'm a common lisp
> programmer, I believe in common lisp way of things. But few months ago
> I understood that I'm a schemer in heart. Though I still label my self
> as common lisper, and I still believe that feature rich language is
> better than a minimalistic one, lisp1 and continuations are something
> I envy schemers.
Slobodan Blazeski <·················@gmail.com> writes:
> Though I still label my self as common lisper, and I still believe
> that feature rich language is better than a minimalistic one, lisp1
> and continuations are something I envy schemers.
I came to Common Lisp having come through SICP and Scheme.
CL's Lisp-2-ness seemed like an archaic implementation hack of some
kind, and I objected loudly at people[1].
But the gyrations needed to get anything useful out of Scheme's macro
system are pretty awful. I remember fighting with MIT Scheme's[2]
syntactic closures, which were (a) an escape from the weakness of
syntax-rules, and (b) worked on honest lists, unlike syntax-case; but I
had to write destructuring-bind myself, and so on... CL's much simpler
and more pragmatic approach to macros led me to understanding that a
Lisp-n is not a bad thing; it also showed me why the package system is
the Right Way to avoid name clashes -- i.e., provide different
subsystems with different name-to- symbol mappings, rather than
different symbol-to-variable/function/type/slot/label/block-name/
catch-tag/... mappings. (I've never seen slot namespaces handled
properly elsewhere anyway.)
I'll certainly agree with you about continuations. I frequently find
myself missing them in other languages. But I've always been a fan of
coroutines as a way of dealing with conflicting views of the direction
function-calls should be happening.
[1] I'm prone to complaining loudly at nearby people about whatever
stupidity I think I've found recently in real life as well as on
Usenet...
[2] Don't get me started on MIT Scheme's broken implementation of
multiple-values!
-- [mdw]
Slobodan Blazeski schrieb:
> On Jan 23, 11:24 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
> I hope you'll tell your grandchildren how you wrote 100 billions lines
Billions? Trillions!
There passes no single day in which I won�t write a least a few million
lines of code. ;-)
> of code, and that you kept all your methods private, you were extra
> careful about inheritance, used sealed classes,
Honestly, I am not into OOP anymore, if I am not forced to do so.
At least for the stuff that I do, functional programming is what I prefer.
Be this CL or Clojure, where functional programming is the idiomatic
way to code.
> Now that I know that you're Java kind of person in heart(*)
Oh, you know more about me than I do :-)
Really, I like the JVM. And Lispers should be glad that there are
Lisps targetting it.
> posing as lisper, we don't have a mutual reference
> point to continue this discussion. Something like two religious
> fundamentalists talking which god is greater. It's pointless.
Oh sorry, I didn�t know that programming languages are like a
religion for you. I am an Atheist, and for me programming languages
are tools. Okay, I see we disagree here.
> And by the way there is a shorter solution than:
> (defun summing (n &optional (r 0))
> (if (zerop n) r (summing (1-n) (+ r n))))
> and no it's not this one, below is just the same, actually little
> worse, since there's one token more.
> (defun s (n &optional (r 0))
> (if (= n 0) r (s (1- n) (+ r n))))
Or even better:
(defn s [n] (apply + (range (inc n))))
And still better:
(def s #(apply + (range (+ 1 %))))
Cool, I won :-)
> (*) In heart as in something you (sometimes subconsciously) believe in
> that is the right way to do it. For example I'm a common lisp
> programmer, I believe in common lisp way of things.
I think it�s fair to say this about me as well. Someone who had and also
at this moment has a CL job, and left his city and even country to get
one, that person can be also called a Common Lisp programmer.
> But few months ago I understood that I'm a schemer in heart.
It�s a Lisp, so, all the same family :-)
And maybe Scheme is just what you prefer for the kind of things you do.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Jan 25, 9:38 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Slobodan Blazeski schrieb:
> > And by the way there is a shorter solution than:
> > (defun summing (n &optional (r 0))
> > (if (zerop n) r (summing (1-n) (+ r n))))
> > and no it's not this one, below is just the same, actually little
> > worse, since there's one token more.
> > (defun s (n &optional (r 0))
> > (if (= n 0) r (s (1- n) (+ r n))))
>
> Or even better:
> (defn s [n] (apply + (range (inc n))))
>
> And still better:
> (def s #(apply + (range (+ 1 %))))
>
> Cool, I won :-)
No you don't, it's not doing the same thing and that's called
cheating:
(range end)
(range start end)
(range start end step)
Returns a lazy seq of nums from start (inclusive) to end (exclusive),
by step, where start defaults to 0 and step to 1.
Don't change the rules when they suit you. I could also do this:
(defun s (n) (/ (* n (1+ n)) 2))
but that's not the same thing.
bobi
On Jan 26, 2:28 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jan 25, 9:38 pm, André Thieme <address.good.until.
>
> ···········@justmail.de> wrote:
> > Slobodan Blazeski schrieb:
> > > And by the way there is a shorter solution than:
> > > (defun summing (n &optional (r 0))
> > > (if (zerop n) r (summing (1-n) (+ r n))))
> > > and no it's not this one, below is just the same, actually little
> > > worse, since there's one token more.
> > > (defun s (n &optional (r 0))
> > > (if (= n 0) r (s (1- n) (+ r n))))
>
> > Or even better:
> > (defn s [n] (apply + (range (inc n))))
>
> > And still better:
> > (def s #(apply + (range (+ 1 %))))
>
> > Cool, I won :-)
>
> No you don't, it's not doing the same thing and that's called
> cheating:
> (range end)
> (range start end)
> (range start end step)
> Returns a lazy seq of nums from start (inclusive) to end (exclusive),
> by step, where start defaults to 0 and step to 1.
>
> Don't change the rules when they suit you. I could also do this:
> (defun s (n) (/ (* n (1+ n)) 2))
> but that's not the same thing.
I wonder whether Andy knows how not to cheat.
·········@yahoo.com schrieb:
> I wonder whether Andy knows how not to cheat.
You are a great teacher.
But you are so advanced at it, I guess no one from this newsgroup
will ever be able to catch up with you.
Btw, where is the Ruby code for the fibs? Alternatively you can
present a solution in Comal.
Extend this program:
10 PAGE
20 FOR number:= 1 TO 10 DO
30 PRINT "THIS IS JUST AN EXAMPLE"
40 ENDFOR
50 END " "
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On 2009-01-26, ·········@yahoo.com <·········@yahoo.com> wrote:
> I wonder whether Andy knows how not to cheat.
I wonder how soon your your nurse will realize you crapped your pants.
Andr� Thieme wrote:
> > (defun summing (n &optional (r 0))
> > (if (zerop n) r (summing (1-n) (+ r n))))
> > and no it's not this one, below is just the same, actually little
> > worse, since there's one token more.
> > (defun s (n &optional (r 0))
> > (if (= n 0) r (s (1- n) (+ r n))))
>
OCaml:
# let rec sum accum = function
0 -> accum
| n -> sum (accum+n) (n-1)
;;
# sum 0 9;;
- : int = 45
> Or even better:
> (defn s [n] (apply + (range (inc n))))
>
> And still better:
> (def s #(apply + (range (+ 1 %))))
>
Ruby:
def s n;(1..n).inject{|a,b|a+b} end
On Jan 26, 1:34 am, "William James" <·········@yahoo.com> wrote:
> André Thieme wrote:
> > > (defun summing (n &optional (r 0))
> > > (if (zerop n) r (summing (1-n) (+ r n))))
This is 16 tokens.
> > > and no it's not this one, below is just the same, actually little
> > > worse, since there's one token more.
> > > (defun s (n &optional (r 0))
> > > (if (= n 0) r (s (1- n) (+ r n))))
>
> OCaml:
>
> # let rec sum accum = function
> 0 -> accum
> | n -> sum (accum+n) (n-1)
> ;;
OCaml 19 tokens
> # sum 0 9;;
> - : int = 45
>
> > Or even better:
> > (defn s [n] (apply + (range (inc n))))
>
> > And still better:
> > (def s #(apply + (range (+ 1 %))))
Both Clojure solutions are unacceptable since they're working over
range instead of peano (is that the name?)
>
> Ruby:
>
> def s n;(1..n).inject{|a,b|a+b} end
This is unacceptable too. http://blog.jayfields.com/2008/03/ruby-inject.html
bobi
William James schrieb:
> Andr� Thieme wrote:
>
>>> (defun summing (n &optional (r 0))
>>> (if (zerop n) r (summing (1-n) (+ r n))))
>>> and no it's not this one, below is just the same, actually little
>>> worse, since there's one token more.
>>> (defun s (n &optional (r 0))
>>> (if (= n 0) r (s (1- n) (+ r n))))
>
> OCaml:
>
> # let rec sum accum = function
> 0 -> accum
> | n -> sum (accum+n) (n-1)
> ;;
> # sum 0 9;;
> - : int = 45
>
>
>> Or even better:
>> (defn s [n] (apply + (range (inc n))))
>>
>> And still better:
>> (def s #(apply + (range (+ 1 %))))
>>
>
> Ruby:
>
> def s n;(1..n).inject{|a,b|a+b} end
>
Thanks for providing these other versions. So now we can compare them
and see which is the best programming language. This is determined by
character count:
OCaml: 68 chars
(count "let rec sum accum = function 0 -> accum | n -> sum (accum+n)
(n-1);;")
==> 68
Ruby: 35 chars
(count "def s n;(1..n).inject{|a,b|a+b} end")
==> 35
Lisp (Clojure): 34 chars
(count "(def s #(apply + (range (+ 1 %))))")
==> 34
The Ruby code is still readable, although one would usually put a few
more spaces in. I can remove two spaces in the Clojure code as well.
But even without that we have:
1. Lisp
2. Ruby
3. OCaml
Can you also supply the OCaml and Ruby version that assigns the sequence
of all Fibonaccis to a variable �fibs�?
Such as:
(def fibs (lazy-cat [0 1] (map + fibs (drop 1 fibs))))
Note that fibs is not assigned a function object, but the infinite
sequence of all fibs:
user> (take 15 fibs)
(0 1 1 2 3 5 8 13 21 34 55 89 144 233 377)
user> (nth fibs 45)
1134903170
And this needs to be memoized as well:
(time (nth fibs 80000)) ==> "Elapsed time: 3126.904886 msecs"
(time (nth fibs 80001)) ==> "Elapsed time: 11.774765 msecs"
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
Pascal J. Bourguignon wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> The "goto" is jump between instruction blocks that share a stack frame
>> (i.e. within a function or exception handler) and correspond to a branch
>> or jump assembly instruction. Tail calls jump between functions that do
>> not necessarily share a stack frame and the code generator is responsible
>> for overwriting the caller's stack frame with the callee's stack frame.
>> Note, in particular, that the callee may have a larger stack frame than
>> the caller.
>>
>> So tail calls must handle all stack allocations which includes parameters
>> but also other entities such as struct return values.
>
> You're looking implementation details here.
Tail calls are an implementation detail.
> You must see it at a more abtract level.
>
> (block :exit
> (let (a b c)
> (tagbody
> (setf a 1)
> (setf b 2)
> :small
> (when (< 10 a) (return-from :exit b))
> (setf a (+ a b))
> (go :big)
> :big
> (setf c (* a b))
> (setf a (- c a))
> (setf b (- c b))
> (go :small))))
>
> Here, you can see that the :small 'block' uses only two slots in the
> stack frame, while the :big 'block' uses three slots. However, all
> stack allocations have been handled.
>
> In any case, you only have to show us an expression with goto or with
> tail calls, along with the proof that it cannot be translated into the
> other form to prove your assertion. But I'll bet that whatever your
> expression, we will be able to translate it into the other form
> easily.
Rewrite your example in CPS and try again.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-01-18, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> On 2009-01-18, Jon Harrop <···@ffconsultancy.com> wrote:
>>> Kaz Kylheku wrote:
>>>> Tail calling is just goto with parameter passing.
>>>
>>> No, it isn't.
>>
>> Please show a tail calling example in Lisp, or pseudocode, that you think
>> does not correspond to goto with parameter passing.
>
> The "goto" is jump between instruction blocks that share a stack frame (i.e.
> within a function or exception handler) and correspond to a branch or jump
[ snip ]
Doesn't look like an example to me. Take two.
> assembly instruction. Tail calls jump between functions that do not
These statements are about a particular implementation, not about
the abstraction of tail calling.
> necessarily share a stack frame and the code generator is responsible for
> overwriting the caller's stack frame with the callee's stack frame.
No such thing is required for the tail calling abstraction.
It's a possible implementation. It's one that is typically done
when the implementor is confused about what tail calling is, and
thinks it something that has to be shoehorned into functions.
> in particular, that the callee may have a larger stack frame than the
> caller.
>
> So tail calls must handle all stack allocations which includes parameters
> but also other entities such as struct return values.
So basically you are not able to reason about a high level programming language
feature without resorting to implementation-level entities like stack frames,
etc.
Kaz Kylheku wrote:
> On 2009-01-18, Jon Harrop <···@ffconsultancy.com> wrote:
>> Kaz Kylheku wrote:
>>> On 2009-01-18, Jon Harrop <···@ffconsultancy.com> wrote:
>>>> Kaz Kylheku wrote:
>>>>> Tail calling is just goto with parameter passing.
>>>>
>>>> No, it isn't.
>>>
>>> Please show a tail calling example in Lisp, or pseudocode, that you
>>> think does not correspond to goto with parameter passing.
>>
>> The "goto" is jump between instruction blocks that share a stack frame
>> (i.e. within a function or exception handler) and correspond to a branch
>> or jump
>
> [ snip ]
>
> Doesn't look like an example to me. Take two.
Any program in continuation passing style (CPS) is an example. Here is a
trivial example from a term rewriter written in CPS:
# let rec rewrites rewrite exprs k =
match exprs with
| [] -> k []
| h::t ->
rewrite rewrite h (fun h ->
rewrites rewrite t (fun t -> k (h::t)));;
val rewrites :
('a -> 'b -> ('c -> 'd) -> 'd as 'a) -> 'b list -> ('c list -> 'd) -> 'd =
<fun>
There are four tail calls to other functions in that function body. The two
tail calls to "k" are not statically known because "k" is a function
argument.
>> assembly instruction. Tail calls jump between functions that do not
>
> These statements are about a particular implementation, not about
> the abstraction of tail calling.
What particular implementation?
>> necessarily share a stack frame and the code generator is responsible for
>> overwriting the caller's stack frame with the callee's stack frame.
>
> No such thing is required for the tail calling abstraction.
How will you handle a tail call into a callee that has more local variables
than the caller did?
>> in particular, that the callee may have a larger stack frame than the
>> caller.
>>
>> So tail calls must handle all stack allocations which includes parameters
>> but also other entities such as struct return values.
>
> So basically you are not able to reason about a high level programming
> language feature without resorting to implementation-level entities like
> stack frames, etc.
How do you interpret high-level language failures like stack overflows
without resorting to implementation-level entities like the stack?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Sun, 18 Jan 2009 09:11:34 +0000, Kaz Kylheku wrote:
> On 2009-01-17, Jon Harrop <···@ffconsultancy.com> wrote:
>> Lack of tail calls is an absolutely crippling problem.
>
> Tail calling is just goto with parameter passing.
>
> The rest of your article only demonstrates that stupidity is a crippling
> progblem for academic programmers.
Please... JH is neither an academic nor a programmer.
T
On Jan 17, 3:16 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Slobodan Blazeski schrieb:
>
> > On Jan 16, 9:51 am, Slobodan Blazeski <·················@gmail.com>
> > wrote:
> >> On Jan 15, 6:50 pm, André Thieme <······························@justmail.de> wrote:
> >>> Okay, I see that I understood the word “better” in the usual context,
> >> No you don't understand anything, grab a copy of SICP or Art of
> >> Interpreter and write one for yourself. Naive implementation is only a
> >> weekend of work.
> >> bobi
> > One more thing to add from Rich Hickey video 14:00
> > ..It (Clojure) does not have proper tail call optimization . And
> > that's because JVM doesn't support it and Clojure uses JVM calling
> > both for performace and interoperability.
> >http://blip.tv/file/812787?filename=Richhickey-ClojureConcurrency252.flv
>
> > So next time you blow up your stack, thanks the JVM for that.
>
> For someone who accuses others of not understanding anything one could
> think you would try to optimize your own knowledge base.
> While it is true that the current version of the JVM does not support
> tail calls, it does not mean that you constantly run into stack over-
> flows.
Only one stack overflow is enough to break the program. For a lisp
that relies on functional programming not having tail calls
optimization is simply unacceptable.
> Clojure offers several mechanisms to go in most cases around that
> problem, as (recur ...) or trampolines.
Do you offer goto to? Since when is my job to jump through hoops for
something that's a job the language. Clojure has many good ideas like
the one for building hash table, but recur is one of the worst
things.
> Also keep in mind that Sun is working on Fortress, which will most
> likely lead to built in TC support in the JVM.
Cool, tell me when they're done. But now they ain't got them. So you
will blow your stack or act as an human compiler.
bobi
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
Slobodan Blazeski schrieb:
> On Jan 17, 3:16 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
> Only one stack overflow is enough to break the program. For a lisp
> that relies on functional programming not having tail calls
> optimization is simply unacceptable.
For nearly every situation Clojure offers tail calls.
For the most typical kind of recursion, where a function calls itself,
there is recur. For mutual recursion there are trampolines.
I don�t know if there exist situations in which these two tools won�t
protect you from a stack overflow.
If anyone could provide an example I would be glad, so I would be more
aware when trampolines can�t help.
>> Clojure offers several mechanisms to go in most cases around that
>> problem, as (recur ...) or trampolines.
> Do you offer goto to? Since when is my job to jump through hoops for
> something that's a job the language. Clojure has many good ideas like
> the one for building hash table, but recur is one of the worst
> things.
What a BS... *shaking head*
What exactly about recur is bad?
It is the same thing as typical recursion of functions that call
themselves. You do the call as you would in Scheme/CL, but replace
the name of the function with �recur� and be done.
Heck, you can even have anonymous functions calling themselves without
the need for a Y-combinator.
When you make a lambda in CL and don�t bind it on some symbol, then it
is not extremly trivial to have this lambda recursively call itself.
Maybe in F# that�s also easy, don�t know.
>> Also keep in mind that Sun is working on Fortress, which will most
>> likely lead to built in TC support in the JVM.
> Cool, tell me when they're done. But now they ain't got them. So you
> will blow your stack or act as an human compiler.
Well, it�s programming, and with todays technology it still means the
programmer has to think.
I agree that it is a bit easier without trampolines as with. But not
very much, it is just an specific paradigm one can get used to.
One thing that would be really cool is if I could just call functions
at *any* point without thinking. Tail calls already mean that the
programmer has to think. He can not simply do make recursive calls
at any place he wants to.
One step forward would be if he could, and if the compiler then rewrites
the program in such a way, that all calls under the hood become gotos.
Andr�
--
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gkvlli$12ch$3@opal.icpnet.pl>
thus spoke André Thieme <······························@justmail.de>:
> For nearly every situation Clojure offers tail calls.
> For the most typical kind of recursion, where a function calls itself,
> there is recur. For mutual recursion there are trampolines.
> I don’t know if there exist situations in which these two tools won’t
> protect you from a stack overflow.
Clojure could certainly offer TCO for every tail call with
CPS-transformation. Then the stack is irrelevant and can be discarded
with longjmp when it's about to run out.
> If anyone could provide an example I would be glad, so I would be more
> aware when trampolines can’t help.
(progn (foo) (bar)) ; application of BAR is a tail call.
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
On Tue, 20 Jan 2009 18:33:01 +0000, Stanisław Halik wrote:
> thus spoke Jon Harrop <···@ffconsultancy.com>:
>
>>> Clojure could certainly offer TCO for every tail call with
>>> CPS-transformation. Then the stack is irrelevant and can be discarded
>>> with longjmp when it's about to run out.
>> CPS transformation requires TCO to work (it makes every call a tail
>> call) so it cannot be used to workaround the absence of TCO.
>
> That's not the way Chicken Scheme does it. The stack is only unwound
> when it's about to run out by means of longjmp. It's presumed that
> unwinding it once every n calls is cheaper than jumping to toplevel with
> every function application.
Doesn't Chicken's approach rely on being able to introspect/inspect stack
frames? You can do that in C, but I doubt very much that it's possible
in Java. Could be wrong, but it sounds like the sort of security
violation that the JVM was intended to prevent. Apart from anything, it
would be JVM implementation-dependent. I know of at least one (research)
JVM where the stack is a heap-based linked list of activation frames (for
the benefit of lots of threads in small VM).
Cheers,
--
Andrew
Slobodan Blazeski schrieb:
> On Jan 15, 6:50 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Okay, I see that I understood the word �better� in the usual context,
> No you don't understand anything, grab a copy of SICP or Art of
> Interpreter and write one for yourself. Naive implementation is only a
> weekend of work.
I don�t understand what�s the message.
When I want to implement a Scheme interpreter in Assembler or C it will
be dramatically much easier than doing it in Java?
Will the JVM simply refuse to run the interpreter?
No, of course not.
>> I just see that Clojure works very good. Some people would even argue,
>> that it works �better� than CL, whatever �better� means. And Clojure
>> runs on a JVM and is without a doubt Lisp. ABCL also compiles to the
>> code. So, it obviously is possible.
> From http://common-lisp.net/project/armedbear/ if situation improved
> please correct me:
> ABCL's CLOS is intolerably slow and does not handle on-the-fly
> redefinition of classes correctly. There is no support for the long
> form of DEFINE-METHOD-COMBINATION, and certain other required CLOS
> features are also missing. Enough CLOS is there to run ASDF and CL-
> PPCRE, if you're in no hurry. There's no MOP worth mentioning.
(equal speed better) ==> NIL
What exactly is it in the JVM that makes Lisps running under it
worse?
You simply expressed your opinion, which maybe was stated a bit unclear
because you felt provoked by Jon.
See, if now the guys from Franz who programmed Allego would take ten
years to implement CL on the JVM (they had more time to do it for
Windows), do you then think it will perform about as good as abcl?
A one-man project, done as a hobby?
I see no reason why such a Lisp should not be as good as any other.
If I assume that 3 people at Franz worked full time on Allegro, 150
hours per month, then they put 450 man-hours of work into it, per month.
That�s 5400 man-hours per year. In one decade this accumulates to 54.000
man-hours. Sorry, but noone here in c.l.l can convince me that experts
are not able to implement a decent CL within fiftythousand hours.
Yes, the 380 hours that went into ABCL don�t sum up, but who in the world
would find that strange?
> Landrover engine is possible in Porche and Kia, but it's not a right
> thing.
So, which is the better car?
This is obviously an opinion.
> According to http://common-lisp.net/~dlw/LispSurvey.html only one
> implementation Armed Bear works on JVM. So the majority of common lisp
> users think that JVM is bad idea, though there are some users who
> prefer it. So if you're member of the JVM camp good for your, enjoy
> Clojure or ABCL or whatever works for you. But the rest of us
> disagree.
Funny. Why is Jon not allowed to make conclusions from a simple google
search, but others are? ;-)
But anyway, thanks. Until now I am having fun.
Btw, with both: CL *and* Clojure.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Jan 17, 12:33 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Slobodan Blazeski schrieb:
>
> > On Jan 15, 6:50 pm, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> Okay, I see that I understood the word “better” in the usual context,
> > No you don't understand anything, grab a copy of SICP or Art of
> > Interpreter and write one for yourself. Naive implementation is only a
> > weekend of work.
>
> I don’t understand what’s the message.
The message is that you don't know anything about implementing any
lisp, not even a simple 2 day work interpreter, yet you're claiming
that JVM would be a best thing for implementing it.
Until you educate yourself and gain experience IN IMPLEMENTING NOT
USING you're only doing wishful thinking from a perspective of a
USER.
> When I want to implement a Scheme interpreter in Assembler or C it will
> be dramatically much easier than doing it in Java?
> Will the JVM simply refuse to run the interpreter?
> No, of course not.
Do you homework then will talk.
>
> >> I just see that Clojure works very good. Some people would even argue,
> >> that it works “better” than CL, whatever “better” means. And Clojure
> >> runs on a JVM and is without a doubt Lisp. ABCL also compiles to the
> >> code. So, it obviously is possible.
> > Fromhttp://common-lisp.net/project/armedbear/if situation improved
> > please correct me:
> > ABCL's CLOS is intolerably slow and does not handle on-the-fly
> > redefinition of classes correctly. There is no support for the long
> > form of DEFINE-METHOD-COMBINATION, and certain other required CLOS
> > features are also missing. Enough CLOS is there to run ASDF and CL-
> > PPCRE, if you're in no hurry. There's no MOP worth mentioning.
>
> (equal speed better) ==> NIL
> What exactly is it in the JVM that makes Lisps running under it
> worse?
> You simply expressed your opinion, which maybe was stated a bit unclear
> because you felt provoked by Jon.
That's not opinion, and even less mine. It's the FACT presented by the
IMPLEMENTOR of abcl. So he knows what's he talking about.
>
> See, if now the guys from Franz who programmed Allego would take ten
> years to implement CL on the JVM (they had more time to do it for
> Windows), do you then think it will perform about as good as abcl?
> A one-man project, done as a hobby?
> I see no reason why such a Lisp should not be as good as any other.
>
> If I assume that 3 people at Franz worked full time on Allegro, 150
> hours per month, then they put 450 man-hours of work into it, per month.
> That’s 5400 man-hours per year. In one decade this accumulates to 54.000
> man-hours. Sorry, but noone here in c.l.l can convince me that experts
> are not able to implement a decent CL within fiftythousand hours.
That's called boiling the ocean.
If there was 100 billions of US$ invested in lisp machines, and the
best engineers worked on them for 3 decades do you think that they
will be faster and cheaper then X86 boxes?
>
> Yes, the 380 hours that went into ABCL don’t sum up, but who in the world
> would find that strange?
>
> > Landrover engine is possible in Porche and Kia, but it's not a right
> > thing.
>
> So, which is the better car?
> This is obviously an opinion.
>
> > According tohttp://common-lisp.net/~dlw/LispSurvey.htmlonly one
> > implementation Armed Bear works on JVM. So the majority of common lisp
> > users think that JVM is bad idea, though there are some users who
> > prefer it. So if you're member of the JVM camp good for your, enjoy
> > Clojure or ABCL or whatever works for you. But the rest of us
> > disagree.
>
> Funny. Why is Jon not allowed to make conclusions from a simple google
> search, but others are? ;-)
Because Jon Harrop is a well known spammer. He's not here for
discussing lisp, he only wants to spam this newsgroup with his pond
staff.
> But anyway, thanks. Until now I am having fun.
> Btw, with both: CL *and* Clojure.
I didn't had a chance to try Clojure because of JVM problems mentioned
in other post, but from reading the documentation and watching Hickey
video it seems as a language with a lot of good ideas. I even
recognized some of the things I'm thinking of adding in edi, my hybrid
langauge, like multimethods.
cheers
bobi
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
Slobodan Blazeski schrieb:
> On Jan 17, 12:33 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Slobodan Blazeski schrieb:
>>
>>> On Jan 15, 6:50 pm, Andr� Thieme <address.good.until.
>>> ···········@justmail.de> wrote:
>>>> Okay, I see that I understood the word �better� in the usual context,
>>> No you don't understand anything, grab a copy of SICP or Art of
>>> Interpreter and write one for yourself. Naive implementation is only a
>>> weekend of work.
>> I don�t understand what�s the message.
> The message is that you don't know anything about implementing any
> lisp, not even a simple 2 day work interpreter, yet you're claiming
> that JVM would be a best thing for implementing it.
Please read more carefully. I don�t suggest that the JVM is the best
possible plattform for implementing a Lisp.
I only say that your claim is BS. Your use of the word �better� is
totally subjective. What I didn�t like is that you presented it as a fact.
It�s okay to have that opinion, but in that case one could state it like
that and maybe even give one or two reasons why one thinks so.
And only because you were able to follow instructions of a first semester
course on how to implement a trivial interpreter does not make you an
expert. Rich Hickey just implemented Clojure on the JVM. I never heard
him complaining that the JVM somehow makes it very hard to implement a
Lisp. It�s clear that there is no mysterious force that makes Lisp
somehow run worse as soon it realizes it runs in a JVM.
> Until you educate yourself and gain experience IN IMPLEMENTING NOT
> USING you're only doing wishful thinking from a perspective of a
> USER.
Again, bullshit.
Do you also have to consume cocain before you can understand its effects
very well?
You have no way to know how much I know about this matter. Please stop
accusing people and playing the expert, okay? Thanks :-)
>> What exactly is it in the JVM that makes Lisps running under it
>> worse?
>> You simply expressed your opinion, which maybe was stated a bit unclear
>> because you felt provoked by Jon.
> That's not opinion, and even less mine. It's the FACT presented by the
> IMPLEMENTOR of abcl. So he knows what's he talking about.
I did not meant the runtime performance of ABCL.
I was talking about your opinion that
�lisp is just working better under it's own VM than JVM�.
You did not give any definition of what �better� means for you hear.
It can�t be runtime behaviour, because in that case you would have said
so: �Lisps can�t run as fast in the JVM as in their own VM�.
That would be a verifiable claim.
But under �better� I understand, that it somehow does not work right.
Sometimes it produces wrong results, or stop to work, like an old motor
of a car.
The word �better� is a relative one and thus can never be verifiable.
Noone can prove that 4 is better than 19.
Kaz said, that implementors of Lisp have more freedom if they do it in
their own VM. Okay, that�s fine by me, I see this is a possibility.
Also this more granular control can mean that the memory consumption may
be bigger in some cases for the JVM. Oki, no problem.
But this still does not mean that the Lisp �works better�.
>> If I assume that 3 people at Franz worked full time on Allegro, 150
>> hours per month, then they put 450 man-hours of work into it, per month.
>> That�s 5400 man-hours per year. In one decade this accumulates to 54.000
>> man-hours. Sorry, but noone here in c.l.l can convince me that experts
>> are not able to implement a decent CL within fiftythousand hours.
>
> That's called boiling the ocean.
> If there was 100 billions of US$ invested in lisp machines, and the
> best engineers worked on them for 3 decades do you think that they
> will be faster and cheaper then X86 boxes?
Please, let�s connect to reality again yes?
What I gave was an example that could be not too far away of what Franz
actually did with Allegro.
Could they, or the Lispworks guys or the devs of cmucl/sbcl/clisp
implement such good Lisps within some few hundred hours?
Why do you have to compare ABCL that got some few hundred hours of work
and is still version 0.12 with Lisps that have tens if not hundreds of
thousands of man-hours work put into their development?
WTF!
Obviously for a fair comparison we need a CL implementation on the JVM
into which someone invested at least a mere 20.000 hours.
>> Funny. Why is Jon not allowed to make conclusions from a simple google
>> search, but others are? ;-)
> Because Jon Harrop is a well known spammer. He's not here for
> discussing lisp, he only wants to spam this newsgroup with his pond
> staff.
One �problem� with Jon is that he sometimes posts stuff that makes sense
and is debatable. He can be very serious and unprovocative, and he is
most likely as clever as the average guy here in c.l.l.
He just has this hobby of posting a lot of provocative stuff that is not
always connected with reality, but more wishful thinking.
But on the other hand he understands that Lisp offers more expresivity
than his programming languages, and this knowledge which he tries to
deny but which is still in his mind, keeps him coming back.
He knows that:
- Lisp is the more dynamic language (CL, Emacs Lisp, Clojure)
- Lisp has the more powerful static type system (Qi)
- Lisp produces faster code (Stalin compiler)
- Lisp can easily embedded (ECL)
- Lisp is cheaper: Clojure runs on the JVM and offers free tools such
as NetBeans and does not require customers to pay moon prices for
Windows(Server) licenses
- Lisp is where the innovation came from
- Lisp is more expressive than his languages. Lisp can do the same
stuff, but on top of it, it offers macros and goes beyond what he
can do
- Lisp runs on more plattforms than his programs can. Clojure can do
Windows but also the other OSes.
For these reasons he can�t stay away.
>> But anyway, thanks. Until now I am having fun.
>> Btw, with both: CL *and* Clojure.
> I didn't had a chance to try Clojure because of JVM problems mentioned
Well, it could be an indicator for hardware problems.
On one compi I also could not install the JRE/JDK. This machine had a
hardware error. Typical signs are that your computer crashes or suddenly
gets extremly slow/freezes. If that happens it is likely that there is a
hardware defect.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
······@corporate-world.lisp.de wrote:
> No? I thought that was pretty much clear in 1990 when they already
> were out of business
> (LMI, TI, Xerox) or scaled down (Symbolics).
Yes, I think that's true.
Since we're talking about Lisp here, I should point out
that one of the biggest problems Symbolics had was that
the "workstation" class of computer had appeared (e.g.
the early Suns), and after a while
the Lisp implementations that ran these were getting
better and better. While the Lisp implementations
and IDE's never (in my opinion) got quite as good
as the Symbolics system, they got a lot better.
By those years, the advantage of buying a workstation
machine that could run a wide range of software, that
was produced in much higher quantity and so was much
less expensive, etc, was very large.
See my blog entry:
http://danweinreb.org/blog/why-did-symbolics-fail
On 2009-01-12, =?windows-1252?Q?Andr=E9_Thieme?=
<······························@justmail.de> wrote:
> Maybe one of them decides to build a new IDE for Clojure. That could
> perhaps make sense. There is no such IDE now, and in the long run more
> and more Lispers will switch over to Clojure and other people are also
> moving into that direction.
I'm planning to start using it when the optional support for ANSI Lisp becomes
more complete.
André Thieme wrote:
> Jon Harrop schrieb:
>> That does not make it a good business model though. I am considering
>> something similar, building a HLVM on top of LLVM. I would also like to
>> earn money from the project but doing that by keeping it closed source
>> and trying to sell it seems like the worst option to me. Open sourcing
>> the platform, making it commerce friendly and selling documentation (e.g.
>> books, journals) and libraries built upon it seems like a much more
>> viable business model. The key is to get third parties building on your
>> platform.
>
> I can agree with you if you think about starting a project today.
Yes, exactly.
> ...
> The are masters of their niches.. no one will try to get into that
> market, so no new competition.
That is only true if you consider their market to be Lisp but I think there
is a strong argument that their market is tools for programmers and, in
that market, they are obviously facing huge competition. Essentially, I
doubt their users are that desperate to use Lisp.
> And they have each some hundred paying customers for years to come which
> will guarantee survival.
I don't think that guarantees survival at all. I don't know how many people
are locked in to Lispworks but I'd wager it is very few.
> A pretty stable niche I would say.
I cannot agree. The niche (Lisp) is too small for it to be stable.
> But I honestly don’t see a chance how they could grow.
They'll die if they don't diversify. Lisp will always survive in the
academic space but I think it is a sinking ship when it comes to industry.
I am not even willing to gamble on Haskell.
There are just too many alluring alternatives, e.g. languages that already
have SMP support and libraries that have been tested by millions of
programmers and hundreds of millions of end users.
> Maybe one of them decides to build a new IDE for Clojure. That could
> perhaps make sense. There is no such IDE now, and in the long run more
> and more Lispers will switch over to Clojure and other people are also
> moving into that direction.
> But currently there is no real IDE.
> Just editors with code colorization and indentation.
Good idea.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Jan 12, 11:24 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Jon Harrop schrieb:
>
> > ·····@franz.com wrote:
> >> There must be something commercial vendors supply that customers don't
> >> get with free lisps.
>
> > Support, a decent IDE, libraries that actually work, usable Windows support
> > and many other things I imagine.
>
> > That does not make it a good business model though. I am considering
> > something similar, building a HLVM on top of LLVM. I would also like to
> > earn money from the project but doing that by keeping it closed source and
> > trying to sell it seems like the worst option to me. Open sourcing the
> > platform, making it commerce friendly and selling documentation (e.g.
> > books, journals) and libraries built upon it seems like a much more viable
> > business model. The key is to get third parties building on your platform.
>
> I can agree with you if you think about starting a project today.
> But let’s remember that the Lisp vendors grew into their markets. They
> started to build their IDEs at very different times. It was when several
> people heared about this “Internet” thing. Some rich guys had mobile...
> well, one could call them phones, although cabin was what they looked like.
> At those times the markets were different, Lisp machines existed and not
> everyone knew they would be dead by the year 2000, and so on.
> So, from that perspective I can understand the business models of the
> vendors.
> The are masters of their niches.. no one will try to get into that
> market, so no new competition. And they have each some hundred paying
> customers for years to come which will guarantee survival.
> A pretty stable niche I would say.
> But I honestly don’t see a chance how they could grow.
By being brave. Scieneer made a bold step by releasing their lisp
without any limits for noncommercial users. Franz & LW has a cool
IDEs but you can't make exe's without buying their commercial
versions. By fallowing Scieneer steps they would probably lose some
money short term but gain much more on the long run. There are very
few companies ready to experiment and even less spend money on weird
technologies but if employees get lisp through the back door the
sales will fallow. I know of dozen of tools that started that way in
the companies I worked for, from source controls systems, UI widgets.
database drivers, they usually start from temporary fix made by one
coder but later when they grow into the system management has no
choice but to spend money or do a massive rewrite and management hates
massive rewrites.
bobi
On 13 Jan., 14:26, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jan 12, 11:24 pm, André Thieme <address.good.until.
>
> ···········@justmail.de> wrote:
> > Jon Harrop schrieb:
>
> > > ·····@franz.com wrote:
> > >> There must be something commercial vendors supply that customers don't
> > >> get with free lisps.
>
> > > Support, a decent IDE, libraries that actually work, usable Windows support
> > > and many other things I imagine.
>
> > > That does not make it a good business model though. I am considering
> > > something similar, building a HLVM on top of LLVM. I would also like to
> > > earn money from the project but doing that by keeping it closed source and
> > > trying to sell it seems like the worst option to me. Open sourcing the
> > > platform, making it commerce friendly and selling documentation (e.g.
> > > books, journals) and libraries built upon it seems like a much more viable
> > > business model. The key is to get third parties building on your platform.
>
> > I can agree with you if you think about starting a project today.
> > But let’s remember that the Lisp vendors grew into their markets. They
> > started to build their IDEs at very different times. It was when several
> > people heared about this “Internet” thing. Some rich guys had mobile...
> > well, one could call them phones, although cabin was what they looked like.
> > At those times the markets were different, Lisp machines existed and not
> > everyone knew they would be dead by the year 2000, and so on.
> > So, from that perspective I can understand the business models of the
> > vendors.
> > The are masters of their niches.. no one will try to get into that
> > market, so no new competition. And they have each some hundred paying
> > customers for years to come which will guarantee survival.
> > A pretty stable niche I would say.
> > But I honestly don’t see a chance how they could grow.
>
> By being brave. Scieneer made a bold step by releasing their lisp
> without any limits for noncommercial users.
Read this: http://www.scieneer.com/s/license.html?code=scl-1.3c
> Franz & LW has a cool
> IDEs but you can't make exe's without buying their commercial
> versions. By fallowing Scieneer steps they would probably lose some
> money short term but gain much more on the long run. There are very
> few companies ready to experiment and even less spend money on weird
> technologies but if employees get lisp through the back door the
> sales will fallow. I know of dozen of tools that started that way in
> the companies I worked for, from source controls systems, UI widgets.
> database drivers, they usually start from temporary fix made by one
> coder but later when they grow into the system management has no
> choice but to spend money or do a massive rewrite and management hates
> massive rewrites.
>
> bobi
On Jan 13, 3:04 pm, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:
> On 13 Jan., 14:26, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
>
>
> > On Jan 12, 11:24 pm, André Thieme <address.good.until.
>
> > ···········@justmail.de> wrote:
> > > Jon Harrop schrieb:
>
> > > > ·····@franz.com wrote:
> > > >> There must be something commercial vendors supply that customers don't
> > > >> get with free lisps.
>
> > > > Support, a decent IDE, libraries that actually work, usable Windows support
> > > > and many other things I imagine.
>
> > > > That does not make it a good business model though. I am considering
> > > > something similar, building a HLVM on top of LLVM. I would also like to
> > > > earn money from the project but doing that by keeping it closed source and
> > > > trying to sell it seems like the worst option to me. Open sourcing the
> > > > platform, making it commerce friendly and selling documentation (e.g.
> > > > books, journals) and libraries built upon it seems like a much more viable
> > > > business model. The key is to get third parties building on your platform.
>
> > > I can agree with you if you think about starting a project today.
> > > But let’s remember that the Lisp vendors grew into their markets. They
> > > started to build their IDEs at very different times. It was when several
> > > people heared about this “Internet” thing. Some rich guys had mobile...
> > > well, one could call them phones, although cabin was what they looked like.
> > > At those times the markets were different, Lisp machines existed and not
> > > everyone knew they would be dead by the year 2000, and so on.
> > > So, from that perspective I can understand the business models of the
> > > vendors.
> > > The are masters of their niches.. no one will try to get into that
> > > market, so no new competition. And they have each some hundred paying
> > > customers for years to come which will guarantee survival.
> > > A pretty stable niche I would say.
> > > But I honestly don’t see a chance how they could grow.
>
> > By being brave. Scieneer made a bold step by releasing their lisp
> > without any limits for noncommercial users.
>
> Read this: http://www.scieneer.com/s/license.html?code=scl-1.3c
Sorry my wording was wrong. Scieneer made a bold step by releasing
their lisp without any limits for noncommercial USE for free.
If I don't pay money to Scieeneer I can't use their lisp COMMERCIALLY
and that's fair with me. I could use how many demos, internal apps or
prototypes I want and not pay anything. But if some of them is market
ready i will pay the license. Or I could even cheat a little and
release my app, thus braking the license, if it makes me money I will
buy license(s) if it fails well I didn't make anything from it. It
lowers the barrier to entry. And I've seen it happening, and many
vendors are actually encouraging it.MS will let use their technology
unlicensed for a while, then when get hooked and have the money you'll
pay for windows server, for SQL server ,for Sharepoint. They want you
to succeed so you will pay for years to come. The problem with those
who want money in advance is that many people will not even try.
If for example reddit had all the goodies from Franz, when it was just
a petty start up with no money would they rewrite everything from
scratch after few years when they become profitable?
bobi
bobi
On 13 Jan., 15:18, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jan 13, 3:04 pm, ·······@corporate-world.lisp.de" <······@corporate-
>
>
>
> world.lisp.de> wrote:
> > On 13 Jan., 14:26, Slobodan Blazeski <·················@gmail.com>
> > wrote:
>
> > > On Jan 12, 11:24 pm, André Thieme <address.good.until.
>
> > > ···········@justmail.de> wrote:
> > > > Jon Harrop schrieb:
>
> > > > > ·····@franz.com wrote:
> > > > >> There must be something commercial vendors supply that customers don't
> > > > >> get with free lisps.
>
> > > > > Support, a decent IDE, libraries that actually work, usable Windows support
> > > > > and many other things I imagine.
>
> > > > > That does not make it a good business model though. I am considering
> > > > > something similar, building a HLVM on top of LLVM. I would also like to
> > > > > earn money from the project but doing that by keeping it closed source and
> > > > > trying to sell it seems like the worst option to me. Open sourcing the
> > > > > platform, making it commerce friendly and selling documentation (e.g.
> > > > > books, journals) and libraries built upon it seems like a much more viable
> > > > > business model. The key is to get third parties building on your platform.
>
> > > > I can agree with you if you think about starting a project today.
> > > > But let’s remember that the Lisp vendors grew into their markets. They
> > > > started to build their IDEs at very different times. It was when several
> > > > people heared about this “Internet” thing. Some rich guys had mobile...
> > > > well, one could call them phones, although cabin was what they looked like.
> > > > At those times the markets were different, Lisp machines existed and not
> > > > everyone knew they would be dead by the year 2000, and so on.
> > > > So, from that perspective I can understand the business models of the
> > > > vendors.
> > > > The are masters of their niches.. no one will try to get into that
> > > > market, so no new competition. And they have each some hundred paying
> > > > customers for years to come which will guarantee survival.
> > > > A pretty stable niche I would say.
> > > > But I honestly don’t see a chance how they could grow.
>
> > > By being brave. Scieneer made a bold step by releasing their lisp
> > > without any limits for noncommercial users.
>
> > Read this: http://www.scieneer.com/s/license.html?code=scl-1.3c
>
> Sorry my wording was wrong. Scieneer made a bold step by releasing
> their lisp without any limits for noncommercial USE for free.
There are limits. You haven't read the license then. For example
the license is only for one computer for one year.
> If I don't pay money to Scieeneer I can't use their lisp COMMERCIALLY
> and that's fair with me. I could use how many demos, internal apps or
> prototypes I want and not pay anything.
On one machine. See the license.
> But if some of them is market
> ready i will pay the license. Or I could even cheat a little and
> release my app, thus braking the license,
Nah! You also have to work around the keyfile mechanism. Have you
actually tried to use it?
Don't get me wrong, Scieneer CL runs fine and its a nice
way to find more about it, but it is wrong to say that
there are no limits.
> if it makes me money I will
> buy license(s) if it fails well I didn't make anything from it. It
> lowers the barrier to entry.
Sure, but there are other ways to start a business and if the
commercial Lisp
system gives an advantage in productivity one may want to buy one.
Even a pizza delivery business has to invest in transportation means
somehow. The other option is that the pizza man uses
his own car for delivery or, well, walks. Probably a fuel
efficient small car improves the business outlook.
> And I've seen it happening, and many
> vendors are actually encouraging it.MS will let use their technology
> unlicensed for a while, then when get hooked and have the money you'll
> pay for windows server, for SQL server ,for Sharepoint. They want you
> to succeed so you will pay for years to come. The problem with those
> who want money in advance is that many people will not even try.
It is hard to compare independent tool vendors with Microsoft.
Microsoft will
use whatever necessary tactics to get you hooked on their stuff.
> If for example reddit had all the goodies from Franz, when it was just
> a petty start up with no money would they rewrite everything from
> scratch after few years when they become profitable?
The Franz model is that development is relatively cost effective and
they
profit from the applications that their users deploy. You pay
some percent from what you make with your application (based on
users or similar). I'm not sure reddit had no money at startup time.
But in their domain there are lots of tools that are free and
that they were comfortable with.
The LispWorks model is that you pay for the purchase and maintenance
of the development tools (in a price range that is similar to
what other commercial tool vendors want). The deployment of
applications then is free on Linux, Windows, Mac, ... On
some UNIX machines they also want runtime licenses.
>
> bobi
>
> bobi
On Jan 13, 4:03 pm, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:
> On 13 Jan., 15:18, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
>
>
> > On Jan 13, 3:04 pm, ·······@corporate-world.lisp.de" <······@corporate-
>
> > world.lisp.de> wrote:
> > > On 13 Jan., 14:26, Slobodan Blazeski <·················@gmail.com>
> > > wrote:
>
> > > > On Jan 12, 11:24 pm, André Thieme <address.good.until.
>
> > > > ···········@justmail.de> wrote:
> > > > > Jon Harrop schrieb:
>
> > > > > > ·····@franz.com wrote:
> > > > > >> There must be something commercial vendors supply that customers don't
> > > > > >> get with free lisps.
>
> > > > > > Support, a decent IDE, libraries that actually work, usable Windows support
> > > > > > and many other things I imagine.
>
> > > > > > That does not make it a good business model though. I am considering
> > > > > > something similar, building a HLVM on top of LLVM. I would also like to
> > > > > > earn money from the project but doing that by keeping it closed source and
> > > > > > trying to sell it seems like the worst option to me. Open sourcing the
> > > > > > platform, making it commerce friendly and selling documentation (e.g.
> > > > > > books, journals) and libraries built upon it seems like a much more viable
> > > > > > business model. The key is to get third parties building on your platform.
>
> > > > > I can agree with you if you think about starting a project today.
> > > > > But let’s remember that the Lisp vendors grew into their markets. They
> > > > > started to build their IDEs at very different times. It was when several
> > > > > people heared about this “Internet” thing. Some rich guys had mobile...
> > > > > well, one could call them phones, although cabin was what they looked like.
> > > > > At those times the markets were different, Lisp machines existed and not
> > > > > everyone knew they would be dead by the year 2000, and so on.
> > > > > So, from that perspective I can understand the business models of the
> > > > > vendors.
> > > > > The are masters of their niches.. no one will try to get into that
> > > > > market, so no new competition. And they have each some hundred paying
> > > > > customers for years to come which will guarantee survival.
> > > > > A pretty stable niche I would say.
> > > > > But I honestly don’t see a chance how they could grow.
>
> > > > By being brave. Scieneer made a bold step by releasing their lisp
> > > > without any limits for noncommercial users.
>
> > > Read this: http://www.scieneer.com/s/license.html?code=scl-1.3c
>
> > Sorry my wording was wrong. Scieneer made a bold step by releasing
> > their lisp without any limits for noncommercial USE for free.
>
> There are limits. You haven't read the license then. For example
> the license is only for one computer for one year.
>
> > If I don't pay money to Scieeneer I can't use their lisp COMMERCIALLY
> > and that's fair with me. I could use how many demos, internal apps or
> > prototypes I want and not pay anything.
>
> On one machine. See the license.
>
> > But if some of them is market
> > ready i will pay the license. Or I could even cheat a little and
> > release my app, thus braking the license,
>
> Nah! You also have to work around the keyfile mechanism. Have you
> actually tried to use it?
No I don't currently own a linux box. Beside I want descent edi.
>
> Don't get me wrong, Scieneer CL runs fine and its a nice
> way to find more about it, but it is wrong to say that
> there are no limits.
>
> > if it makes me money I will
> > buy license(s) if it fails well I didn't make anything from it. It
> > lowers the barrier to entry.
>
> Sure, but there are other ways to start a business and if the
> commercial Lisp
> system gives an advantage in productivity one may want to buy one.
> Even a pizza delivery business has to invest in transportation means
> somehow. The other option is that the pizza man uses
> his own car for delivery or, well, walks. Probably a fuel
> efficient small car improves the business outlook.
The difference is that this is software, delivery vans are material
things. Making extra copy of a prograns cost almost nothing.
>
> > And I've seen it happening, and many
> > vendors are actually encouraging it.MS will let use their technology
> > unlicensed for a while, then when get hooked and have the money you'll
> > pay for windows server, for SQL server ,for Sharepoint. They want you
> > to succeed so you will pay for years to come. The problem with those
> > who want money in advance is that many people will not even try.
>
> It is hard to compare independent tool vendors with Microsoft.
> Microsoft will
> use whatever necessary tactics to get you hooked on their stuff.
It's not just Microsoft. Friends of mine got a Photoshop for free
through some learning course for noncommercial use. After a several
years when he become a good graphic designer and opened his own studio
and even hired some folks to help him. What do you think he's using
now GIMP? Oh no he bought licenses for him and his employeess
And it's not just the big boys. One of the former companies I worked
for used the noncommercial only database driver because programmers
hated the preinstalled one, after few months the manager had no choice
but to buy license. The other got UI widgets with something like
unlimited time trial. When application was built with those widgets
and it got online and they went to purchase licenses, you know what
was the answer? Guys wait for few months to see if your app is making
you money then you'll pay us if our widgets helped you. Now they made
money licenses, and got their reference clients amd applications. Also
there is a network effect of programmers leaving for other companies
and spreading the word, because they're famigliar with those widgets.
Another colleague of mine spread those widgets through 4 companies he
worked for in the previous years and at least 2 dozen of projects.
Lisp vendors aren't competing with themselves or OSS implementations
they're competing with other languages. And unless the word is spread,
lisp will stay IRRELEVANT.
Now it seems that lisp vendors are eating the corn seed.
>
> > If for example reddit had all the goodies from Franz, when it was just
> > a petty start up with no money would they rewrite everything from
> > scratch after few years when they become profitable?
>
> The Franz model is that development is relatively cost effective and
> they
> profit from the applications that their users deploy. You pay
> some percent from what you make with your application (based on
> users or similar). I'm not sure reddit had no money at startup time.
> But in their domain there are lots of tools that are free and
> that they were comfortable with.
>
> The LispWorks model is that you pay for the purchase and maintenance
> of the development tools (in a price range that is similar to
> what other commercial tool vendors want). The deployment of
> applications then is free on Linux, Windows, Mac, ... On
> some UNIX machines they also want runtime licenses.
Last time I checked Ycombinator paid only several thousands per
developer. So after they payed for the rent, hosting and living
expenses they don't have money for expensive tools. On the other hand
if Franz gave them the thumb up to use their product just for the
royalties and let them pay the license when they grow from negligeble
revenues to something that could afford the tools. Do you think they
would switch if they found Franz goodies useful. There is a VC just
around the corner with bags of money and we are going to rewrite our
app from scratch in different language just because we don't want to
spend few grands.
On 13 Jan., 16:43, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jan 13, 4:03 pm, ·······@corporate-world.lisp.de" <······@corporate-
> > Sure, but there are other ways to start a business and if the
> > commercial Lisp
> > system gives an advantage in productivity one may want to buy one.
> > Even a pizza delivery business has to invest in transportation means
> > somehow. The other option is that the pizza man uses
> > his own car for delivery or, well, walks. Probably a fuel
> > efficient small car improves the business outlook.
>
> The difference is that this is software, delivery vans are material
> things. Making extra copy of a prograns cost almost nothing.
That was not the questions. There are no-cost tools and
tools that cost money. If the more expensive tool
enables or improves the business plan, then it is an option.
>
> > > And I've seen it happening, and many
> > > vendors are actually encouraging it.MS will let use their technology
> > > unlicensed for a while, then when get hooked and have the money you'll
> > > pay for windows server, for SQL server ,for Sharepoint. They want you
> > > to succeed so you will pay for years to come. The problem with those
> > > who want money in advance is that many people will not even try.
>
> > It is hard to compare independent tool vendors with Microsoft.
> > Microsoft will
> > use whatever necessary tactics to get you hooked on their stuff.
>
> It's not just Microsoft. Friends of mine got a Photoshop for free
> through some learning course for noncommercial use. After a several
> years when he become a good graphic designer and opened his own studio
> and even hired some folks to help him. What do you think he's using
> now GIMP? Oh no he bought licenses for him and his employeess
> And it's not just the big boys. One of the former companies I worked
> for used the noncommercial only database driver because programmers
> hated the preinstalled one, after few months the manager had no choice
> but to buy license. The other got UI widgets with something like
> unlimited time trial. When application was built with those widgets
> and it got online and they went to purchase licenses, you know what
> was the answer? Guys wait for few months to see if your app is making
> you money then you'll pay us if our widgets helped you. Now they made
> money licenses, and got their reference clients amd applications. Also
> there is a network effect of programmers leaving for other companies
> and spreading the word, because they're famigliar with those widgets.
> Another colleague of mine spread those widgets through 4 companies he
> worked for in the previous years and at least 2 dozen of projects.
> Lisp vendors aren't competing with themselves or OSS implementations
> they're competing with other languages. And unless the word is spread,
> lisp will stay IRRELEVANT.
As I said, that is similar to the Franz model. Only that there
is usually a higher entry barrier. You really start paying for
the deployed apps.
...
> Last time I checked Ycombinator paid only several thousands per
> developer. So after they payed for the rent, hosting and living
> expenses they don't have money for expensive tools.
Nah, if you have a cool application idea and need a commercial
Lisp, you should talk to your VC about that. If the VC does
not have the money for the tools, then you probably should try to
find another VC.
> On the other hand
> if Franz gave them the thumb up to use their product just for the
> royalties and let them pay the license when they grow from negligeble
> revenues to something that could afford the tools. Do you think they
> would switch if they found Franz goodies useful. There is a VC just
> around the corner with bags of money and we are going to rewrite our
> app from scratch in different language just because we don't want to
> spend few grands.
In that domain (reddit) it does not make much sense. That tool area
is so crowded that it is even hard to choose from the no-cost ones.
For a relatively simple webapp you won't find nobody paying
money for tools. You won't find even less people will to
pay for users. I don't see Lisp vendors competing with no-cost
offerings and getting anywhere. As a developer I don't get any
advantage from using Lisp (unless I'm in a Lisp shop with lots
of spare Lisp development time) for simple webapps.
Commercial Lisp is competitive in
different areas. For example when the developer who understands
the domain has to be kept happy or when you want to do something
non-standard that needs brains and high-productivity. Having
a Lisp vendor giving away development tools for free, when
actually the development tool has differentiating features
just makes little sense.
Slobodan Blazeski wrote:
> It's not just Microsoft. Friends of mine got a Photoshop for free
> through some learning course for noncommercial use. After a several
> years when he become a good graphic designer and opened his own studio
> and even hired some folks to help him. What do you think he's using
> now GIMP? Oh no he bought licenses for him and his employeess
> And it's not just the big boys. One of the former companies I worked
> for used the noncommercial only database driver because programmers
> hated the preinstalled one, after few months the manager had no choice
> but to buy license. The other got UI widgets with something like
> unlimited time trial. When application was built with those widgets
> and it got online and they went to purchase licenses, you know what
> was the answer? Guys wait for few months to see if your app is making
> you money then you'll pay us if our widgets helped you. Now they made
> money licenses, and got their reference clients amd applications. Also
> there is a network effect of programmers leaving for other companies
> and spreading the word, because they're famigliar with those widgets.
> Another colleague of mine spread those widgets through 4 companies he
> worked for in the previous years and at least 2 dozen of projects.
> Lisp vendors aren't competing with themselves or OSS implementations
> they're competing with other languages. And unless the word is spread,
> lisp will stay IRRELEVANT.
> Now it seems that lisp vendors are eating the corn seed.--
I don't get the Lisp vendors in this respect. I wrote my Magister thesis
in Common Lisp, and I got weird stares for my choice of language from my
Professor already. I wanted to make the case for CL at the institute
where I studied. When I asked Xanalys whether I could have a full
version of their implementation for writing my program with it, they
brushed me off suggesting to use the personal edition or wossname, which
was of no use because of the limited heap space -- my app was built
around large hash tables.
In the end I used cmucl and stuck a TBNL-based web interface on it
instead of a nice GUI. It was enough for my purposes, but didn't look as
impressive as it could have, and installation of the system is daunting
to say the least*, so after my thesis was done, the project was dead for
the institute, no matter how good it performed.
There was nothing to lose for Xanalys, as I could not have afforded
the full version of Lispworks as a student in any case, but a lot to
gain. That was pretty disillusioning to me. Microsoft knows that you
need to get them as students.
Wolfgang
* CMUCL, Emacs, SLIME, screen, asdf, cl-ppcre, split-sequence, TBNL,
cl-who, Apache, mod_lisp, if I remember correctly. Not for the faint
of the heart.
--
Wolfgang Mederle
<URL:http://mederle.de/>
On 13 Jan., 18:00, "Wolfgang Mederle" <·······················@gmx.de>
wrote:
> Slobodan Blazeski wrote:
> > It's not just Microsoft. Friends of mine got a Photoshop for free
> > through some learning course for noncommercial use. After a several
> > years when he become a good graphic designer and opened his own studio
> > and even hired some folks to help him. What do you think he's using
> > now GIMP? Oh no he bought licenses for him and his employeess
> > And it's not just the big boys. One of the former companies I worked
> > for used the noncommercial only database driver because programmers
> > hated the preinstalled one, after few months the manager had no choice
> > but to buy license. The other got UI widgets with something like
> > unlimited time trial. When application was built with those widgets
> > and it got online and they went to purchase licenses, you know what
> > was the answer? Guys wait for few months to see if your app is making
> > you money then you'll pay us if our widgets helped you. Now they made
> > money licenses, and got their reference clients amd applications. Also
> > there is a network effect of programmers leaving for other companies
> > and spreading the word, because they're famigliar with those widgets.
> > Another colleague of mine spread those widgets through 4 companies he
> > worked for in the previous years and at least 2 dozen of projects.
> > Lisp vendors aren't competing with themselves or OSS implementations
> > they're competing with other languages. And unless the word is spread,
> > lisp will stay IRRELEVANT.
> > Now it seems that lisp vendors are eating the corn seed.--
>
> I don't get the Lisp vendors in this respect. I wrote my Magister thesis
> in Common Lisp, and I got weird stares for my choice of language from my
> Professor already. I wanted to make the case for CL at the institute
> where I studied. When I asked Xanalys whether I could have a full
> version of their implementation for writing my program with it, they
> brushed me off suggesting to use the personal edition or wossname, which
> was of no use because of the limited heap space -- my app was built
> around large hash tables.
>
> In the end I used cmucl and stuck a TBNL-based web interface on it
> instead of a nice GUI. It was enough for my purposes, but didn't look as
> impressive as it could have, and installation of the system is daunting
> to say the least*, so after my thesis was done, the project was dead for
> the institute, no matter how good it performed.
>
> There was nothing to lose for Xanalys, as I could not have afforded
> the full version of Lispworks as a student in any case, but a lot to
> gain. That was pretty disillusioning to me. Microsoft knows that you
> need to get them as students.
>
> Wolfgang
>
> * CMUCL, Emacs, SLIME, screen, asdf, cl-ppcre, split-sequence, TBNL,
> cl-who, Apache, mod_lisp, if I remember correctly. Not for the faint
> of the heart.
>
> --
> Wolfgang Mederle
> <URL:http://mederle.de/>
How times are changing. When I was at the University of Hamburg (long
ago),
the University had a site license for Allegro CL, several MCL
licenses, Lucid CL,
two Symbolics, got rid of a bunch of Xerox Lisp Machines, had
Goldworks, G2, Procyon CL, ... One of the people of the AI lab wrote
code in
the domain of medical image processing. He got a LispWorks
copy - even though there was a site license for Allegro CL.
Well in your case it is kind of obvious, that it would be hard to sell
any license. The professor doesn't care, doesn't have the money
for a single copy and your result was easily achieved with a free
tool.
LispWorks is not that cheap (if you include maintenance). The 64bit
Enterprise Edition including 1 year maintenance is 2760 Euros.
They don't give it away for free and later have a high probablilty
that they don't
sell any license. They are not so 'sales guy' oriented. Either you
want a copy or not. ;-) They can provide you with time limited
evaluation licenses, though. Actually I think especially
the 64bit version is really good.
······@corporate-world.lisp.de wrote:
> How times are changing. When I was at the University of Hamburg (long
> ago), the University had a site license for Allegro CL, several MCL
> licenses, Lucid CL, two Symbolics, got rid of a bunch of Xerox Lisp
> Machines, had Goldworks, G2, Procyon CL, ... One of the people of the
> AI lab wrote code in the domain of medical image processing. He got a
> LispWorks copy - even though there was a site license for Allegro CL.
And now it's probably the same as in Munich. I studied Computational
Linguistics and worked as a sysadmin for the institute. On the attic,
there were lectures about Common Lisp (replaced first by Prolog, then by
Perl/C++/Java), and I snatched a full version of Golden Common Lisp for
IBM PC/XT on 5" floppy disk with printed manual.
--
Wolfgang Mederle
<URL:http://mederle.de/>
On Jan 14, 2:03 am, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:
> On 13 Jan., 15:18, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
> > On Jan 13, 3:04 pm, ·······@corporate-world.lisp.de" <······@corporate-
>
> > world.lisp.de> wrote:
> > > On 13 Jan., 14:26, Slobodan Blazeski <·················@gmail.com>
> > > wrote:
>
> > > > On Jan 12, 11:24 pm, André Thieme <address.good.until.
>
> > > > ···········@justmail.de> wrote:
> > > > > Jon Harrop schrieb:
>
> > > > > > ·····@franz.com wrote:
> > > > > >> There must be something commercial vendors supply that customers don't
> > > > > >> get with free lisps.
>
> > > > > > Support, a decent IDE, libraries that actually work, usable Windows support
> > > > > > and many other things I imagine.
>
> > > > > > That does not make it a good business model though. I am considering
> > > > > > something similar, building a HLVM on top of LLVM. I would also like to
> > > > > > earn money from the project but doing that by keeping it closed source and
> > > > > > trying to sell it seems like the worst option to me. Open sourcing the
> > > > > > platform, making it commerce friendly and selling documentation (e.g.
> > > > > > books, journals) and libraries built upon it seems like a much more viable
> > > > > > business model. The key is to get third parties building on your platform.
>
> > > > > I can agree with you if you think about starting a project today.
> > > > > But let’s remember that the Lisp vendors grew into their markets. They
> > > > > started to build their IDEs at very different times. It was when several
> > > > > people heared about this “Internet” thing. Some rich guys had mobile...
> > > > > well, one could call them phones, although cabin was what they looked like.
> > > > > At those times the markets were different, Lisp machines existed and not
> > > > > everyone knew they would be dead by the year 2000, and so on.
> > > > > So, from that perspective I can understand the business models of the
> > > > > vendors.
> > > > > The are masters of their niches.. no one will try to get into that
> > > > > market, so no new competition. And they have each some hundred paying
> > > > > customers for years to come which will guarantee survival.
> > > > > A pretty stable niche I would say.
> > > > > But I honestly don’t see a chance how they could grow.
>
> > > > By being brave.Scieneermade a bold step by releasing their lisp
> > > > without any limits for noncommercial users.
>
> > > Read this: http://www.scieneer.com/s/license.html?code=scl-1.3c
>
> > Sorry my wording was wrong. Scieneermade a bold step by releasing
> > their lisp without any limits for noncommercial USE for free.
>
> There are limits. You haven't read the license then. For example
> the license is only for one computer for one year.
While this is partly accurate, it is also misleading because Scieneer
will issue multiple licenses to use the Scieneer CL free for non-
commercial or academic use, and many such licenses have been issued,
and Rainer you are licensed to use each of your free licenses on
separate systems! Further you are welcome to reapply for new
licenses after one year. Scieneer does not unreasonable refuse
requests.
Please consider that I have a strong record of contributing to free
Common Lisp implementations and worked on the CMU CL for many years
contributing the work into the public domain. If there were a way to
make the Scieneer CL available for free while funding development then
it would be done. I continue to try hard to encourage Common Lisp and
find funding for development.
Regards
Douglas Crosher
On 26 Jan., 00:52, ····@scieneer.com wrote:
> On Jan 14, 2:03 am, ·······@corporate-world.lisp.de" <······@corporate-
>
>
>
> world.lisp.de> wrote:
> > On 13 Jan., 15:18, Slobodan Blazeski <·················@gmail.com>
> > wrote:
>
> > > On Jan 13, 3:04 pm, ·······@corporate-world.lisp.de" <······@corporate-
>
> > > world.lisp.de> wrote:
> > > > On 13 Jan., 14:26, Slobodan Blazeski <·················@gmail.com>
> > > > wrote:
>
> > > > > On Jan 12, 11:24 pm, André Thieme <address.good.until.
>
> > > > > ···········@justmail.de> wrote:
> > > > > > Jon Harrop schrieb:
>
> > > > > > > ·····@franz.com wrote:
> > > > > > >> There must be something commercial vendors supply that customers don't
> > > > > > >> get with free lisps.
>
> > > > > > > Support, a decent IDE, libraries that actually work, usable Windows support
> > > > > > > and many other things I imagine.
>
> > > > > > > That does not make it a good business model though. I am considering
> > > > > > > something similar, building a HLVM on top of LLVM. I would also like to
> > > > > > > earn money from the project but doing that by keeping it closed source and
> > > > > > > trying to sell it seems like the worst option to me. Open sourcing the
> > > > > > > platform, making it commerce friendly and selling documentation (e.g.
> > > > > > > books, journals) and libraries built upon it seems like a much more viable
> > > > > > > business model. The key is to get third parties building on your platform.
>
> > > > > > I can agree with you if you think about starting a project today.
> > > > > > But let’s remember that the Lisp vendors grew into their markets. They
> > > > > > started to build their IDEs at very different times. It was when several
> > > > > > people heared about this “Internet” thing. Some rich guys had mobile...
> > > > > > well, one could call them phones, although cabin was what they looked like.
> > > > > > At those times the markets were different, Lisp machines existed and not
> > > > > > everyone knew they would be dead by the year 2000, and so on.
> > > > > > So, from that perspective I can understand the business models of the
> > > > > > vendors.
> > > > > > The are masters of their niches.. no one will try to get into that
> > > > > > market, so no new competition. And they have each some hundred paying
> > > > > > customers for years to come which will guarantee survival.
> > > > > > A pretty stable niche I would say.
> > > > > > But I honestly don’t see a chance how they could grow.
>
> > > > > By being brave.Scieneermade a bold step by releasing their lisp
> > > > > without any limits for noncommercial users.
>
> > > > Read this: http://www.scieneer.com/s/license.html?code=scl-1.3c
>
> > > Sorry my wording was wrong. Scieneermade a bold step by releasing
> > > their lisp without any limits for noncommercial USE for free.
>
> > There are limits. You haven't read the license then. For example
> > the license is only for one computer for one year.
>
> While this is partly accurate, it is also misleading because Scieneer
> will issue multiple licenses to use the Scieneer CL free for non-
> commercial or academic use, and many such licenses have been issued,
> and Rainer you are licensed to use each of your free licenses on
> separate systems! Further you are welcome to reapply for new
> licenses after one year. Scieneer does not unreasonable refuse
> requests.
>
> Please consider that I have a strong record of contributing to free
> Common Lisp implementations and worked on the CMU CL for many years
> contributing the work into the public domain. If there were a way to
> make the Scieneer CL available for free while funding development then
> it would be done. I continue to try hard to encourage Common Lisp and
> find funding for development.
>
> Regards
> Douglas Crosher
Sounds good. Thanks for the clarification.
Regards,
Rainer Joswig
On Sun, 11 Jan 2009 13:41:06 +0000
Jon Harrop <···@ffconsultancy.com> wrote:
> No way.
>
> Market share by programming language:
>
> USA (from dice.com):
> Lisp: 0.06%
> C#: 15%
>
> UK (from itjobswatch.co.uk):
> Lisp: 0.017%
> C#: 30%
>
> France (from monster.fr):
> Lisp: 1 job
> C#: 1,219 jobs
Keep in mind that job postings are not the same as programmers. Some
company that already has one developer does not need to publish a
job posting (making the number of job postings zero). You'd argue that
there are zero programmers where in fact there are more.
regards,
Marek
Marek Kubica wrote:
> Keep in mind that job postings are not the same as programmers. Some
> company that already has one developer does not need to publish a
> job posting (making the number of job postings zero). You'd argue that
> there are zero programmers where in fact there are more.
I would expect the ratio of filled jobs to advertised jobs to be roughly
constant between general-purpose languages across the entire industry
though. Lisp having 1,000x fewer job postings but only 100x fewer
programmers just does not make sense to me, particularly when there is no
evidence of such an anomaly in other related languages. Indeed, the only
anomaly I would expect to see is a much larger proportion of
non-professional Lisp developers because it is an academic language.
Roughly speaking, I would say that languages like OCaml/Haskell/Lisp have
tens of thousands of programmers, languages like Python/Ruby have hundreds
of thousands and Java/C# have millions.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-01-11, Jon Harrop <···@ffconsultancy.com> wrote:
> Market share by programming language:
>
> USA (from dice.com):
> Lisp: 0.06%
> C#: 15%
Oh ...
But what he can infer,
From just one Google search
Based on number of hits!
"John Thingstad" <·······@online.no> writes:
> P� Sun, 11 Jan 2009 06:21:27 +0100, skrev Jon Harrop
> <···@ffconsultancy.com>:
>
>> Mathematica had a million users by 1999 and now has several million. Even
>> free Lisp implementations have only a few thousand users. I very
>> much doubt
>> all commercial Lisps combined have 10,000 users.
>
> There are about 30 000 professional Lisp programmes world wide and
> about 100 000 that use Lisp.
> This is far less than the 4 million copies sold of Mathematica but
> still an order of magitude more than you seem to suggest.
Ok, there may be more Mathematica users in non CS/IT circles than
lisper.
--
__Pascal Bourguignon__
On 2009-01-09, Jon Harrop <···@ffconsultancy.com> wrote:
> Dimiter "malkia" Stanev wrote:
>> To all of the previous - Somehow. I don't know what's your problem? You
>> get the bindings, run the solution, if you run into problem - you look
>> for a workaround (in any language, API, etc.).
>
> You ditch Lisp in favor of a language with mature libraries, as everyone
> else has done.
If I had to guess what that language would be, I would have to go with C++.
:)
>>> You can get a much longer list of subtleties by looking at the bugs filed
>>> against various GL bindings, such as PyGL:
>>>
>>> http://sourceforge.net/tracker/?atid=105988&group_id=5988&func=browse
>>
>> No need for that - you might run into some of them, you might not run
>> into them at all...
>
> You almost certainly will if you try to use immature bindings like most Lisp
> libraries and, when you have problems, you will be facing an unfeasible
> amount of work. That problem is widespread among esoteric languages.
> Anyone needing to get a competitive amount of work done cannot afford to
> follow your advice, i.e. your advice is useless in the real world.
But that obviously isn't you. Or why would you be recounting your experiences
about developing your own immature bindings in an esoteric language?
Don't assume that Lisp is like the shit you are using.
The FFI technology in the best Lisp implementations is very solid. Most of the
issues are solved out-of-the-box, so you just have to write the definitions to
connect to your particular API. You still have to confront some of the same
issues, but the FFI has solutions for them. The bindings you write inherit
maturity from the underlying FFI module.
Looking at the Objective Caml documentation about interfacing with C,
no wonder you think this stuff is a big deal! You have to do lame stuff, like
write wrapper functions in C, and call those, rather than call the real
functions.
Lisp FFI's work without any stub code. You simply declare the interface, and it
connects directly to the function you want to be calling. The FFI knows how to
generate a C function call and do any necessary conversions, move data between
GC safe and unsafe buffers and stuff like that.
The Posix function glob makes a nice example, since it returns a variable
amount of data, and it has a callback function interface for reporting errors.
It also has a memory management protocol that requires the caller to invoke
a special destructor function.
Here is how to bind to the glibc version from CLISP. You can do this
all at the REPL. No need to write any C code or compile anything:
(use-package :ffi)
;;; Define glob_t structure
(def-c-struct glob-t
(gl-pathc uint32)
(gl-pathv (c-array-ptr c-string))
(gl-offs uint32)
;; We don't know how big this struct really is,
;; so let's allocate extra space for it!
(padding (c-array int 16)))
;;; Define binding for glob
;;; The :NONE for the glob argument means we handle our own memory
;;; management. We need to do that because after glob is called,
;;; it is necessary to call globfree to release resources that have
;;; been charged to the structure. So automatic malloc/free
;;; handling in the FFI is no good.
(def-call-out glob-ll
(:language :stdc)
(:library "libc.so.6")
(:name "glob")
(:arguments (pattern c-string) (flags int)
(errorfunc (c-function (:language :stdc)
(:arguments (epath c-string)
(errno int))
(:return-type int)))
(glob c-pointer :in :none))
(:return-type int))
;;; Define binding for globfree
(def-call-out glob-free-ll
(:language :stdc)
(:library "libc.so.6")
(:name "globfree")
(:arguments (glob c-pointer :in :none)))
;;; Now we just need a simple wrapper for glob which handles the memory
;;; management for glob-t, similar to what happens in a C program.
;;; We allocate the struct, use it, then have to call globfree on it,
;;; and finally release it:
(defun glob (pattern &optional error-lambda)
(let* ((glob-foreign-struct (allocate-shallow 'glob-t))
(result (glob-ll pattern 0 error-lambda glob-foreign-struct)))
(unwind-protect
(glob-t-gl-pathv (foreign-value glob-foreign-struct))
(glob-free-ll glob-foreign-struct)
(foreign-free glob-foreign-struct))))
Now it's ready to go.
[1]> (glob "/var/run/*" (lambda (path errno) (format t "error ~a accessing ~a~%")))
#("/var/run/acpid.socket" "/var/run/atd.pid" "/var/run/console"
"/var/run/crond.pid" "/var/run/cups-config-daemon.pid" "/var/run/cupsd.pid"
"/var/run/dbus" "/var/run/dhclient-eth0.pid" "/var/run/gdm.pid"
"/var/run/haldaemon.pid" "/var/run/klogd.pid" "/var/run/mdadm"
"/var/run/mdmpd" "/var/run/messagebus.pid" "/var/run/netreport"
"/var/run/nscd" "/var/run/ppp" "/var/run/rpc.statd.pid" "/var/run/saslauthd"
"/var/run/sshd.pid" "/var/run/sudo" "/var/run/syslogd.pid" "/var/run/usb"
"/var/run/utmp" "/var/run/vmware-guestd.pid" "/var/run/winbindd"
"/var/run/xfs.pid" "/var/run/xinetd.pid" "/var/run/ypbind.pid")
Oh look, callbacks work:
[2]> (glob "/root/*" (lambda (path errno) (format t "error ~a accessing ~a~%" errno path) 0))
error 13 accessing /root
NIL
See, glibc called right into our lambda.
There is just the small problem that the closure is leaked. The C library
is assumed to have permanently registered the function somewhere.
One easy way to deal with this is to store the closure in a special
variable binding, and pass a wrapper function to the library instead of
the closure. The wrapper pulls the closure out of the special and calls it.
> Lisp FFI's work without any stub code. You simply declare the interface, and it
> connects directly to the function you want to be calling. The FFI knows how to
> generate a C function call and do any necessary conversions, move data between
> GC safe and unsafe buffers and stuff like that.
That is the best point about Lisp's FFI. Really you don't need any stub
code for 99% of the stuff. Only in cases where your lisp implementation
does not support something arcane, or the run-time library is not
compatible.
Really with any other language you have to do it with bindings,
hopefully there's SWIG.
On Fri, 09 Jan 2009 03:35:59 -0800
"Dimiter \"malkia\" Stanev" <······@mac.com> wrote:
> Really with any other language you have to do it with bindings,
> hopefully there's SWIG.
No, that's not really true. I agree that writing stub code sucks but CL
is not the only language with decent FFI. Making Lisp popular is one
thing, but it should be based on facts.
regards,
Marek
Dimiter "malkia" Stanev wrote:
>> Lisp FFI's work without any stub code. You simply declare the interface,
>> and it connects directly to the function you want to be calling. The FFI
>> knows how to generate a C function call and do any necessary conversions,
>> move data between GC safe and unsafe buffers and stuff like that.
>
> That is the best point about Lisp's FFI. Really you don't need any stub
> code for 99% of the stuff. Only in cases where your lisp implementation
> does not support something arcane, or the run-time library is not
> compatible.
>
> Really with any other language you have to do it with bindings,
> hopefully there's SWIG.
Or the JVM, or CLR, or LLVM or...
In reality, Lisp has no benefits over other languages here either. What it
does have is a grave lack of mature bindings because there are so few Lisp
users, i.e. a vicious circle.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-01-10 04:15:37 -0800, the f(scking)lying frog said:
> What it
> does have is a grave lack of mature bindings because there are so few Lisp
> users
Which is why you spend your time posting here rather than that bustling
electronic commons, comp.lang.functional, which has so many users - oh,
wait...
--
Raffael Cavallaro, Ph.D.
Raffael Cavallaro wrote:
> On 2009-01-10 04:15:37 -0800, the f(scking)lying frog said:
>> What it does have is a grave lack of mature bindings because there are so
>> few Lisp users
>
> Which is why you spend your time posting here rather than that bustling
> electronic commons, comp.lang.functional, which has so many users - oh,
> wait...
comp.lang.functional is as relevant to Lisp as it is to the next FPL.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On 2009-01-11, Mariano Montone <··············@gmail.com> wrote:
> Yes, you are right. Common Lisp completly sucks and Mathematica, F#,
> and OCaml are the best tools!!
Oh ...
And he never gives up,
He doesn't know when to quit,
He's the consummate twit!
http://groups.google.com/group/comp.lang.lisp/msg/01f398e72359228a
Message-ID: <··················@gmail.com>
On 2009-01-11, Jon Harrop <···@ffconsultancy.com> wrote:
> Raffael Cavallaro wrote:
>> On 2009-01-10 04:15:37 -0800, the f(scking)lying frog said:
>>> What it does have is a grave lack of mature bindings because there are so
>>> few Lisp users
>>
>> Which is why you spend your time posting here rather than that bustling
>> electronic commons, comp.lang.functional, which has so many users - oh,
>> wait...
>
> comp.lang.functional is as relevant to Lisp as it is to the next FPL.
comp.lang.functional is at least as relevant to Lisp as anything you've
ever written in comp.lang.lisp.
Kaz Kylheku wrote:
> On 2009-01-09, Jon Harrop <···@ffconsultancy.com> wrote:
>> You almost certainly will if you try to use immature bindings like most
>> Lisp libraries and, when you have problems, you will be facing an
>> unfeasible amount of work. That problem is widespread among esoteric
>> languages. Anyone needing to get a competitive amount of work done cannot
>> afford to follow your advice, i.e. your advice is useless in the real
>> world.
>
> But that obviously isn't you. Or why would you be recounting your
> experiences about developing your own immature bindings in an esoteric
> language?
I learned from my mistake and now use F# and WPF precisely because they do
not have this problem.
> The FFI technology in the best Lisp implementations is very solid. Most of
> the issues are solved out-of-the-box, so you just have to write the
> definitions...
Writing "the definitions" is the only hard part and it must be done by hand
because the necessary information is only available in the form of English
documentation and not in a machine readable form (e.g. it cannot be
obtained from the C headers by an FFI).
> to connect to your particular API. You still have to confront
> some of the same issues, but the FFI has solutions for them. The bindings
> you write inherit maturity from the underlying FFI module.
Nonsense. The bindings you write inherit the fragility of your definitions
which inevitably contain many errors and require extensive testing and
debugging.
> Looking at the Objective Caml documentation about interfacing with C,
> no wonder you think this stuff is a big deal! You have to do lame stuff,
> like write wrapper functions in C, and call those, rather than call the
> real functions.
Use one of the autogenerators and you recover the same properties that Lisp
has (but it still isn't enough).
> Lisp FFI's work without any stub code. You simply declare the interface,
> and it connects directly to the function you want to be calling. The FFI
> knows how to generate a C function call and do any necessary conversions,
> move data between GC safe and unsafe buffers and stuff like that.
That is nowhere near enough in practice. Look at the list of issues I gave:
the FFI does not know about dlopen, or how to preserve types across
separate functions, or the implicit dependencies between allocated values,
or the order functions must be called in, or how to handle GL errors. These
are the real problems and they cannot be "solved out-of-the-box" by an FFI.
If you want to support esoteric languages like Lisp adequately then the only
viable solution is a managed common language run-time where multiple
language communities collaborate on shared, safe, high-level bindings to
existing libraries.
On .NET, my F# code calls WPF which contains bindings to Direct X written in
C# that call the low-level driver code. Everything outside my F# code has
already been tested by hundreds of millions of users: it is mature. Compare
that with cl-opengl which appears to have had only 75 users and no
successful projects and you can glimpse the chasm in maturity between these
solutions.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Dimiter "malkia" Stanev wrote:
>> Jon Harrop wrote:
>>> .. Static link or dynamic load the whole GL?
>> Off course dynamic, how otherwise else? (MESA?)
>
> Some bindings use dlopen (e.g. GLCaml) others do not (e.g. LablGL).
>
>>> .. Do you expose GL extensions in the target language and, if so, how?
>> As long as you have glGetExtensions, and some way to callback a function
>> with parameters (and you have that in CL with CFFI).
>
> So you don't bind GL extensions at all, you just leave it for the user.
You don't know Lispers. Offer us a wheel and we'll get all excited and
go make our own. Except the Yobbos, they'll keep working on where to put
the axle on an epitichroid. Don't worry, it will be free.
>
>>> .. How do you make "void *" type safe in the GLU tesselator?
>> What if you don't use the GLU tesselator?
>
> So you only aspire to write partial bindings?
Pay attention. The bindings aren't partial if I do not need the others.
Wade <·············@gmail.com> writes:
> Lisp is not popular because of the s-exp syntax. Many people
> are thrown right away when looking at it.
In my experience, that issue mostly goes away when using low-contrast
parenthesis (parenface) and syntax coloring.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
On Dec 24, 4:54 pm, ·············@deadspam.com (Luís Oliveira) wrote:
> Wade <·············@gmail.com> writes:
> > Lisp is not popular because of the s-exp syntax. Many people
> > are thrown right away when looking at it.
>
> In my experience, that issue mostly goes away when using low-contrast
> parenthesis (parenface) and syntax coloring.
i have a love for uniform syntax systems.
By “system”, it is meant that there are no exceptions, with just a
core axiom or principle. A pure parenthesis nested syntax, is such a
system. Other such syntax system include XML, and Mathematica's
syntax.
When things are uniform, it is subject to systematic automation, which
in turn means huge power. Especially today, the computing industry is
more and more aware of this. Witness XML and the whole of its
associated technologies, the semantic web, and in particular Google's
software that puts a heavy emphasis on massive scale automation.
(when you talk about automation, one of the most important element is
simplicity and uniformality. (not assuming here strong AI))
The first thing lisp's syntax benefitted lispers is the development of
the concept of macros. Unfortunately, lisp's syntax are irregular,
thus destroyed much of its potential. One of the potential is a
transparent a layer of human-readible syntax, which would maintain the
whole advantage of machine parsible uniform nested syntax yet humans
don't have to use that if they don't want to. (e.g. such syntax system
is in Mathematica, or in lisp circles so-called M-expression)
Having written a book-length tutorial on emacs lisp in the past 3
years, my personal experience is that coding in nested paren is a pain
in the ass in actual coding, despite emacs being the lisp editor with
all its editing power.
For a detailed exposition on nested syntax, see:
• The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations
http://xahlee.org/UnixResource_dir/writ/notations.html
in particular, the 3rd section “How Purely Nested Notation Limits The
Language's Utility”.
For a detailed exposition on how lisp's irregularities damaged the
lang's potential, see the section “Syntax Irregularities” at
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
the following is a plain text excert from one of the section of the
above article.
---------------------------------
How Purely Nested Notation Limits The Language's Utility
2007-05-03
There is a common complain by programers about lisp's notation, of
nested parenthesis, being unnatural or difficult to read. Long time
lisp programers, often counter, that it is a matter of conditioning,
and or blaming the use of “inferior” text editors that are not
designed to display nested notations. In the following, i describe how
lisp notation is actually a problem, in several levels.
(1) Some 99% of programers are not used to the nested parenthesis
syntax. This is a practical problem. On this aspect along, lisp's
syntax can be considered a problem.
(2) Arguably, the pure nested syntax is not natural for human to read.
Long time lispers may disagree on this point.
(3) Most importantly, a pure nested syntax discourages frequent or
advanced use of function sequencing or compositions. This aspect is
the most devastating.
The first issue, that most programers are not comfortable with nested
notation, is well known. It is not a technical issue. Whether it is
considered a problem of the lisp language is a matter of philosophical
disposition.
The second issue, about nested parenthesis not being natural for human
to read, may be debatable. I do think, that deep nesting is a problem
to the programer. Here's a example of 2 blocks of code that are
syntactically equivalent in the Mathematica language:
vectorAngle[{a1_, a2_}] := Module[{x, y},
{x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
If[x == 0, If[····@y === 1, π/2, -π/2],
If[y == 0, If[····@x === 1, 0, π],
If[····@y === 1, ······@x, 2 π - ······@x]
]
]
]
SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
Module[List[x,y],
CompoundExpression[
Set[List[x,y],
N[Times[List[a1,a2],
Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
If[Equal[x,0],
If[SameQ[Sign[y],1],Times[π,Power[2,-1]],
Times[Times[-1,π],Power[2,-1]]],
If[Equal[y,0],If[SameQ[Sign[x],1],0,π],
If[SameQ[Sign[y],1],ArcCos[x],
Plus[Times[2,π],Times[-1,ArcCos[x]]]]]]]]]
In the latter, it uses a full nested form (called FullForm in
Mathematica). This form is isomorphic to lisp's nested parenthesis
syntax, token for token (i.e. lisp's “(f a b)” is Mathematica's “f
[a,b]”). As you can see, this form, by the sheer number of nested
brackets, is in practice problematic to read and type. In Mathematica,
nobody really program using this syntax. (The FullForm syntax is
there, for the same reason of language design principle shared with
lisp of “consistency and simplicity”, or the commonly touted lisp
advantage of “data is program; program is data”.)
The following shows the same code with tokens transformed into the
lisp style.
(SetDelayed
(vectorAngle (list (Pattern a1 (Blank)) (Pattern a2 (Blank))))
(let (list x y)
(progn
(setq (list x y)
(N (* (list a1 a2)
(exp (sqrt (+ (exp a1 2) (exp a2 2))) -1))))
(if (eq x 0)
(if (equal (signum y) 1) (* π (exp 2 -1))
(* (* -1 π) (exp 2 -1)))
(if (eq y 0) (if (equal (signum x) 1) 0 π)
(if (equal (signum y) 1) (acos x)
(+ (* 2 π) (* -1 (acos x)))))))))
Note: The steps to transform the sample Mathematica code in FullForm
to lisp's sexp is done by these operations (for those curious):
* 1. Move the head inside. (using this regex “\([A-Za-z]+\)\[” →
“[\1”)
* 2. Replace bracket by parens. [] → ()
* 3. Replace function names to lisp styled names:
o Plus → +
o Times → *
o List → list
o If → if
o Set → setq
o Power → exp
o Sqrt → sqrt
o Equal → eq
o SameQ → equal
o Sign → signum
o ArcCos → acos
o Module → let
o CompoundExpression → progn
o Replace comma to space. (“,” → “ ”)
* 4. Adjust linebreaks and indentations to lisp convention.
The third issue, about how nested syntax seriously discourages
frequent or advanced use of inline function sequencing on the fly, is
the most important and I'll give further explanation below.
One practical way to see how this is so, is by considering unix's
shell syntax. You all know, how convenient and powerful is the unix's
pipes. Here are some practical example: “ls -al | grep xyz”, or “cat a
b c | grep xyz | sort | uniq”.
Now suppose, we get rid of the unix's pipe notation, instead, replace
it with a pure functional notation: e.g. (uniq (sort (grep xyz (cat a
b c)))), or enrich it with a composition function and a pure function
construct (aka lambda), so this example can be written as:
((composition uniq sort (lambda (x) (grep xyz x))) (cat a b c)).
You see, how this change, although syntactically equivalent to the
pipe “|” (or semantically equivalent in the example using function
compositions), but due to the cumbersome nesting of parenthesis, will
force a change in the nature of the language by the code programer
produces. Namely, the frequency of inline sequencing of functions on
the fly will probably be reduced, instead, there will be more code
that define functions with temp variables and apply it just once as
with traditional languages.
A language's syntax or notation system, has major impact on what kind
of code or style or thinking pattern on the language's users. This is
a well-known fact for those acquainted with the history of math
notations.
The sequential notation ··@·@·@x”, or “x//h//g//f”, or unixy “x|h|g|
f”, are far more convenient and easier to decipher, than “(f (g (h
x)))” or “((composition f g h) x)”. In actual code, any of the f, g, h
might be a complex pure function (aka lambda constructs, full of
parenthesis themselves).
Lisp, by sticking with a almost uniform nested parenthesis notation,
it immediately reduces the pattern of sequencing functions, simply
because the syntax does not readily lend the programer to it as in the
unix's “x|h|g|f”. For programers who are aware of the coding pattern
of sequencing functions, now either need to think in terms of a
separate “composition” construct, and or subject to the much
problematic typing and deciphering of nested parenthesis. (in
practice, it's mostly done by writing the inline functions as a
auxiliary function definitions on their own, then another code block
sequence them together.)
(Note: Lisp's sexp is actually not that pure. It has ad hoc syntax
equivalents such as the “quote” construct “ '(a b c) ”, and also “`”,
“#”, “,@” constructs, precisely for the purpose of reducing
parenthesis and increasing readability. Scheme's coming standard the
R6RS ↗, even proposes the introduction of [] and {} and few other
syntax sugars to break the uniformity of nested parenthesis for
legibility. Mathematica's FullForm, is actually a version of
unadulterated nested notation as can be. For a full discussion, see:
Fundamental Problems of Lisp. )
Xah
∑ http://xahlee.org/
☄
On Dec 25, 12:34 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Xah Lee <······@gmail.com> writes:
> > vectorAngle[{a1_, a2_}] := Module[{x, y},
> > {x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
> > If[x == 0, If[····@y === 1, ð/2, -ð/2],
> > If[y == 0, If[····@x === 1, 0, ð],
> > If[····@y === 1, ······@x, 2 ð - ······@x]
> > ]
> > ]
> > ]
>
> > SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
> > Module[List[x,y],
> > CompoundExpression[
> > Set[List[x,y],
> > N[Times[List[a1,a2],
> > Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
> > If[Equal[x,0],
> > If[SameQ[Sign[y],1],Times[ð,Power[2,-1]],
> > Times[Times[-1,ð],Power[2,-1]]],
> > If[Equal[y,0],If[SameQ[Sign[x],1],0,ð],
> > If[SameQ[Sign[y],1],ArcCos[x],
> > Plus[Times[2,ð],Times[-1,ArcCos[x]]]]]]]]]
> > The following shows the same code with tokens transformed into the
> > lisp style.
>
> > (SetDelayed
> > (vectorAngle (list (Pattern a1 (Blank)) (Pattern a2 (Blank))))
> > (let (list x y)
> > (progn
> > (setq (list x y)
> > (N (* (list a1 a2)
> > (exp (sqrt (+ (exp a1 2) (exp a2 2))) -1))))
> > (if (eq x 0)
> > (if (equal (signum y) 1) (* ð (exp 2 -1))
> > (* (* -1 ð) (exp 2 -1)))
> > (if (eq y 0) (if (equal (signum x) 1) 0 ð)
> > (if (equal (signum y) 1) (acos x)
> > (+ (* 2 ð) (* -1 (acos x)))))))))
>
> The above is not Common Lisp, either.
>
> (declaim (inline square))
> (defun square (x) (* x x))
>
> (defun vector-angle (v)
> (destructuring-bind (x y) v
> (cond
> ((zerop x) (if (plusp y) (/ pi 2) (/ pi -2)))
> ((zerop y) (if (plusp x) 0 pi))
> ((plusp y) (acos (/ x (sqrt (+ (square x) (square y))))))
> (t (- (* 2 pi)
> (acos (/ x (sqrt (+ (square x) (square y))))))))))
>
> > In the latter, it uses a full nested form (called FullForm in
> > Mathematica). This form is isomorphic to lisp's nested parenthesis
> > syntax, token for token (i.e. lisp's "(f a b)" is Mathematica's "f
> > [a,b]"). As you can see, this form, by the sheer number of nested
> > brackets, is in practice problematic to read and type.
>
> What's problematic is not being able to program... to write elegant code.
>
> --
> __Pascal Bourguignon__
Pros for Scheme (rather than Lisp) I can think of:
1: uniform syntax (with a good editor you hardly notice the
parentheses any longer after two days of practice)
2: very few semantical restrictions.
3: Most important: a program is a datum that can be read simply by
(read port). Therefore it is rather easy two write code that
manipulates and generates programs.
4: The hygienic macros of syntax-rules and syntax-case facilitate the
construction of macro's (this is related to point 3, of course)
5: point 4 makes it very easy to extend the language to your own
needs.
I don't know why, but for a product to be supreme is not enough to be
choosen by a general public or even to survive. Sometimes I even
suspect some programmers (I dont want you to read this a
generalization) that they prefer cryptic notation (and documentation)
above modern clear notation and acceessible documentation, just
because their knowledge of the cryptics lends them some power over
people (may be customers) without that knowledge.
There are some difficulties newbies may experience when being
introduced in Lisp or Scheme. The most important one is, I think, the
distinction between 'quotation' and 'mention'. For example `(a b c)'
is a list, while `(list 'a 'b 'c)' or `(quote (a b c))' are
expressions (btw lists too) that evaluate to the list `(a b c)'. Some
may considere this a contra. I think it is a pro, for it forces the
programmer to keep in mind the distinction between 'quotation' and
`mention'. I mean the question: "what is left of a sorcerer after his
tricks have been exposed?"
(if you want to respond to my 2 cents, please cc it to jos dot koot at
telefonica dot com)
Jos
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gjad8p$1bk0$1@opal.icpnet.pl>
In comp.lang.lisp jos koot <········@telefonica.net> wrote:
> 4: The hygienic macros of syntax-rules and syntax-case facilitate the
> construction of macro's (this is related to point 3, of course)
Their worthless-excuse-of-a-macro-system can hardly be called an
advantage. Common Lispers excercise their creativity to define
macro-based abstractions, but the same doesn't hold true for Scheme.
Reason? Their macro system sucks and they're in denial.
FUT ignored.
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
Stanisław Halik wrote:
> In comp.lang.lisp jos koot <········@telefonica.net> wrote:
>> 4: The hygienic macros of syntax-rules and syntax-case facilitate the
>> construction of macro's (this is related to point 3, of course)
> Their worthless-excuse-of-a-macro-system can hardly be called an
> advantage. Common Lispers excercise their creativity to define
> macro-based abstractions, but the same doesn't hold true for Scheme.
>
> Reason? Their macro system sucks and they're in denial.
So you're saying that there are not a lot of people writing macros in Scheme
because its macro system sucks compared to Common Lisp's but there are also
not a lot of people writing macros in Lisp because Lisp and macros suck.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Mon, 05 Jan 2009 02:24:59 +0000, Jon Harrop <···@ffconsultancy.com>
wrote:
>Stanis?aw Halik wrote:
>> In comp.lang.lisp jos koot <········@telefonica.net> wrote:
>>> 4: The hygienic macros of syntax-rules and syntax-case facilitate the
>>> construction of macro's (this is related to point 3, of course)
>> Their worthless-excuse-of-a-macro-system can hardly be called an
>> advantage. Common Lispers excercise their creativity to define
>> macro-based abstractions, but the same doesn't hold true for Scheme.
>>
>> Reason? Their macro system sucks and they're in denial.
>
>So you're saying that there are not a lot of people writing macros in Scheme
>because its macro system sucks compared to Common Lisp's but there are also
>not a lot of people writing macros in Lisp because Lisp and macros suck.
OTOH, there are probably a lot of people not writing macros in either
Lisp or Scheme because they don't feel any need to do so.
Some programmers think any repetitive pattern is fodder for a macro,
but you really only need them if you want to change how arguments are
evaluated.
George
Xah Lee wrote:
> > vectorAngle[{a1_, a2_}] := Module[{x, y},
> > {x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
> > If[x == 0, If[····@y === 1, π/2, -π/2],
> > If[y == 0, If[····@x === 1, 0, π],
> > If[····@y === 1, ······@x, 2 π - ······@x]
> > ]
> > ]
> > ]
>
> > SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
> > Module[List[x,y],
> > CompoundExpression[
> > Set[List[x,y],
> > N[Times[List[a1,a2],
> > Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
> > If[Equal[x,0],
> > If[SameQ[Sign[y],1],Times[π,Power[2,-1]],
> > Times[Times[-1,π],Power[2,-1]]],
> > If[Equal[y,0],If[SameQ[Sign[x],1],0,π],
> > If[SameQ[Sign[y],1],ArcCos[x],
> > Plus[Times[2,π],Times[-1,ArcCos[x]]]]]]]]]
> > The following shows the same code with tokens transformed into the
> > lisp style.
>
> > (SetDelayed
> > (vectorAngle (list (Pattern a1 (Blank)) (Pattern a2 (Blank))))
> > (let (list x y)
> > (progn
> > (setq (list x y)
> > (N (* (list a1 a2)
> > (exp (sqrt (+ (exp a1 2) (exp a2 2))) -1))))
> > (if (eq x 0)
> > (if (equal (signum y) 1) (* π (exp 2 -1))
> > (* (* -1 π) (exp 2 -1)))
> > (if (eq y 0) (if (equal (signum x) 1) 0 π)
> > (if (equal (signum y) 1) (acos x)
> > (+ (* 2 π) (* -1 (acos x)))))))))
Pascal J. Bourguignon wrote:
> The above is not Common Lisp, either.
The point in that section of the article
http://xahlee.org/UnixResource_dir/writ/notations.html
is to demonstrate the isomorphism of the syntax between Mathematica
and lisp.
It is not about whether simple transmutation of the syntax of
Mathematica can become a runnable Common Lisp program.
Xah wrote:
> > In the latter, it uses a full nested form (called FullForm in
> > Mathematica). This form is isomorphic to lisp's nested parenthesis
> > syntax, token for token (i.e. lisp's “(f a b)” is Mathematica's “f
> > [a,b]”). As you can see, this form, by the sheer number of nested
> > brackets, is in practice problematic to read and type.
Pascal wrote:
> What's problematic is not being able to program... to write elegant code.
The issue addressed in the article is about language syntax and its
relation to coding. It is not about whether it is possible to create
elegant code in a lang with bad syntax.
Xah
∑ http://xahlee.org/
☄
From: Don Geddis
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <87r63vvlcf.fsf@geddis.org>
Xah Lee <······@gmail.com> wrote on Thu, 25 Dec 2008:
> The first thing lisp's syntax benefitted lispers is the development of
> the concept of macros. Unfortunately, lisp's syntax are irregular,
> thus destroyed much of its potential.
You've been asked many times, but have yet to come up with a SINGLE example
where Common Lisp's "irregular" syntax affects Common Lisp's macros in ANY
way. Much less "destroyed [...] its potential."
Do you find, when you're unable to justify your lies, that simply repeating
them makes you feel better?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I hope that after I die, people will say of me: ``That guy sure owed me a lot
of money.'' -- Deep Thoughts, by Jack Handey
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gj00ou$hbe$1@opal.icpnet.pl>
thus spoke Wade <·············@gmail.com>:
> Lisp is not popular because of the s-exp syntax.
[...]
> Learn to be unpopular, it is freeing.
Maybe the best argument against popular languages could be a five-minute
conversation with an average programmer?
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
Stanisław Halik wrote:
> thus spoke Wade <·············@gmail.com>:
>
>> Lisp is not popular because of the s-exp syntax.
> [...]
>> Learn to be unpopular, it is freeing.
>
> Maybe the best argument against popular languages could be a five-minute
> conversation with an average programmer?
Or a subscription to the Daily WTF feed at http://thedailywtf.com/ ;)
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/
On Dec 25, 2:12 pm, Pascal Costanza <····@p-cos.net> wrote:
> Stanis³aw Halik wrote:
> > Maybe the best argument against popular languages could be a five-minute
> > conversation with an average programmer?
>
> Or a subscription to the Daily WTF feed athttp://thedailywtf.com/;)
Sadly, I've seen monstrous Common Lisp code which is magnificent in
its ugliness. You wouldn't believe what DECLARE SPECIAL can do, in the
hands of someone with a vendetta against LET.
Or for a more common example, execute this in front of a newbie (and
offer no guidance for what her computer does next):
(asdf-install:install :clsql)
We'll assume you remembered to install/enable asdf-install...
Or try editing Lisp code without Paredit. If you already use Paredit,
have you noticed how much pity you feel for Lisp users futzing with
parens? "I don't see parens anymore!" they'll claim, when you're
watching them doing all sorts of complicated processes involving paren-
matching and indentation.
I recently taught someone Common Lisp. (She enjoyed using it for a
night after I left, then put it away like a forgotten toy.) To explain
COND and LET, I had to fire up Clojure. That made CL's versions
clearer.
(This is not to pick on Common Lisp in particular: the whole software
world suffers from it. For example, I can't believe anyone at Sun ever
wondered why applets didn't take off. And those people who say that
Linux is ready for grandma... how many grandmothers have they driven
to early graves?)
Tayssir
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gj2leu$aq9$3@opal.icpnet.pl>
thus spoke Tayssir John Gabbour <············@googlemail.com>:
> Or try editing Lisp code without Paredit. If you already use Paredit,
> have you noticed how much pity you feel for Lisp users futzing with
> parens? "I don't see parens anymore!" they'll claim, when you're
> watching them doing all sorts of complicated processes involving paren-
> matching and indentation.
FWIW, Paredit's great, but it's missing one important operation:
(defun nest-sexp ()
(interactive)
(let ((start (point))
(end (save-excursion
(forward-sexp)
(point))))
(insert "( ")
(goto-char (+ 2 end))
(insert ")")
(goto-char (1+ start))))
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
On Dec 26, 2:16 pm, Stanis³aw Halik <··············@tehran.lain.pl>
wrote:
> FWIW, Paredit's great, but it's missing one important operation:
>
> (defun nest-sexp ()
> (interactive)
> (let ((start (point))
> (end (save-excursion
> (forward-sexp)
> (point))))
> (insert "( ")
> (goto-char (+ 2 end))
> (insert ")")
> (goto-char (1+ start))))
Cool... but doesn't that do basically the same thing as paredit-wrap-
sexp? (Though it looks handy in that it adds an extra space in front
of your cursor.)
Tayssir
On Dec 26, 3:21 pm, Tayssir John Gabbour <············@googlemail.com>
wrote:
> Cool... but doesn't that do basically the same thing as paredit-wrap-
> sexp? (Though it looks handy in that it adds an extra space in front
> of your cursor.)
paredit-wrap-sexp is incidentally bound to M-(.
For some reason, I always feel like I'm making some kinda energy orb
when typing that chord... filling it with the next sexp. (Or
generating an empty orb if there is no next sexp.)
Tayssir
On Dec 26, 3:21 pm, Tayssir John Gabbour <············@googlemail.com>
wrote:
> On Dec 26, 2:16 pm, Stanis³aw Halik <··············@tehran.lain.pl>
> wrote:
>
> > FWIW, Paredit's great, but it's missing one important operation:
>
> > (defun nest-sexp ()
> > (interactive)
> > (let ((start (point))
> > (end (save-excursion
> > (forward-sexp)
> > (point))))
> > (insert "( ")
> > (goto-char (+ 2 end))
> > (insert ")")
> > (goto-char (1+ start))))
>
> Cool... but doesn't that do basically the same thing as paredit-wrap-
> sexp? (Though it looks handy in that it adds an extra space in front
> of your cursor.)
>
> Tayssir
On Dec 25, 7:10 am, Stanis³aw Halik <··············@tehran.lain.pl>
wrote:
> > Learn to be unpopular, it is freeing.
>
> Maybe the best argument against popular languages could be a five-minute
> conversation with an average programmer?
There's a reason the Goth kids love Common Lisp.
············@gmail.com wrote:
> On Dec 25, 7:10 am, Stanis�aw Halik <··············@tehran.lain.pl>
> wrote:
>>> Learn to be unpopular, it is freeing.
>> Maybe the best argument against popular languages could be a five-minute
>> conversation with an average programmer?
>
> There's a reason the Goth kids love Common Lisp.
LOL!
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/
I have been considering the popularity thing. It is probably solvable
by using marketing/persuasion. There is a show here in Canada
called the "The Age of Persuasion". It has thoughtful insights into
how to persuade people. Here as link into the series of audio casts.
http://www.cbc.ca/ageofpersuasion/2008/06/six_remarkable_brands_1.html
Wade
On Dec 26, 2:57 pm, Wade <·············@gmail.com> wrote:
> I have been considering the popularity thing. It is probably solvable
> by using marketing/persuasion.
It's _partially_ solvable via marketing. Marketing only solves the
first half of the expected-benefits vs. barrier-to-entry problem. If
we convince people to check out Lisp but it's still a pain in the ass
to get started, we're no better off than we were before.
The marketing of Lisp _is_ terrible. It's put succinctly by this blog
post:
http://www.lispcast.com/drupal/node/29
...though it gives significant leniency to Lisp by using common-
lisp.net as the Lisp example: it's not even in the top 10 Google hits
for Lisp, and unlike the relevant top 10 (minus Wikipedia and
planet.lisp.org,) it actually has a decent design aesthetic.
Combining marketing with reducing the barrier to entry: the single
biggest thing that would improve Lisp's popularity would be making the
Able home page the #1 Google hit for Lisp. (http://
phil.nullable.eu/) Move the "Potential issues and To-do list" section
to a separate page, add a "Getting started with Lisp" section with a
link to the Practical Common Lisp book, and we'd be set.
Walter
Here's a screenshot tour of the top 10 Google hits for Lisp:
http://waltergr.com/tlgh/
(These may differ from your top 10 ghits - Google customizes results
based on your search history... Clear your Google cookie and you
should see the same pages.)
Walter
On Dec 26, 4:39 pm, WalterGR <········@gmail.com> wrote:
> On Dec 26, 2:57 pm, Wade <·············@gmail.com> wrote:
>
> > I have been considering the popularity thing. It is probably solvable
> > by using marketing/persuasion.
>
> It's _partially_ solvable via marketing. Marketing only solves the
> first half of the expected-benefits vs. barrier-to-entry problem. If
> we convince people to check out Lisp but it's still a pain in the ass
> to get started, we're no better off than we were before.
There are large barrier-to-entry for many successful brands.
There is nothing wrong with barriers and there are and will always be
barriers to entry to using Lisp. Other programming
languages have the same barriers as Lisp has, the difference is that
they are taught in schools and the barrier is slowly removed over
years of learning. Lisp is hardly taught any more and the onus is
on students to teach themselves. I also think that most people who
are
trying Lisp are the experienced programmers. When they find
it a pain they think there is something wrong with Lisp and not
with their education and experience (and that is a big problem).
They have to un-learn and re-learn which takes
four or five times the energy just learning would take.
(The refreshing part in my experience is the young programmers
who I have met that have taught themselves Lisp without going
through the current programmer education. I have nothing but
admiration for them).
If the perceived pain-in-the-ass aspect can be turned around into
positive...
Wade
Wade <·············@gmail.com> writes:
> [...] Other programming
> languages have the same barriers as Lisp has, the difference is that
> they are taught in schools and the barrier is slowly removed over
> years of learning. Lisp is hardly taught any more and the onus is
> on students to teach themselves. [...]
Other programming languages are taught in schools because enterprises
want programmers in these languages (and finance universities in that
direction). Programming languages are popular because they can land
their users a job.
--
__Pascal Bourguignon__
WalterGR <········@gmail.com> writes:
> ...though it gives significant leniency to Lisp by using common-
> lisp.net as the Lisp example: it's not even in the top 10 Google hits
> for Lisp, and unlike the relevant top 10 (minus Wikipedia and
> planet.lisp.org,) it actually has a decent design aesthetic.
Add planet.lisp.org as far as I'm concerned. A redesign is long past
due.
Zach
On Dec 26, 6:32 pm, Zach Beane <····@xach.com> wrote:
> WalterGR <········@gmail.com> writes:
> > ...though it gives significant leniency to Lisp by using common-
> > lisp.net as the Lisp example: it's not even in the top 10 Google hits
> > for Lisp, and unlike the relevant top 10 (minus Wikipedia and
> > planet.lisp.org,) it actually has a decent design aesthetic.
>
> Add planet.lisp.org as far as I'm concerned. A redesign is long past
> due.
>
> Zach
Really? I think you've done a fantastic job. I'd only suggest
increasing the margin-left on the right sidebar, so the headings
aren't smushed against the dashed vertical line.
Just by virtue of using a sans serif font and not using rainbow.gif as
a horizontal rule you're at least 13 years ahead of the rest.
Walter
On Fri, 26 Dec 2008 21:32:30 -0500, Zach Beane wrote:
> Add planet.lisp.org as far as I'm concerned. A redesign is long past
> due.
what's wrong with it ? I find it refreshingly minimalistic and devoid of
gratuitous CSS trickery (the oposite of stackoverflow.com)
On Fri, 26 Dec 2008 15:39:23 -0800, WalterGR wrote:
> Combining marketing with reducing the barrier to entry: the single
> biggest thing that would improve Lisp's popularity would be making the
> Able home page the #1 Google hit for Lisp. (http:// phil.nullable.eu/)
good heavens! if this is the "biggest thing that would improve Lisp's
popularity" then I'd rather CL remain unpopular as it is.
why is it that noobs want to advertise such primitive tools as ABLE or
CUSP/Eclipse ?
On Dec 26, 4:29 pm, alien_guy <····@l.org> wrote:
> On Fri, 26 Dec 2008 15:39:23 -0800, WalterGR wrote:
> > Combining marketing with reducing the barrier to entry: the single
> > biggest thing that would improve Lisp's popularity would be making the
> > Able home page the #1 Google hit for Lisp. (http:// phil.nullable.eu/)
>
> good heavens! if this is the "biggest thing that would improve Lisp's
> popularity" then I'd rather CL remain unpopular as it is.
> why is it that noobs want to advertise such primitive tools as ABLE or
> CUSP/Eclipse ?
You don't know a thing about me, so it's impolite to call me a
"noob." Further, did you read my post at all? I said Able being the
#1 link on Google would best help its popularity, not that every Lisp
programmer should use Able.
Your post captures precisely why Lisp isn't more popular.
"I know about this programming language that's more powerful than
*any* other programming language out there. You want to learn it?
Okay, first you have to use this specific programming environment. No
no no... you'll learn to *like* those key chords! It's one of the
benefits, you see. Besides, if you don't like them, you can change
them. How do you change them? Oh, you just use this programming
language that's more powerful than *any* other programming language
out there."
Walter
On Fri, 26 Dec 2008 16:55:02 -0800, WalterGR wrote:
> Your post captures precisely why Lisp isn't more popular.
I still need to be explained why I should strive for popularity. Your
arguments are much too similar to those of many religious fanatics I met
who cannot conceive that there are people who do not wish to proselytise
their own personal faith.
> "I know about this programming language that's more powerful than *any*
> other programming language out there. You want to learn it? Okay, first
Again, why would I want to teach CL to somebody else ?
alien_guy <·@l.org> writes:
> On Fri, 26 Dec 2008 16:55:02 -0800, WalterGR wrote:
>> Your post captures precisely why Lisp isn't more popular.
>
> I still need to be explained why I should strive for popularity. Your
> arguments are much too similar to those of many religious fanatics I met
> who cannot conceive that there are people who do not wish to proselytise
> their own personal faith.
Actually, more than "popularity", what whould be in the interest of most
lispers, I'd guess, is to strive for more corporate penetration. We
would like lisp be more used in corporation, so we would get more lisp jobs.
>> "I know about this programming language that's more powerful than *any*
>> other programming language out there. You want to learn it? Okay, first
>
> Again, why would I want to teach CL to somebody else ?
It would be part of the strategy to make lisp more used in corporate
world. In enterprises, we often hear that there are not enough lisp
programmers, that it would be even harder to hire lisp programmers than
good C++ (or whatever) programmers.
--
__Pascal Bourguignon__
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gjadjg$1bk0$2@opal.icpnet.pl>
thus spoke Pascal J. Bourguignon <···@informatimago.com>:
> Actually, more than "popularity", what whould be in the interest of most
> lispers, I'd guess, is to strive for more corporate penetration. We
> would like lisp be more used in corporation, so we would get more lisp jobs.
How's that achievable without an inescapable B&D sandbox?
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
Stanisław Halik <··············@tehran.lain.pl> writes:
> thus spoke Pascal J. Bourguignon <···@informatimago.com>:
>
>> Actually, more than "popularity", what whould be in the interest of most
>> lispers, I'd guess, is to strive for more corporate penetration. We
>> would like lisp be more used in corporation, so we would get more lisp jobs.
>
> How's that achievable without an inescapable B&D sandbox?
Basically, enterprises are there to make a profit. If you can earn
more money (or reduce expanses) by using Lisp technology rather than
something else, most CFO should be able to convince the most obtuse CEO.
And for the B&D lovers:
Even a Java programmer may think out of the box.
But for a long time yet, macros won't think out of the box.
Replace Java programmers by Lisp macros! :-)
--
__Pascal Bourguignon__
WalterGR <········@gmail.com> writes:
> You want to learn it? Okay, first you have to use this specific
> programming environment. No no no... you'll learn to *like* those
> key chords!
How did you leap from luring someone into Lisp to luring him into Emacs?
Yes, I prefer to use Emacs for my Lisp programming. I also prefer it for
/all/ of my programming and editing in general. Java is the only
exception, insofar as the other popular IDEs offer features my team uses
that aren't available with within an appropriate Emacs mode. Regardless,
I have my Java-focused IDE's editor configured to work as much as
possible like Emacs.
You could persuade people to like or dislike Emacs as a separate
endeavor. Don't wrap that up in your crusade for Lisp.
--
Steven E. Harris
On Dec 27, 7:09 am, "Steven E. Harris" <····@panix.com> wrote:
> WalterGR <········@gmail.com> writes:
> > You want to learn it? Okay, first you have to use this specific
> > programming environment. No no no... you'll learn to *like* those
> > key chords!
>
> How did you leap from luring someone into Lisp to luring him into Emacs?
Am I mistaken that Emacs + SLIME is the de facto standard Lisp
development environment? That's the sense I get reading *any* thread
on c.l.l that starts with someone asking what development environment
to use.
> Don't wrap that up in your crusade for Lisp.
Don't be rude. I have no crusade for Lisp, nor could you possibly
find one in my postings. I've always been discussing why I think Lisp
isn't more popular.
Alien Guy, Tamas, and Steven: I don't know if you're intentionally
mischaracterizing my posts for the sake of baiting me into argument or
if there's a language barrier (giving the benefit of the doubt I'll
assume it's the latter,) but unless you do me the courtesy of
carefully reading my posts I will not reply further to yours.
Thanks,
Walter
On Sat, 27 Dec 2008 11:36:06 -0800, WalterGR wrote:
> Am I mistaken that Emacs + SLIME is the de facto standard Lisp
> development environment? That's the sense I get reading *any* thread on
> c.l.l that starts with someone asking what development environment to
> use.
I know of no systematic survey so I can't say. Also consider that CLL is
not a representative sample of Lisp users.
But I know why I would recommend Emacs+SLIME: it is free, easy to learn,
works well, and Emacs is worth trying even for other things than Lisp.
Perhaps people are recommending it because they find it useful? That
could happen, however strange that sounds to you.
> Alien Guy, Tamas, and Steven: I don't know if you're intentionally
> mischaracterizing my posts for the sake of baiting me into argument or
> if there's a language barrier (giving the benefit of the doubt I'll
Yes, everyone who disagrees with you is intentionally mischaracterizing
your posts. We conspire against you intentionally off-list and laugh
behind your back. You are not paranoid at all.
> assume it's the latter,) but unless you do me the courtesy of carefully
> reading my posts I will not reply further to yours.
Suits me.
Tamas
WalterGR <········@gmail.com> writes:
> Am I mistaken that Emacs + SLIME is the de facto standard Lisp
> development environment?
Probably not. I use it, and I've recommended that other people try
it. In case Kenny chimes in, I have tried both Allegro CL's and
Lispwork's IDEs and, while each did have a few nice things, I spent too
much effort trying to get each to behave more like SLIME. Had I started
out differently, though, those other IDEs would have seemed more
natural.
> That's the sense I get reading *any* thread on c.l.l that starts with
> someone asking what development environment to use.
A lot of people like it, I agree. In October I met Luke Gorrie (SLIME's
original author) at the Lisp 50 event in Nashville and gushed praise
upon him for helping make SLIME. However, I don't think it's the only
way to find productivity for Lisp programming. All Emacs users
appreciate the tools that let them "stay at home". I'm typing this
message in Gnus, which is wonderful for too many reasons to count, but,
again, it also lets the Emacs user "stay at home".
> Don't be rude.
I didn't mean to be. I apologize for being curt. The post of yours to
which I replied stood out because it looked to be introducing a needless
fork in the discussion about Lisp's popularity, turning it toward a
discussion about Emacs, which has a whole set of advocacy problems of
its own.
> Alien Guy, Tamas, and Steven: I don't know if you're intentionally
> mischaracterizing my posts for the sake of baiting me into argument
No, don't read that much into what I wrote. My intention was to put a
roadblock or at least a guardrail into the discussion to push its focus
back onto Lisp itself, and not get hung up on discussing Emacs.
--
Steven E. Harris
On Dec 27, 9:48 pm, WalterGR <········@gmail.com> wrote:
> On Dec 27, 1:41 pm, Bakul Shah <············@bitblocks.com> wrote:
>
> > Why do you think he is talking about *you*? [snip]
>
> Ah. My apologies to Rob if that's the case.
>
> Walter
Er, my apologies to _Steven_ if that's the case.
On Dec 28, 6:43 am, "Steven E. Harris" <····@panix.com> wrote:
> WalterGR <········@gmail.com> writes:
> > Am I mistaken that Emacs + SLIME is the de facto standard Lisp
> > development environment?
>
> Probably not. I use it, and I've recommended that other people try
> it. [snip] I apologize for being curt. The post of yours to
> which I replied stood out because it looked to be introducing a needless
> fork in the discussion about Lisp's popularity, turning it toward a
> discussion about Emacs, which has a whole set of advocacy problems of
> its own.
But that's the thing... it's impossible to separate the two because
when budding / prospective Lisp developers ask which development
environment to use, the default answer is "use Emacs." My contention
is that the default response doesn't do anything to help Lisp's
cause. As you say, Emacs "has a a whole set of advocacy problems of
its own."
If Emacs + SLIME *weren't* the default answer, then I wouldn't have
been harping on Emacs, and would have been harping on the other
barriers to entry I listed. To prove my point, during the discussion
of Lisp marketing on this thread, I said, "the single biggest thing
that would improve Lisp's popularity would be making the Able home
page the #1 Google hit for Lisp." Alien Guy responds, "why is it that
noobs want to advertise such primitive tools as ABLE or CUSP/
Eclipse?" Point, set, match.
> > Alien Guy, Tamas, and Steven: I don't know if you're intentionally
> > mischaracterizing my posts for the sake of baiting me into argument
>
> No, don't read that much into what I wrote.
My apologies. I'm a bit defensive since my original arguments about
Lisp's popularity being affected by barriers to entry have come to be
construed as either a) "Walter the noob wants Tamas K. Papp to
personally work to make Lisp more popular," or b) "Walter the noob
refuses to learn Lisp because he doesn't like Emacs," neither of which
are true, and both of which *completely* miss the point of my
arguments.
Though I have come to realize that there are many on c.l.l who can't
imagine not using Emacs + SLIME, can't imagine not telling every
curious programmer who stumbles across Lisp that he should use it too,
and can't imagine people working on alternatives. I don't think I
have the rhetorical prowess to convince them that maybe that's not the
best thing for Lisp's popularity.
Walter
On Dec 28, 4:31 pm, WalterGR <········@gmail.com> wrote:
> Though I have come to realize that there are many on c.l.l who can't
> imagine not using Emacs + SLIME, can't imagine not telling every
> curious programmer who stumbles across Lisp that he should use it too,
> and can't imagine people working on alternatives. I don't think I
> have the rhetorical prowess to convince them that maybe that's not the
> best thing for Lisp's popularity.
To avoid any misunderstanding: by "I don't think I have the rhetorical
prowess to convince them that maybe that's not the best thing for
Lisp's popularity" I didn't mean those "who can't imagine not using
Emacs + SLIME." I'm all for people using the tools they prefer - I
can't imagine believing otherwise. There are just those for whom
Emacs _is_ a barrier to entry, and I hope that efforts like ABLE and
Eclipse + CUSP are encouraged rather than disparaged.
Walter
WalterGR <········@gmail.com> writes:
> I don't think I have the rhetorical prowess to convince them that
> maybe that's not the best thing for Lisp's popularity.
I see your point. Luring programmers in with nice tools can work, in
part by distracting them from the language of focus for those
tools. We're all suckers for a nice tool set. It's worked quite well for
Java. Now those tools built for Java are trying to grow "Emacs nature"
by generalizing to support many languages.
(An interesting counterexample is Scala. It's suffered a dearth of tool
support, with several abandoned attempts. Still, it attracts and for now
keeps a good number of adherents.)
On the popularity front, I find the biggest problem with bringing Lisp
to others' feet is that it's already too popular: people "know" it as
something they remember from long ago, something safe to mock
today. They barely believe that anyone's actually still using it for
real work, and even then their belief comes paired with characterizing
the user as an anachronistic freak -- not a pied piper to consider
seriously.
Given that, it might be better if Lisp was /less/ popular, at least for
a while. I think Franz tried this approach: selling Lisp but not calling
it that, burying the damning name, focusing instead on its unique
characteristics.
--
Steven E. Harris
On Mon, 29 Dec 2008 19:19:02 -0500, Steven E. Harris wrote:
> On the popularity front, I find the biggest problem with bringing Lisp
> to others' feet is that it's already too popular: people "know" it as
> something they remember from long ago, something safe to mock today.
> They barely believe that anyone's actually still using it for real work,
> and even then their belief comes paired with characterizing the user as
> an anachronistic freak -- not a pied piper to consider seriously.
Some universities still use Lisp in intro courses, but only to
demonstrate nice theoretical points and such things. Modern language
features (like CLOS, arrays, hash tables etc) and macros are mostly
ignored, and students finish the course with the impression that Lisp is
a playground language where one is required to perform mental acrobatics
on lists with weird functions like cadadr and by forcing everything to be
recursive. After that, they will not touch Lisp with a ten-foot pole.
Common Lisp would be much better off if students weren't forced to touch
Lisp until they were ready for it, and then learn it as a practical and
powerful language at their own pace, and only if they want to.
Tamas
On Dec 30, 1:51 am, Tamas K Papp <······@gmail.com> wrote:
> On Mon, 29 Dec 2008 19:19:02 -0500, Steven E. Harris wrote:
> > On the popularity front, I find the biggest problem with bringing Lisp
> > to others' feet is that it's already too popular: people "know" it as
> > something they remember from long ago, something safe to mock today.
> > They barely believe that anyone's actually still using it for real work,
> > and even then their belief comes paired with characterizing the user as
> > an anachronistic freak -- not a pied piper to consider seriously.
>
> Some universities still use Lisp in intro courses, but only to
> demonstrate nice theoretical points and such things. Modern language
> features (like CLOS, arrays, hash tables etc) and macros are mostly
> ignored, and students finish the course with the impression that Lisp is
> a playground language where one is required to perform mental acrobatics
> on lists with weird functions like cadadr and by forcing everything to be
> recursive. After that, they will not touch Lisp with a ten-foot pole.
>
> Common Lisp would be much better off if students weren't forced to touch
> Lisp until they were ready for it, and then learn it as a practical and
> powerful language at their own pace, and only if they want to.
>
> Tamas
Two remarks:
I've seen in introductory computer science course using Scheme, that
the
students who get it are usually really good. To find those it might
be useful to expose a lot of students to Lisp.
I've seen a professor doing a large part of the computer science
introductory
course in Common Lisp. She was introducing a large part of CL to the
students,
including CLOS. It helped that she had a good understanding of Lisp
and CL.
It was definitely not the naive Lisp introduction with CAR/CDR/CONS.
I've seen some good materials about Lisp courses in Germany, so it
can't be all that bad. One of the problems is that it takes
a bit time to understand the significance of Lisp and that
after an introductory course it would be necessary to use
Lisp in projects. I think the problem is more that after
the introduction the students don't do much with it. Programming
is usually not that important anymore. If they had to write
modules for robot software, vision algorithms, planners,
logic languages, etc. in Lisp, they could actually get some
experience and could see themselves where and how Lisp is useful.
Years ago students learned to write a complex scheduling system in
Lisp.
Today they learn how to write a Java/HTML- or even AJAX-based
web interface for a primitive scheduling system.
Tamas K Papp <······@gmail.com> writes:
> After that, they will not touch Lisp with a ten-foot pole.
That matches my experience exactly. Well put.
> Common Lisp would be much better off if students weren't forced to
> touch Lisp until they were ready for it, and then learn it as a
> practical and powerful language at their own pace, and only if they
> want to.
It's odd how even the worst programmers know that they should hate or at
least mock Lisp, not realizing that they'll have to suffer through so
much inferior technology before they'll be ready to appreciate what
they've prematurely cast aside.
--
Steven E. Harris
On 2008-12-30, Tamas K Papp <······@gmail.com> wrote:
> On Mon, 29 Dec 2008 19:19:02 -0500, Steven E. Harris wrote:
>>
> Some universities still use Lisp in intro courses, but only to
> demonstrate nice theoretical points and such things. Modern language
> features (like CLOS, arrays, hash tables etc) and macros are mostly
> ignored, and students finish the course with the impression that Lisp is
> a playground language where one is required to perform mental acrobatics
> on lists with weird functions like cadadr and by forcing everything to be
> recursive. After that, they will not touch Lisp with a ten-foot pole.
>
> Common Lisp would be much better off if students weren't forced to touch
> Lisp until they were ready for it, and then learn it as a practical and
> powerful language at their own pace, and only if they want to.
>
> Tamas
amongst all this doom and gloom about lisp, i want to share a good news story
for years i assumed that my students were not good programmers and
taught grad data mining using the simplest tools i could find:
- dumb shell scripts
- data mining tools with pretty interfaces
then, just as an experiment, i wrote a small data mining in LISP, gave
it to students and passed out a bunch of crazy ideas. "here's stuff no
one has every tried before. heh, you guys have never done data mining
or seen LISP before- have a go at it"
i've done this twice now and the response is the same. they _LOVE_
it. data mining newbies are building data miners that have never seen
before, running massive experiments, reporting on the relative merits
of X vs Y vs Z, etc etc.
why is this possible? has my student population suddenly doubled in
IQ? am i suddenly a doubly better teacher? i think not.
no. i think that LISP supports their wildest dreams. i gave them an
extendible tool kit and they extended it. and extended it. and
extended it.
just my $0.02 worth
tim menzies
--
Posted Via Newsfeeds.com Premium Usenet Newsgroup Service
----------------------------------------------------------
http://www.Newsfeeds.com
Timothy menzies wrote:
> On 2008-12-30, Tamas K Papp <······@gmail.com> wrote:
>
>>On Mon, 29 Dec 2008 19:19:02 -0500, Steven E. Harris wrote:
>>
>>Some universities still use Lisp in intro courses, but only to
>>demonstrate nice theoretical points and such things. Modern language
>>features (like CLOS, arrays, hash tables etc) and macros are mostly
>>ignored, and students finish the course with the impression that Lisp is
>>a playground language where one is required to perform mental acrobatics
>>on lists with weird functions like cadadr and by forcing everything to be
>>recursive. After that, they will not touch Lisp with a ten-foot pole.
>>
>>Common Lisp would be much better off if students weren't forced to touch
>>Lisp until they were ready for it, and then learn it as a practical and
>>powerful language at their own pace, and only if they want to.
>>
>>Tamas
>
>
> amongst all this doom and gloom about lisp, i want to share a good news story
>
> for years i assumed that my students were not good programmers and
> taught grad data mining using the simplest tools i could find:
>
> - dumb shell scripts
>
> - data mining tools with pretty interfaces
>
> then, just as an experiment, i wrote a small data mining in LISP, gave
> it to students and passed out a bunch of crazy ideas. "here's stuff no
> one has every tried before. heh, you guys have never done data mining
> or seen LISP before- have a go at it"
>
> i've done this twice now and the response is the same. they _LOVE_
> it. data mining newbies are building data miners that have never seen
> before, running massive experiments, reporting on the relative merits
> of X vs Y vs Z, etc etc.
>
> why is this possible? has my student population suddenly doubled in
> IQ? am i suddenly a doubly better teacher? i think not.
>
> no. i think that LISP supports their wildest dreams. i gave them an
> extendible tool kit and they extended it. and extended it. and
> extended it.
Indeed. I believe Mr. Papas must be hanging out as well in comp.lang.c++
and has gotten the two languages confused.
Oh, look. I type in any random form and see what it does. Today's
generation is all about instant gratification, Lisp does that. So do
languages like Python and Ruby, but look! The syntax is
so...non-existent. Operator, operands, got it. Let's see what operators
we have...holy crap! The index is bigger than some entire languages!!
We're rich!
Mind you, the single most important factor in the classroom is the
teacher. You gave them a running start with some neato code that
probably leveraged recursion or first-class functions or loop or
something while Mr. Papas wants to teach them cadar. Hmmm....
kth
Timothy menzies <·····@vermouth.dreamhost.com> writes:
> amongst all this doom and gloom about lisp, i want to share a good news story
>
> for years i assumed that my students were not good programmers and
> taught grad data mining using the simplest tools i could find:
>
> - dumb shell scripts
>
> - data mining tools with pretty interfaces
>
> then, just as an experiment, i wrote a small data mining in LISP, gave
> it to students and passed out a bunch of crazy ideas. "here's stuff no
> one has every tried before. heh, you guys have never done data mining
> or seen LISP before- have a go at it"
>
> i've done this twice now and the response is the same. they _LOVE_
> it. data mining newbies are building data miners that have never seen
> before, running massive experiments, reporting on the relative merits
> of X vs Y vs Z, etc etc.
>
> why is this possible? has my student population suddenly doubled in
> IQ? am i suddenly a doubly better teacher? i think not.
>
> no. i think that LISP supports their wildest dreams. i gave them an
> extendible tool kit and they extended it. and extended it. and
> extended it.
One of my CS teacher used to tell us that the most important thing to
become a good programer was to have some problem to solve.
It's not a problem specific to CS, but most students are there not
because they're keen on solving some problem programming, but because
they weren't interested in the other matters and they heard some money
could be made with computers.
So once you've got student interested in solving some problem, of
course giving them a tool to do so, they'll gladly learn to use and
exploit it.
--
__Pascal Bourguignon__
P� Sun, 28 Dec 2008 15:43:16 +0100, skrev Steven E. Harris <···@panix.com>:
> WalterGR <········@gmail.com> writes:
>
>> Am I mistaken that Emacs + SLIME is the de facto standard Lisp
>> development environment?
>
> Probably not. I use it, and I've recommended that other people try
> it. In case Kenny chimes in, I have tried both Allegro CL's and
> Lispwork's IDEs and, while each did have a few nice things, I spent too
> much effort trying to get each to behave more like SLIME. Had I started
> out differently, though, those other IDEs would have seemed more
> natural.
>
Under LispWorks if you dowload Edi Weitz Lisp Starter Pack it adds
somethig called the Lisp Works addons that give you the most usefull bits
of SLIME functionality that are missing. Personally I can't even use LW
without it anymore.
--------------
John Thingstad
On 2008-12-28 19:40:24 -0500, "John Thingstad" <·······@online.no> said:
> Under LispWorks if you dowload Edi Weitz Lisp Starter Pack it adds
> somethig called the Lisp Works addons that give you the most usefull
> bits of SLIME functionality that are missing. Personally I can't even
> use LW without it anymore.
Seconded
--
Raffael Cavallaro, Ph.D.
John Thingstad <·······@online.no> writes:
> Under LispWorks if you dowload Edi Weitz Lisp Starter Pack it adds
> somethig called the Lisp Works addons that give you the most usefull
> bits of SLIME functionality that are missing.
Yes, I did that about a year and a half ago when I was last evaluating
LispWorks. It did finally make the IDE feel natural, by which I mean, it
mimicked SLIME.
Using my "stay at home" metaphor, using the Starter Pack is like staying
at a friend's house, but rearranging all the furnishings to match the
layout at home.
--
Steven E. Harris
On Dec 27, 12:29 am, alien_guy <····@l.org> wrote:
> good heavens! if this is the "biggest thing that would improve Lisp's
> popularity" then I'd rather CL remain unpopular as it is.
> why is it that noobs want to advertise such primitive tools as ABLE or
> CUSP/Eclipse ?
Scanning my inbox I have many emails from people who've contacted me
to say that they now program in Lisp because of ABLE. Is it not a good
thing that these people now program Lisp rather than just picking up
Python or Ruby? They had the curiosity to look a little beyond the
obvious choices...is it not a good idea to help them on their way?
So I'm curious as to why it would be better for Lisp to remain
unpopular than to provide tools that make it easier for new
programmers to start using the language. If you believe ABLE is
harming Lisp, as you seem to imply, then perhaps I should take the
site down?
Phil
On Fri, 26 Dec 2008 17:05:27 -0800, philip.armitage wrote:
> On Dec 27, 12:29 am, alien_guy <····@l.org> wrote:
>> good heavens! if this is the "biggest thing that would improve Lisp's
>> popularity" then I'd rather CL remain unpopular as it is. why is it
>> that noobs want to advertise such primitive tools as ABLE or
>> CUSP/Eclipse ?
>
> Scanning my inbox I have many emails from people who've contacted me to
> say that they now program in Lisp because of ABLE. Is it not a good
> thing that these people now program Lisp rather than just picking up
> Python or Ruby? They had the curiosity to look a little beyond the
> obvious choices...is it not a good idea to help them on their way?
Nothing is wrong with that, even though you have no counterfactual -- how
do you know that these people wouldn't have learned Lisp if they didn't
encounter ABLE?
> So I'm curious as to why it would be better for Lisp to remain unpopular
> than to provide tools that make it easier for new programmers to start
> using the language. If you believe ABLE is harming Lisp, as you seem to
> imply, then perhaps I should take the site down?
ABLE might be helping Lisp, but the effect is minuscule. I am amazed
that some people on CLL are arguing about the supreme importance of
development environments when discussing Lisp's "popularity". It is like
arguing that the Karamazov Brothers is not popular because it is printed
in the wrong font. Give me a break. Even if Lisp had the best IDE ever
(whatever that means), it would not become popular with the crowd that is
thrilled by Perl.
Go on working on ABLE by all means, more choice is always beneficial.
But please do not delude yourself into thinking that having another
editor/environment would make Lisp spread like wildfire.
Tamas
On Dec 27, 2:23 am, Tamas K Papp <······@gmail.com> wrote:
> On Fri, 26 Dec 2008 17:05:27 -0800, philip.armitage wrote:
> > On Dec 27, 12:29 am, alien_guy <····@l.org> wrote:
> >> good heavens! if this is the "biggest thing that would improve Lisp's
> >> popularity" then I'd rather CL remain unpopular as it is. why is it
> >> that noobs want to advertise such primitive tools as ABLE or
> >> CUSP/Eclipse ?
>
> > Scanning my inbox I have many emails from people who've contacted me to
> > say that they now program in Lisp because of ABLE. Is it not a good
> > thing that these people now program Lisp rather than just picking up
> > Python or Ruby? They had the curiosity to look a little beyond the
> > obvious choices...is it not a good idea to help them on their way?
>
> Nothing is wrong with that, even though you have no counterfactual -- how
> do you know that these people wouldn't have learned Lisp if they didn't
> encounter ABLE?
>
> > So I'm curious as to why it would be better for Lisp to remain unpopular
> > than to provide tools that make it easier for new programmers to start
> > using the language. If you believe ABLE is harming Lisp, as you seem to
> > imply, then perhaps I should take the site down?
>
> ABLE might be helping Lisp, but the effect is minuscule. I am amazed
> that some people on CLL are arguing about the supreme importance of
> development environments when discussing Lisp's "popularity". It is like
> arguing that the Karamazov Brothers is not popular because it is printed
> in the wrong font. Give me a break. Even if Lisp had the best IDE ever
> (whatever that means), it would not become popular with the crowd that is
> thrilled by Perl.
>
> Go on working on ABLE by all means, more choice is always beneficial.
> But please do not delude yourself into thinking that having another
> editor/environment would make Lisp spread like wildfire.
I don't think the choice is black or white. Having a better IDE than
Emacs+SLIME+CL
would help some users. Note that these things are all very
'subjective'. People
have different needs. For a group of people Emacs+SLIME+CL is fine.
But for me it is not. Much too complex for the task at hand. I would
want a much simpler tool. Even though I use Emacs (and related)
for a long time, I tend to avoid SLIME+Emacs. It is really a
very capable tool and better than most editors for many tasks.
But the user interface is a nightmare (IMHO).
I would expect that many Lisp users like a simple, GUI-based IDE.
If developers build such IDEs and try to reach those users, it
is fine with me. There is some need for that. Clozure CL developers
collected in a short time more than $20k to pay
some developer improving the IDE. The commercial CL implementations
survive
in part because they have to offer something in the area of
IDEs.
> Tamas
On Dec 27, 8:44 am, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:
> On Dec 27, 2:23 am, Tamas K Papp <······@gmail.com> wrote:
>
>
>
> > On Fri, 26 Dec 2008 17:05:27 -0800, philip.armitage wrote:
> > > On Dec 27, 12:29 am, alien_guy <····@l.org> wrote:
> > >> good heavens! if this is the "biggest thing that would improve Lisp's
> > >> popularity" then I'd rather CL remain unpopular as it is. why is it
> > >> that noobs want to advertise such primitive tools as ABLE or
> > >> CUSP/Eclipse ?
>
> > > Scanning my inbox I have many emails from people who've contacted me to
> > > say that they now program in Lisp because of ABLE. Is it not a good
> > > thing that these people now program Lisp rather than just picking up
> > > Python or Ruby? They had the curiosity to look a little beyond the
> > > obvious choices...is it not a good idea to help them on their way?
>
> > Nothing is wrong with that, even though you have no counterfactual -- how
> > do you know that these people wouldn't have learned Lisp if they didn't
> > encounter ABLE?
>
> > > So I'm curious as to why it would be better for Lisp to remain unpopular
> > > than to provide tools that make it easier for new programmers to start
> > > using the language. If you believe ABLE is harming Lisp, as you seem to
> > > imply, then perhaps I should take the site down?
>
> > ABLE might be helping Lisp, but the effect is minuscule. I am amazed
> > that some people on CLL are arguing about the supreme importance of
> > development environments when discussing Lisp's "popularity". It is like
> > arguing that the Karamazov Brothers is not popular because it is printed
> > in the wrong font. Give me a break. Even if Lisp had the best IDE ever
> > (whatever that means), it would not become popular with the crowd that is
> > thrilled by Perl.
>
> > Go on working on ABLE by all means, more choice is always beneficial.
> > But please do not delude yourself into thinking that having another
> > editor/environment would make Lisp spread like wildfire.
>
> I don't think the choice is black or white. Having a better IDE than
> Emacs+SLIME+CL
> would help some users. Note that these things are all very
> 'subjective'. People
> have different needs. For a group of people Emacs+SLIME+CL is fine.
> But for me it is not. Much too complex for the task at hand. I would
> want a much simpler tool. Even though I use Emacs (and related)
> for a long time, I tend to avoid SLIME+Emacs. It is really a
> very capable tool and better than most editors for many tasks.
> But the user interface is a nightmare (IMHO).
>
> I would expect that many Lisp users like a simple, GUI-based IDE.
> If developers build such IDEs and try to reach those users, it
> is fine with me. There is some need for that. Clozure CL developers
> collected in a short time more than $20k to pay
> some developer improving the IDE. The commercial CL implementations
> survive
> in part because they have to offer something in the area of
> IDEs.
>
> > Tamas
The DrScheme environment might fit the purpose.
Jurgen
On Dec 27, 1:23 am, Tamas K Papp <······@gmail.com> wrote:
> Go on working on ABLE by all means, more choice is always beneficial.
> But please do not delude yourself into thinking that having another
> editor/environment would make Lisp spread like wildfire.
I code in Lisp because it's the most pleasant language I've found to
use. I wrote my own editor because when I first came to the language I
didn't find an environment that I liked and I wanted something to work
on so it made sense. Making it available to others was an
afterthought, not some attempt at popularity.
But when someone criticises my work in a public forum, I am allowed to
defend it without being accused of "deluding myself".
Phil
On 27 Dez., 14:19, ···············@gmail.com wrote:
> On Dec 27, 1:23 am, Tamas K Papp <······@gmail.com> wrote:
>
> > Go on working on ABLE by all means, more choice is always beneficial.
> > But please do not delude yourself into thinking that having another
> > editor/environment would make Lisp spread like wildfire.
>
> I code in Lisp because it's the most pleasant language I've found to
> use. I wrote my own editor because when I first came to the language I
> didn't find an environment that I liked and I wanted something to work
> on so it made sense. Making it available to others was an
> afterthought, not some attempt at popularity.
>
> But when someone criticises my work in a public forum, I am allowed to
> defend it without being accused of "deluding myself".
>
> Phil
He, writing software, publishing it and maintaining/expanding a user
base is nothing
bad. More power to you.
On Sat, 27 Dec 2008 05:19:41 -0800, philip.armitage wrote:
> On Dec 27, 1:23 am, Tamas K Papp <······@gmail.com> wrote:
>> Go on working on ABLE by all means, more choice is always beneficial.
>> But please do not delude yourself into thinking that having another
>> editor/environment would make Lisp spread like wildfire.
>
> I code in Lisp because it's the most pleasant language I've found to
> use. I wrote my own editor because when I first came to the language I
> didn't find an environment that I liked and I wanted something to work
> on so it made sense. Making it available to others was an afterthought,
> not some attempt at popularity.
>
> But when someone criticises my work in a public forum, I am allowed to
> defend it without being accused of "deluding myself".
I am not accusing you of anything. I appreciate that you write software
and make it public.
My point was that I don't think that the (perceived) lack of IDEs is what
keeps Lisp from being popular.
Tamas
On 27 Dez., 14:48, Tamas K Papp <······@gmail.com> wrote:
> On Sat, 27 Dec 2008 05:19:41 -0800, philip.armitage wrote:
> > On Dec 27, 1:23 am, Tamas K Papp <······@gmail.com> wrote:
> >> Go on working on ABLE by all means, more choice is always beneficial.
> >> But please do not delude yourself into thinking that having another
> >> editor/environment would make Lisp spread like wildfire.
>
> > I code in Lisp because it's the most pleasant language I've found to
> > use. I wrote my own editor because when I first came to the language I
> > didn't find an environment that I liked and I wanted something to work
> > on so it made sense. Making it available to others was an afterthought,
> > not some attempt at popularity.
>
> > But when someone criticises my work in a public forum, I am allowed to
> > defend it without being accused of "deluding myself".
>
> I am not accusing you of anything. I appreciate that you write software
> and make it public.
>
> My point was that I don't think that the (perceived) lack of IDEs is what
> keeps Lisp from being popular.
>
> Tamas
I think that a better IDE would help a lot. Currently Common Lisp has
no
really good free native (!) IDE. Imagine Eclipse or Netbeans written
in Lisp.
But better. I really think that would help software developers a lot.
It would also have effects like a mature, cross platform GUI lib or
an environment for developing desktop apps. For me this is a logical
next step to bring Lisp (back) to the desktop.
On Sat, 27 Dec 2008 06:08:16 -0800, ······@corporate-world.lisp.de wrote:
> I think that a better IDE would help a lot. Currently Common Lisp has no
> really good free native (!) IDE. Imagine Eclipse or Netbeans written in
> Lisp.
I am fully satisfied with Emacs, despite its warts. The biggest
advantage is that I can develop Lisp, C, and R code, write LaTeX
documents, edit text files and compose e-mail in the same single
program. Even if you gave me the best Lisp IDE, R IDE, C IDE, LaTeX-
specific editor and general text editor, I would still be disadvantaged
because now I would have to use 5 different programs.
That said, I realize that people have different tastes and some don't
like Emacs, so if they have the time, resources and willingness, sure,
go ahead and write a native Lisp IDE. But realistically, I think that
writing programs like that is a complex and non-rewarding task which
requires attention to minute details. People get started on such
projects, but they fail to gain momentum. Emacs is far from ideal,
but it is "good enough" so that many people don't want to waste time
on writing IDEs.
Tamas
From: Stanisław Halik
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <gjae9f$1bk0$3@opal.icpnet.pl>
thus spoke ······@corporate-world.lisp.de <······@corporate-world.lisp.de>:
> I think that a better IDE would help a lot. Currently Common Lisp has
> no really good free native (!) IDE. Imagine Eclipse or Netbeans
> written in Lisp.
Climacs shows some promise :-) Perhaps with time it's going to grow some
IDE-ish features.
> next step to bring Lisp (back) to the desktop.
Threading on win32 seems to be unpossible. The best-case scenario seems
to be sbcl's win32 port reaching stable status.
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
On 29 Dez., 13:02, Stanis³aw Halik <··············@tehran.lain.pl>
wrote:
> thus spoke ······@corporate-world.lisp.de <······@corporate-world.lisp.de>:
>
> > I think that a better IDE would help a lot. Currently Common Lisp has
> > no really good free native (!) IDE. Imagine Eclipse or Netbeans
> > written in Lisp.
>
> Climacs shows some promise :-) Perhaps with time it's going to grow some
> IDE-ish features.
There is already CLIM-Desktop:
http://www.cliki.net/clim-desktop
Developers welcome!
>
> > next step to bring Lisp (back) to the desktop.
>
> Threading on win32 seems to be unpossible. The best-case scenario seems
> to be sbcl's win32 port reaching stable status.
Clozure CL on Windows could also be cool. The port is in the works.
>
> --
> You only have power over people so long as you don't take everything
> away from them. But when you've robbed a man of everything he's no longer
> in your power -- he's free again. -- Aleksandr Isayevich Solzhenitsyn
······@corporate-world.lisp.de wrote:
> I think that a better IDE would help a lot. Currently Common Lisp has
> no
> really good free native (!) IDE. Imagine Eclipse or Netbeans written
> in Lisp.
> But better. I really think that would help software developers a lot.
> It would also have effects like a mature, cross platform GUI lib or
> an environment for developing desktop apps. For me this is a logical
> next step to bring Lisp (back) to the desktop.
I agree entirely except I think you should aspire to build something much
better than Eclipse (which sucks donkey brains through a straw) and I think
the fragmented open source language communities will never be able to build
the solid foundation required for such a project without collaborating
which, in turn, really requires a common language run-time.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> ······@corporate-world.lisp.de wrote:
>> I think that a better IDE would help a lot. Currently Common Lisp has
>> no
>> really good free native (!) IDE. Imagine Eclipse or Netbeans written
>> in Lisp.
>> But better. I really think that would help software developers a lot.
>> It would also have effects like a mature, cross platform GUI lib or
>> an environment for developing desktop apps.
Hey, I am the AllegroCL shill around here.
>
> I agree entirely except I think you should aspire to build something much
> better than Eclipse (which sucks donkey brains through a straw)
Yes, Eclipse and NetBeans and Aptana are horrifying.
> and I think
> the fragmented open source language communities will never be able to build
> the solid foundation required for such a project without collaborating
> which, in turn, really requires a common language run-time.
>
Possibly the clumsiest segue ever attempted. Guinness has been alerted.
kenneth
On Fri, 26 Dec 2008 15:39:23 -0800, WalterGR wrote:
> Combining marketing with reducing the barrier to entry: the single
> biggest thing that would improve Lisp's popularity would be making the
> Able home
I still haven't seen a convincing argument on _why_ people should be
wasting their time on improving Lisp's "popularity". Why is it an end in
itself? For example, mathematics courses are not popular among
undergrads even at the better universities. Does that make them less
useful? Would mathematicians and scientist gain anything by making
partial differential equations more "popular"?
Also, the problems you mention with Lisp are superficial. "No easy
download"? You can download and install a working CL implementation with
minimal effort, especially compared to the effort of learning the
language. I don't see this as the effective barrier to entry, people who
can't jump this hurdle shouldn't be programming computers anyhow. Again,
compare with mathematics: for most math subjects, there is no "easy
download" Idiot's Guide textbook with cartoons you can drool onto.
People still learn them simply because they are useful. Those who need
some area of mathematics will find it, despite the fact that none of them
have mascots.
Tamas
On Dec 26, 5:11 pm, Tamas K Papp <······@gmail.com> wrote:
> On Fri, 26 Dec 2008 15:39:23 -0800, WalterGR wrote:
> > Combining marketing with reducing the barrier to entry: the single
> > biggest thing that would improve Lisp's popularity would be making the
> > Able home
>
> I still haven't seen a convincing argument on _why_ people should be
> wasting their time on improving Lisp's "popularity". Why is it an end in
> itself?
It's _not_ an end in itself. Do people *really* argue that? Has no
one *ever* presented an argument for why Lisp's popularity will be
beneficial? Wow. Prepare to have your mind blown:
If Lisp is more popular, then there will be more jobs available
programming in Lisp.
If Lisp is more popular, then my shared web hosting provider will
support it better.
If Lisp is more popular, more libraries will be written in Lisp.
If Lisp is more popular, more bugs in those libraries will get fixed.
I could go on.
I'm not going to respond to your mathematics metaphor, because I have
no personal reasons why I want math to be more popular.
> Also, the problems you mention with Lisp are superficial. "No easy
> download"? You can download and install a working CL implementation with
> minimal effort, especially compared to the effort of learning the
> language.
The "No easy download" reference was about why Lisp's marketing sucks.
> I don't see this as the effective barrier to entry, people who
> can't jump this hurdle shouldn't be programming computers anyhow.
Why are you making straw-man arguments? You know full well that for
serious Lisp development you don't just download an arbitrary Lisp
implementation, code in Notepad and copy-and-paste into the REPL.
You write later:
> I am amazed that some people on CLL are arguing about the supreme
> importance of development environments when discussing Lisp's
> "popularity".
Who said that? I sure didn't.
> It is like arguing that the Karamazov Brothers is
> not popular because it is printed in the wrong font.
To do serious Lisp development (at least with free implementations)
you need to download _an_ Emacs, _a_ Lisp implementation, install
SLIME, learn the foreign Emacs key bindings, discover that all the
Lisp videos you've been watching are actually using a configuration
you don't have, spend time Googling to discover newline-and-indent and
everything else you need... Yes, it's *exactly* like not liking the
font of a book.
Walter
On Fri, 26 Dec 2008 18:42:59 -0800, WalterGR wrote:
> On Dec 26, 5:11 pm, Tamas K Papp <······@gmail.com> wrote:
>> On Fri, 26 Dec 2008 15:39:23 -0800, WalterGR wrote:
>> > Combining marketing with reducing the barrier to entry: the single
>> > biggest thing that would improve Lisp's popularity would be making
>> > the Able home
>>
>> I still haven't seen a convincing argument on _why_ people should be
>> wasting their time on improving Lisp's "popularity". Why is it an end
>> in itself?
>
> It's _not_ an end in itself. Do people *really* argue that? Has no one
> *ever* presented an argument for why Lisp's popularity will be
> beneficial? Wow. Prepare to have your mind blown:
Sorry, mind still in place.
> If Lisp is more popular, then there will be more jobs available
> programming in Lisp.
> [...]
You seem to forget that all optimization problems should reflect the
costs, not only the benefits. All your arguments apply equally well
to the lollipop industry (if lollipops were more popular, there would
be more jobs in lollipop manufacturing, etc). So what? Without the
costs, such enumerations of benefits are meaningless. I understand
that those things would be good for you, but then you have to go ahead
and bear the costs of implementing the change.
>> I don't see this as the effective barrier to entry, people who can't
>> jump this hurdle shouldn't be programming computers anyhow.
>
> Why are you making straw-man arguments? You know full well that for
> serious Lisp development you don't just download an arbitrary Lisp
> implementation, code in Notepad and copy-and-paste into the REPL.
It is you who is making a straw-man argument; I never said anything
about Notepad etc.
> To do serious Lisp development (at least with free implementations) you
> need to download _an_ Emacs, _a_ Lisp implementation, install SLIME,
> learn the foreign Emacs key bindings, discover that all the Lisp videos
> you've been watching are actually using a configuration you don't have,
Gosh. I am amazed anyone manages to use Lisp after all. Let's see,
apt-get install slime sbcl emacs22-gtk, that takes <5 minutes, working
through the Emacs tutorial should take another 45 minutes at most,
then voila. Certainly a huge investment of your time.
And then I am sure people go and kill themselves when they discover
that Lisp videos used some other configuration. I can understand the
sentiment, if I see a screenshot when someone used different colors
for highlighting, I lock myself in my closet and cry for hours.
Ok, so you might not have Linux. Then you can download one of the
commercial Lisps, they have reasonable IDEs. After you decide you
like the language but hate the limitations of the free versions of
commercial implementations, you can install Emacs+SLIME+Clisp/SBCL on
your Windows machine. I am perfectly OK with people devoting their
time to making this process easier if they feel like doing it, nice
effort, good luck.
But whining that Lisp is not popular because of IDEs is a joke. Lisp
is not "popular" because it is Lisp: it requires mental effort to
learn, and the majority of people hate to exert themselves either
mentally or physically, programmers no exception. There are
programmers who genuinely and honestly like Object Pascal, for
example, and no amount of effort will make them appreciate Lisp. Move
on.
Tamas
On Dec 26, 7:17 pm, Tamas K Papp <······@gmail.com> wrote:
> You seem to forget that all optimization problems should reflect the
> costs, not only the benefits.
Where did I forget this?
> All your arguments apply equally well
> to the lollipop industry (if lollipops were more popular, there would
> be more jobs in lollipop manufacturing, etc). So what?
It seemed you were without reasons for why Lisp's increased popularity
would be beneficial. I provided you some.
> I understand
> that those things would be good for you, but then you have to go ahead
> and bear the costs of implementing the change.
I never said there'd be no costs, nor did I say I'd not bear such
costs.
> But whining that Lisp is not popular because of IDEs is a joke.
I never whined. I never even said that Lisp should be more popular!
I merely outlined why Lisp isn't more popular.
> I am perfectly OK with people devoting their time to making this process
> easier if they feel like doing it, nice effort, good luck.
Great! That's all you needed to say.
Walter
WalterGR <········@gmail.com> wrote:
+---------------
| To do serious Lisp development (at least with free implementations)
| you need to download _an_ Emacs, _a_ Lisp implementation, install
| SLIME, learn the foreign Emacs key bindings, discover that all the
| Lisp videos you've been watching are actually using a configuration
| you don't have, spend time Googling to discover newline-and-indent and
| everything else you need...
+---------------
I was *almost* with you until this bit of silliness. No, sorry,
you *DON'T* need all of that stuff to do "serious Lisp development".
All you need is an implementation that works on the platform(s)
you care about [CMUCL, for me, for FreeBSD & Linux], an editor
with just a *few* basic Lisp-friendly feaures[1], and a desire
to actually *code* something rather than bitch about lack of
perfect tools.
-Rob
[1] Namely:
1. Simple auto-indentation to the same level as the previous line;
2. The ability to shift groups of lines back & forth;
3. Parentheses-matching, that is, will blink or otherwise show
you the matching open parenthesis when you type a closing one.
For reasons detailed several times here previously, I don't use
happen to use Emacs/SLIME. But most versions of "Vi" or "Vim"
have the above three minimal features, and that's what I've been
using *quite* successfuly to code & deliver Scheme & Lisp applications
for the last 16+ years. Others' mileage may vary, but still...
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Dec 27, 2:49 am, ····@rpw3.org (Rob Warnock) wrote:
> WalterGR <········@gmail.com> wrote:
>
> +---------------
> | To do serious Lisp development (at least with free implementations)
> | you need to download _an_ Emacs, _a_ Lisp implementation, install
> | SLIME, learn the foreign Emacs key bindings, discover that all the
> | Lisp videos you've been watching are actually using a configuration
> | you don't have, spend time Googling to discover newline-and-indent and
> | everything else you need...
> +---------------
>
> I was *almost* with you until this bit of silliness. No, sorry,
> you *DON'T* need all of that stuff to do "serious Lisp development".
> All you need is an implementation that works on the platform(s)
> you care about [CMUCL, for me, for FreeBSD & Linux], an editor
> with just a *few* basic Lisp-friendly feaures[1]
I'm glad that works for you. I prefer a development environment
that's a little more robust - auto-indentation, auto-completion, go-to-
definition, hooks into the Hyperspec, etc.
> Others' mileage may vary, but still...
Yup.
> ...and a desire to actually *code* something rather than bitch
> about lack of perfect tools.
You don't know a thing about me, nor my desires, nor how much code
I've written. I've been describing my thoughts about why Lisp isn't
more popular. As I said to Alien Guy, Tamas, and Steven: unless you
do me the courtesy of carefully reading my posts I will not reply
further to yours.
Walter
WalterGR wrote:
> On Dec 27, 2:49 am, ····@rpw3.org (Rob Warnock) wrote:
>> WalterGR <········@gmail.com> wrote:
>>
>> +---------------
>> | To do serious Lisp development (at least with free implementations)
>> | you need to download _an_ Emacs, _a_ Lisp implementation, install
>> | SLIME, learn the foreign Emacs key bindings, discover that all the
>> | Lisp videos you've been watching are actually using a configuration
>> | you don't have, spend time Googling to discover newline-and-indent and
>> | everything else you need...
>> +---------------
>>
>> I was *almost* with you until this bit of silliness. No, sorry,
>> you *DON'T* need all of that stuff to do "serious Lisp development".
>> All you need is an implementation that works on the platform(s)
>> you care about [CMUCL, for me, for FreeBSD & Linux], an editor
>> with just a *few* basic Lisp-friendly feaures[1]
>
> I'm glad that works for you. I prefer a development environment
> that's a little more robust - auto-indentation, auto-completion, go-to-
> definition, hooks into the Hyperspec, etc.
If you had originally said "*I* prefer a development environment
that's a little more robust" etc., there would be no argument.
I believe Rob was objecting about your *general* statement of "To
do serious Lisp development you need to download _an_ Emacs" etc.
as your experience can not be generalized to all developers.
>> ...and a desire to actually *code* something rather than bitch
>> about lack of perfect tools.
>
> You don't know a thing about me, nor my desires, nor how much code
> I've written. I've been describing my thoughts about why Lisp isn't
> more popular. As I said to Alien Guy, Tamas, and Steven: unless you
> do me the courtesy of carefully reading my posts I will not reply
> further to yours.
Why do you think he is talking about *you*? The way I read what
he said was that a desire to actually code something (& the other
things he mentioned) are much more important for "serious Lisp
development" than the quality of tools. I actually disagree with
Rob on two points. 1) I suspect he *does* want (and perhaps attains)
a perfect development environment but his idea of what that is,
is very different from yours! Perhaps the only thing we can agree
on is that a perfect development environment is one that allows
one to write code most efficiently most of the time. 2) Desire is
not sufficient. It has never written one damn line of code for me!
It is like the difference between hunger and eating.
To bring this back to your original question: write lots of working
code that does things people want! That'd do lot more to popularize
your language of choice than all this philosophizing. So Carpe Diem!
Or Carpe da-keyboard!!
On Dec 27, 1:41 pm, Bakul Shah <············@bitblocks.com> wrote:
> Why do you think he is talking about *you*? The way I read what
> he said was that a desire to actually code something (& the other
> things he mentioned) are much more important for "serious Lisp
> development" than the quality of tools.
Ah. My apologies to Rob if that's the case.
Walter
> On Dec 26, 5:11 pm, Tamas K Papp <······@gmail.com> wrote:
>>I still haven't seen a convincing argument on _why_ people should be
>>wasting their time on improving Lisp's "popularity". Why is it an end in
>>itself?
Do you think Lisp more effective for software development?
Mate in two.
kenneth
Tamas K Papp wrote:
> On Fri, 26 Dec 2008 15:39:23 -0800, WalterGR wrote:
>
>> Combining marketing with reducing the barrier to entry: the single
>> biggest thing that would improve Lisp's popularity would be making the
>> Able home
>
> I still haven't seen a convincing argument on _why_ people should be
> wasting their time on improving Lisp's "popularity".
People are not wasting their time. They just do what they believe is
useful to them and others, or what they just enjoy. Like everybody else.
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/
We should make more promotion for HtDP!
Jurgen
Wade wrote:
> IMHO...
>
> Lisp is not popular because of the s-exp syntax. Many people
> are thrown right away when looking at it. But without the s-exp
> syntax its not Lisp. But its the s-exp syntax that attracted
> me to learn Lisp.
>
> Its not the libraries (lack or not lack), it has absolutely
> nothing to do with that.
>
> Programming languages are not popular in general. Non-programmers
> do not like any programs. Programmers do not like other programmers
> programs. Many people do not even like the programs they write
> themselves. Its just what it is.
>
> Learn to be unpopular, it is freeing.
>
> Wade
On Dec 23, 6:08 am, MishoM <···············@gmail.com> wrote:
> Hi,
>
> I'm really new to Lisp. I had heard of it before and got the
> impression of a dead language with an exotic syntax and no real use.
> My opinion was changed by Paul Graham's article <a href = "http://www.paulgraham.com/avg.html">Beating the averages</a>.
>
> I started investigating and in the last weeks I've been watching the
> videos of "Structure and Interpretation of Computer Programs" and I'm
> reading "Practical Common Lisp". I liked a lot what I heard and read
> and tried to tell my friends and colleagues about it, but the reaction
> was like I'm going nuts, even though I made it clear that I intend to
> learn more and try to implement a nontrivial program in Common Lisp
> before forming my final opinion. The most frequent argument I heard
> was: "If Lisp was that good, it would be much more popular".
>
> So I started asking myself why isn't Lisp popular. Is it because of
> it's syntax? Is it because of the prejudice that it is slow? Or some
> other reason? I searched the Internet a little and saw that other
> people had asked themselves the same question. A discussion on
> Lispcast titled <a href = "http://www.lispcast.com/drupal/node/29">No
> easy download</a> caught my attention along with another article by
> Paul Graham - <a href = "http://www.paulgraham.com/popular.html">Being
> Popular</a>.
>
> So I formed my own opinion on why Lisp isn't popular and summarized it
> in the following two points:
>
> 1. There are not enough libraries in Lisp. Even worse, most of the
> existing libraries are not standard. The fastest way to implement
> something is to have it already implemented for you.
>
> 2. Most people don't see the advantages of Lisp over their programming
> language even for tasks for which Lisp is really much more suitable,
> because they don't know what can be done easily in Lisp.
>
> And then I asked myself if there are circumstances which would help
> Lisp get back on center stage. What I'm certain of is two things.
> First, as time goes by, more and more features of Lisp will get
> introduced to other languages and its will become harder to convince
> people to make the transition. And second, trying to get people to
> learn Lisp so they would appreciate it won't work. They should be
> convinced of the use to learn it before they agree to do it. And so I
> got to this crazy idea which I want to share. If I'm being stupid
> please bear with me.
>
> The best way to convince people to learn Lisp is by convincing them to
> use it first and then use that to show them its advantages. I don't
> know about Scheme, but the FFI of Common Lisp seems to be good enough
> to allow for other languages to use libraries written in Lisp. So if
> there are powerful libraries written in Lisp which can be used from C+
> +, Java, C#, Perl, Python, Ruby, etc, people will use them. Several
> widely used popular libraries in Lisp, especially for tasks which are
> outside the traditional Lisp domain, can really make a difference in
> the attitude towards the language.
>
> The other thing which is mandatory is to make rich libraries for Lisp
> which are readily available, comprehensive, free and standard. The
> best way to do this is by creating the prerequisites for the emergence
> of libraries which are de facto standard, like what boost is for C++.
> Instead of almost 10 libraries for GUI of which people don't know
> which to choose, there should be no more than three and it should be
> immediately clear what's the use of each of them.
>
> And the third thing which could really boost things up is some way to
> make both kinds of libraries very public so that non-lispers could
> become aware that:
>
> 1. They can benefit from Lisp without learning it through powerful
> libraries written in Lisp.
> 2. There will benefit from investing in learning Lisp, because there
> are a lot of solutions readily available.
>
> And here comes my crazy idea. All of this can be achieved through a
> web site targeted at developers in all programming languages. This
> site should be the best programming libraries directory on the
> internet, hosting libraries in any programming language. Its main goal
> should be to hold as many libraries as possible and provide powerful
> search, ranking and comparison features. Here are some of the features
> I have in mind:
>
> 1. Each library should have in its description separate fields for
> implementation language(s) and target language(s) unlike sourceforge
> which has only one language field. To the users of the library it
> matters much more what languages can use the library, but the
> implementation language is important too.
>
> 2. The "supported feature" fields of the libraries should have
> rankings associated with them so that users could rank the support for
> individual features separately.
>
> 3. The users should be able to add new library categories with custom
> feature fields.
>
> 4. The users should be able to sort the libraries according to their
> own ranking criteria like the <a href = "http://
> shootout.alioth.debian.org/gp4/index.php">Gentoo Benchmark<\a> or in
> some other way.
>
> 5. The users should be able to create comparison tables for two or
> more libraries, choosing which features to compare.
>
> I think that if such a site exists and contains all important
> libraries for the major programming languages it will attract enough
> attention to start the ball rolling and become the best programming
> libraries directory. Of course a site of this scale will require some
> serious funding but I believe this is a solvable problem.
>
> And with this site in place, it will be up to the Lisp community to
> start actively pursuing the interest of the other programmers. The key
> is to identify the most popular libraries and implement them in Common
> Lisp and Scheme. This will provide Lisp with the libraries that people
> want thus making it ultimately more useful. And if these libraries are
> more powerful than the original and are made available to other
> programming languages, they will have the potential to start to draw
> people towards Lisp.
>
> Of course there is a reduced version of this agenda, which is to use
> existing software project sites like Sourceforge and implement the
> most popular libraries there in Lisp and post them on Sourceforge. But
> existing project sites are not targeted at libraries specifically so
> they don't provide the tools to highlight the key features and compare
> them. Furthermore, a good libraries site for Lisp is needed anyway,
> and it will only gain if it allows libraries in other languages
> because it will draw the attention of non-lispers.
>
> Well that's it, I hope I didn't annoy anybody, and sorry for the
> really long post, but I wanted to share this idea and see what others
> think.
I can understand that people might say "If Lisp were that good, it
would be much more popular", but it's not well-reasoned. By nearly
any measure, C is one of the very most popular programming language.
Is that because it's "good"? ("Good" can mean many different things
in this context, too.)
The problem of libraries has been brought up many times, by everyone
from beginners to the most advanced Common Lisp developers. On one
hand, there are a lot more libraries around than most people know.
However, it's not easy enough to find the library you want. And, as
you say, sometimes there are many libraries that bear on the same
problem, and it's hard to know which is the most suitable for your
purpose. This is particularly a problem for web application
frameworks, since there are many fundamentally different approaches to
providing such a framework. It's also hard to know which works best.
ome aren't comprehensive enough, i.e. they're missing important
abilities or features. Some don't have very good documentation. Some
don't run on all the Common Lisp implementations or underlying
operating systems.
As is often the case with open-source libraries in any language, they
sometimes depend on other libraries, and you end up having to go on a
scavenger hunt to pull together the transitive set of dependent
libraries, being sure to get the right version of each one. Sometimes
they're all stored on different sites, not all of which area always
up.
I agree completely that more features of Lisp are appearing in other
popular languages, making it harder to persuade people that Lisp is a
good language to get invovled with. You used the future tense, but
it's actually been going on for many years already.
I disagree that one of the best ways to boost Lisp's popularity would
be to write libraries written in Lisp that can be used from other
languages. As far as someone using some other language is concerned,
a library is a black box; what language the library is written in is
not of primary importance.
I also don't think that the Lisp community should undertake to
construct a software repository for all the languages in the world.
Other languages alreadly have their own repositories. PERL developers
have CPAN, for example, and aren't looking for a replacement for it.
I do think it would be very valuable to create a repository for Lisp
libraries and other open-source software and documents. I'll be
writing more about this soon.
In the replies to your post, "Ali" said:
"Lispers generally don't care about popularity because they can
already do what they want already. At least a few see it as a waste of
time to have lots of newbs around."
There are some Lisp people who feel that way, but I think most of us
realize that we'd all benefit greatly if Lisp were more popular.
Those of us who like and appreciate developing in Lisp would like to
see more people writing and maintaining good libraries. We'd like
there to be more jobs available that use Lisp, and more companies
happy to develop new software in Lisp. We'd like to see more effort
put into improving and porting Lisp implementations, more Lisp
textbooks and other resources, and so on. This is all controlled by a
kind of positive feedback: more people will use Lisp if there are
better resources, and better resources will be created if there are
more Lisp users, etc.
For some useful information about the current Common Lisp
implementations, and pointers to libraries, tutorials, textbooks, user
groups, and all kinds of other resources, see
http://common-lisp.net/~dlw/LispSurvey.html
-- Dan Weinreb
On Dec 28 2008, 9:36 pm, Dan Weinreb <····@alum.mit.edu> wrote:
> On Dec 23, 6:08 am, MishoM <···············@gmail.com> wrote:
>
> > Hi,
>
> > I'm really new to Lisp. I had heard of it before and got the
> > impression of a dead language with an exotic syntax and no real use.
> > My opinion was changed by Paul Graham's article <a href = "http://www.paulgraham.com/avg.html">Beating the averages</a>.
>
> > I started investigating and in the last weeks I've been watching the
> > videos of "Structure and Interpretation of Computer Programs" and I'm
> > reading "Practical Common Lisp". I liked a lot what I heard and read
> > and tried to tell my friends and colleagues about it, but the reaction
> > was like I'm going nuts, even though I made it clear that I intend to
> > learn more and try to implement a nontrivial program in Common Lisp
> > before forming my final opinion. The most frequent argument I heard
> > was: "If Lisp was that good, it would be much more popular".
>
> > So I started asking myself why isn't Lisp popular. Is it because of
> > it's syntax? Is it because of the prejudice that it is slow? Or some
> > other reason? I searched the Internet a little and saw that other
> > people had asked themselves the same question. A discussion on
> > Lispcast titled <a href = "http://www.lispcast.com/drupal/node/29">No
> > easy download</a> caught my attention along with another article by
> > Paul Graham - <a href = "http://www.paulgraham.com/popular.html">Being
> > Popular</a>.
>
> > So I formed my own opinion on why Lisp isn't popular and summarized it
> > in the following two points:
>
> > 1. There are not enough libraries in Lisp. Even worse, most of the
> > existing libraries are not standard. The fastest way to implement
> > something is to have it already implemented for you.
>
> > 2. Most people don't see the advantages of Lisp over their programming
> > language even for tasks for which Lisp is really much more suitable,
> > because they don't know what can be done easily in Lisp.
>
> > And then I asked myself if there are circumstances which would help
> > Lisp get back on center stage. What I'm certain of is two things.
> > First, as time goes by, more and more features of Lisp will get
> > introduced to other languages and its will become harder to convince
> > people to make the transition. And second, trying to get people to
> > learn Lisp so they would appreciate it won't work. They should be
> > convinced of the use to learn it before they agree to do it. And so I
> > got to this crazy idea which I want to share. If I'm being stupid
> > please bear with me.
>
> > The best way to convince people to learn Lisp is by convincing them to
> > use it first and then use that to show them its advantages. I don't
> > know about Scheme, but the FFI of Common Lisp seems to be good enough
> > to allow for other languages to use libraries written in Lisp. So if
> > there are powerful libraries written in Lisp which can be used from C+
> > +, Java, C#, Perl, Python, Ruby, etc, people will use them. Several
> > widely used popular libraries in Lisp, especially for tasks which are
> > outside the traditional Lisp domain, can really make a difference in
> > the attitude towards the language.
>
> > The other thing which is mandatory is to make rich libraries for Lisp
> > which are readily available, comprehensive, free and standard. The
> > best way to do this is by creating the prerequisites for the emergence
> > of libraries which are de facto standard, like what boost is for C++.
> > Instead of almost 10 libraries for GUI of which people don't know
> > which to choose, there should be no more than three and it should be
> > immediately clear what's the use of each of them.
>
> > And the third thing which could really boost things up is some way to
> > make both kinds of libraries very public so that non-lispers could
> > become aware that:
>
> > 1. They can benefit from Lisp without learning it through powerful
> > libraries written in Lisp.
> > 2. There will benefit from investing in learning Lisp, because there
> > are a lot of solutions readily available.
>
> > And here comes my crazy idea. All of this can be achieved through a
> > web site targeted at developers in all programming languages. This
> > site should be the best programming libraries directory on the
> > internet, hosting libraries in any programming language. Its main goal
> > should be to hold as many libraries as possible and provide powerful
> > search, ranking and comparison features. Here are some of the features
> > I have in mind:
>
> > 1. Each library should have in its description separate fields for
> > implementation language(s) and target language(s) unlike sourceforge
> > which has only one language field. To the users of the library it
> > matters much more what languages can use the library, but the
> > implementation language is important too.
>
> > 2. The "supported feature" fields of the libraries should have
> > rankings associated with them so that users could rank the support for
> > individual features separately.
>
> > 3. The users should be able to add new library categories with custom
> > feature fields.
>
> > 4. The users should be able to sort the libraries according to their
> > own ranking criteria like the <a href = "http://
> > shootout.alioth.debian.org/gp4/index.php">Gentoo Benchmark<\a> or in
> > some other way.
>
> > 5. The users should be able to create comparison tables for two or
> > more libraries, choosing which features to compare.
>
> > I think that if such a site exists and contains all important
> > libraries for the major programming languages it will attract enough
> > attention to start the ball rolling and become the best programming
> > libraries directory. Of course a site of this scale will require some
> > serious funding but I believe this is a solvable problem.
>
> > And with this site in place, it will be up to the Lisp community to
> > start actively pursuing the interest of the other programmers. The key
> > is to identify the most popular libraries and implement them in Common
> > Lisp and Scheme. This will provide Lisp with the libraries that people
> > want thus making it ultimately more useful. And if these libraries are
> > more powerful than the original and are made available to other
> > programming languages, they will have the potential to start to draw
> > people towards Lisp.
>
> > Of course there is a reduced version of this agenda, which is to use
> > existing software project sites like Sourceforge and implement the
> > most popular libraries there in Lisp and post them on Sourceforge. But
> > existing project sites are not targeted at libraries specifically so
> > they don't provide the tools to highlight the key features and compare
> > them. Furthermore, a good libraries site for Lisp is needed anyway,
> > and it will only gain if it allows libraries in other languages
> > because it will draw the attention of non-lispers.
>
> > Well that's it, I hope I didn't annoy anybody, and sorry for the
> > really long post, but I wanted to share this idea and see what others
> > think.
>
> I can understand that people might say "If Lisp were that good, it
> would be much more popular", but it's not well-reasoned. By nearly
> any measure, C is one of the very most popular programming language.
> Is that because it's "good"? ("Good" can mean many different things
> in this context, too.)
>
> The problem of libraries has been brought up many times, by everyone
> from beginners to the most advanced Common Lisp developers. On one
> hand, there are a lot more libraries around than most people know.
>
> However, it's not easy enough to find the library you want. And, as
> you say, sometimes there are many libraries that bear on the same
> problem, and it's hard to know which is the most suitable for your
> purpose. This is particularly a problem for web application
> frameworks, since there are many fundamentally different approaches to
> providing such a framework. It's also hard to know which works best.
>
> ome aren't comprehensive enough, i.e. they're missing important
> abilities or features. Some don't have very good documentation. Some
> don't run on all the Common Lisp implementations or underlying
> operating systems.
>
> As is often the case with open-source libraries in any language, they
> sometimes depend on other libraries, and you end up having to go on a
> scavenger hunt to pull together the transitive set of dependent
> libraries, being sure to get the right version of each one. Sometimes
> they're all stored on different sites, not all of which area always
> up.
>
> I agree completely that more features of Lisp are appearing in other
> popular languages, making it harder to persuade people that Lisp is a
> good language to get invovled with. You used the future tense, but
> it's actually been going on for many years already.
>
> I disagree that one of the best ways to boost Lisp's popularity would
> be to write libraries written in Lisp that can be used from other
> languages. As far as someone using some other language is concerned,
> a library is a black box; what language the library is written in is
> not of primary importance.
>
> I also don't think that the Lisp community should undertake to
> construct a software repository for all the languages in the world.
> Other languages alreadly have their own repositories. PERL developers
> have CPAN, for example, and aren't looking for a replacement for it.
>
> I do think it would be very valuable to create a repository for Lisp
> libraries and other open-source software and documents. I'll be
> writing more about this soon.
>
> In the replies to your post, "Ali" said:
>
> "Lispers generally don't care about popularity because they can
> already do what they want already. At least a few see it as a waste of
> time to have lots of newbs around."
>
> There are some Lisp people who feel that way, but I think most of us
> realize that we'd all benefit greatly if Lisp were more popular.
> Those of us who like and appreciate developing in Lisp would like to
> see more people writing and maintaining good libraries. We'd like
> there to be more jobs available that use Lisp, and more companies
> happy to develop new software in Lisp. We'd like to see more effort
> put into improving and porting Lisp implementations, more Lisp
> textbooks and other resources, and so on. This is all controlled by a
> kind of positive feedback: more people will use Lisp if there are
> better resources, and better resources will be created if there are
> more Lisp users, etc.
>
> For some useful information about the current Common Lisp
> implementations, and pointers to libraries, tutorials, textbooks, user
> groups, and all kinds of other resources, see
>
> http://common-lisp.net/~dlw/LispSurvey.html
>
> -- Dan Weinreb
Thank you. When I started this discussion, I didn't expect it to turn
this way. I'm this way, I get fired up very quickly and when I have
some idea, I'm extremely likely to throw it at anyone and everyone :)
About the libraries thing, there are two aspects that I had in mind.
First, the ability to compare features of libraries would help
highlight the differences between languages and demonstrate the areas
for which they are suitable. Second, having separate fields for
implementation language and for the languages from which the language
can be used, would help programmers see opportunities to use libraries
implemented in languages different from theirs and would promote
"multi-language" development. Why did I see this as a way to
popularize Lisp? Most probably because of lack of knowledge.... I was
under the impression that with the FFI Lisp functions can be
integrated into other programs, and that would mean that if Lisp is
really as powerful as I thought, the libraries written in it would be
very powerful too and gain popularity. Though the developers that use
them would regard them as black boxes, the sheer fact that they would
use a Lisp library instead of one implemented in their own language
would draw their attention to the language itself. Again, my lack of
knowledge and excessive enthusiasm are probably the reason why I had
this idea at all.
On a side note, I've been keeping my learning, though I have very
little free time (a full time job, wife and little kid, and a long
delayed university education) and I hope that soon I will know enough
to start my first experiment in CL. It is a non-trivial desktop
application, and I don't want to start it before I have acquainted
myself with everything the language offers.
MishoM <···············@gmail.com> writes:
> About the libraries thing, there are two aspects that I had in mind.
> First, the ability to compare features of libraries would help
> highlight the differences between languages and demonstrate the areas
> for which they are suitable.
> Second, having separate fields for
> implementation language and for the languages from which the language
> can be used, would help programmers see opportunities to use libraries
> implemented in languages different from theirs and would promote
> "multi-language" development. Why did I see this as a way to
> popularize Lisp? Most probably because of lack of knowledge.... I was
> under the impression that with the FFI Lisp functions can be
> integrated into other programs, and that would mean that if Lisp is
> really as powerful as I thought, the libraries written in it would be
> very powerful too and gain popularity. Though the developers that use
> them would regard them as black boxes, the sheer fact that they would
> use a Lisp library instead of one implemented in their own language
> would draw their attention to the language itself. Again, my lack of
> knowledge and excessive enthusiasm are probably the reason why I had
> this idea at all.
Ok, I understand better what you mean. (At first, I thought you wanted
to implement libraries for lisp programmers).
You want to implement in lisp, libraries for C programmers.
You could do that with ECL.
But because of the "impedence mismatch", that is the problem of
converting data types, you would have to export most of the lisp
language anyways.
For example, if you wanted to export the simple split-sequence library
you would have to publish functions to build lisp lists, lisp strings
(not the same as C strings), lisp vectors (adjustable, fill-pointer,
various element types, etc), _closures_ (you need them as predicate,
etc). So you already export half of ECL, just for a simple library with
three functions such as split-sequence.
And if you want to publish something more complex, such as for example
the LISA or NARC libraries, you would have to export CLOS, that is about
100% of lisp.
I mean that programmers wanting to make use of these libraries would
have to manipulate from their awkward programming language lisp objects
using the lisp functions ecl exports.
An alternative would be to provide the service of translating the poorer
C data types into lisp data to be processed, but this would greatly
reduce the interest of the lisp library in general.
However, if you implement a library such as:
#ifndef STRONG_AI
#define STRONG_AI
void strongai_initialize(void);
const char* strongai_ask(const char* question);
void strongai_free(const char* answer);
void strongai_terminate(void);
#endif
that you could use as:
int main(void) {
strongai_initialize();
const char* answer=strongai_ask("What should I do to become millionaire overnight?");
printf("%s\n",answer);
strongai_free(answer);
strongai_terminate();
return(0);
}
then I guess it would be ok. The API is simple and C-like enough, and
the feature is worthwhile enough. (Well, if effectively I can become
millionaire overnight applying the given answer).
Serriously, even if it's not as performing as this example, in the
rare cases where the API is small and C-like, and the algorithms
implemented to easily ported to C, it may be worthwhile to provide the
lisp library to the foreign language programmers.
A first step would be classify the existing lisp libraries:
http://www.cliki.net/Library
--
__Pascal Bourguignon__
On 2008-12-23, MishoM <···············@gmail.com> wrote:
> Hi,
>
> I'm really new to Lisp. I had heard of it before and got the
> impression of a dead language with an exotic syntax and no real use.
The syntax of Lisp is completely ``unexotic'', consisting mostly of
very ordinary tokens and some parentheses.
Programmers like exotic syntaxes. The majority of programmers are mediocre, and
need some gimmick---such as exotic syntax---in order to bolster a self-image of
high intelligence.
> My opinion was changed by Paul Graham's article <a href = "http://
> www.paulgraham.com/avg.html">Beating the averages</a>.
>
> I started investigating and in the last weeks I've been watching the
> videos of "Structure and Interpretation of Computer Programs" and I'm
> reading "Practical Common Lisp". I liked a lot what I heard and read
> and tried to tell my friends and colleagues about it, but the reaction
> was like I'm going nuts, even though I made it clear that I intend to
> learn more and try to implement a nontrivial program in Common Lisp
> before forming my final opinion. The most frequent argument I heard
> was: "If Lisp was that good, it would be much more popular".
People know that it's a bullshit argument, but they're testing you by throwing
it in your face. How do you react to that?
> First, as time goes by, more and more features of Lisp will get
> introduced to other languages and its will become harder to convince
> people to make the transition.
Note that the obvious limit of this process is languages that have
/all/ the features of Lisp, including the homoiconic syntax and all.
The only problem is that reinventing the wheel is a waste.
Firstly, every new language that has all the features of Lisp will be
incompatible with every other such language. Much time will pass before
anything is standardized at the ISO level.
Their development will repeat the same mistakes, too. We didn't end up with
Common Lisp overnight, and it's not perfect. The history of Lisp is littered
with various experiments with various design decisions from among which the
better ones survived. This brewing process is why, for instance, we today don't
have FREXP's or NLAMBDA.
People working in Lisp ignorance may have to repeat some of the same
experiments, which is a costly process that takes years. To test an
experimental language feature, you have to implement it, and put it thorugh a
community of users who develop software. When that feature turns out to be a
bad idea, that entire language dialect dies.
Kaz Kylheku wrote:
> On 2008-12-23, MishoM <···············@gmail.com> wrote:
>> Hi,
>>
>> I'm really new to Lisp. I had heard of it before and got the
>> impression of a dead language with an exotic syntax and no real use.
>
> The syntax of Lisp is completely ``unexotic'', consisting mostly of
> very ordinary tokens and some parentheses.
>
> Programmers like exotic syntaxes. The majority of programmers are
> mediocre, and need some gimmick---such as exotic syntax---in order to
> bolster a self-image of high intelligence.
In other words, you think people who use Lisp are clever because you think
people who don't use Lisp are stupid.
Why do you think that most of the people who know Lisp choose not to use it?
Or the fact that both the proportion and absolute number of users with PhDs
is much higher for OCaml or Haskell than it is for Lisp?
How do you explain the lack of industrial success stories surrounding Lisp,
even compared to other FPLs?
Why do you think Lisp's immediate relatives are all extinct and that its
nearest living relative, Mathematica, is a domain specific language?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop wrote:
> Kaz Kylheku wrote:
>> On 2008-12-23, MishoM <···············@gmail.com> wrote:
>>> Hi,
>>>
>>> I'm really new to Lisp. I had heard of it before and got the
>>> impression of a dead language with an exotic syntax and no real use.
>> The syntax of Lisp is completely ``unexotic'', consisting mostly of
>> very ordinary tokens and some parentheses.
>>
>> Programmers like exotic syntaxes. The majority of programmers are
>> mediocre, and need some gimmick---such as exotic syntax---in order to
>> bolster a self-image of high intelligence.
>
> In other words, you think people who use Lisp are clever because you think
> people who don't use Lisp are stupid.
>
> Why do you think that most of the people who know Lisp choose not to use it?
>
> Or the fact that both the proportion and absolute number of users with PhDs
> is much higher for OCaml or Haskell than it is for Lisp?
>
> How do you explain the lack of industrial success stories surrounding Lisp,
> even compared to other FPLs?
>
> Why do you think Lisp's immediate relatives are all extinct and that its
> nearest living relative, Mathematica, is a domain specific language?
>
It's not even clear from your message whether you are reffering to
people that Know, that Use or that Wipe their Asses!
On 2009-01-09, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> On 2008-12-23, MishoM <···············@gmail.com> wrote:
>>> Hi,
>>>
>>> I'm really new to Lisp. I had heard of it before and got the
>>> impression of a dead language with an exotic syntax and no real use.
>>
>> The syntax of Lisp is completely ``unexotic'', consisting mostly of
>> very ordinary tokens and some parentheses.
>>
>> Programmers like exotic syntaxes. The majority of programmers are
>> mediocre, and need some gimmick---such as exotic syntax---in order to
>> bolster a self-image of high intelligence.
>
> In other words, you think people who use Lisp are clever because you think
> people who don't use Lisp are stupid.
In other words, you can't be trusted with the task of rendering
statements into other words.
On 2009-01-09, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> On 2008-12-23, MishoM <···············@gmail.com> wrote:
>>> Hi,
>>>
>>> I'm really new to Lisp. I had heard of it before and got the
>>> impression of a dead language with an exotic syntax and no real use.
>>
>> The syntax of Lisp is completely ``unexotic'', consisting mostly of
>> very ordinary tokens and some parentheses.
>>
>> Programmers like exotic syntaxes. The majority of programmers are
>> mediocre, and need some gimmick---such as exotic syntax---in order to
>> bolster a self-image of high intelligence.
>
> In other words, you think people who use Lisp are clever because you think
> people who don't use Lisp are stupid.
In other words, you can't be entrusted with the task of rendering statements
into other words.
From: Kaz Kylheku
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <20090117123430.79@gmail.com>
On 2009-01-09, Jon Harrop <···@ffconsultancy.com> wrote:
> Or the fact that both the proportion and absolute number of users with PhDs
> is much higher for OCaml or Haskell than it is for Lisp?
He's hung up on Lisp
He's got something to prove.
He does as he pleases
He flouts Usenet rules.
And he won't be convinced,
He has a Pee Heitch Dee!
The most he will do
Is irk a group or two.
But to me he's just Home Grenouiiii.
MishoM <···············@gmail.com> writes:
> So I formed my own opinion on why Lisp isn't popular and summarized it
> in the following two points:
> [...]
Making Lisp popular can definitively be done.
It has been done, several times.
For example, Matz took and old lisp, matzacred it, (removing good
features, adding horrors from such monster languagesas perl, etc), and
most importantly, changed the name, and called the result Ruby.
You can again do it anyday.
Take an implementation of Common Lisp, removing some sizeable
percentage of what makes it such a wonderful language, introduce as
many irregularities and idiosyncrasies from other programming
languages as you can, rename it for some precious stone (I like blue,
so I'd suggest some blue stone name), implement some web server on it
(be lazy just take one of the lisp web servers/frameworks and port it
to your "language") et voil�: instant popularity!
It can also help:
- not to publish any specification of the language, just provide THE
reference implementation,
- to change the language every six months (or more often if you can),
to suscitate press release and noise around your stone named
language.
--
__Pascal Bourguignon__
On 13 Jan., 17:51, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> MishoM <···············@gmail.com> writes:
> > So I formed my own opinion on why Lisp isn't popular and summarized it
> > in the following two points:
> > [...]
>
> Making Lisp popular can definitively be done.
> It has been done, several times.
>
> For example, Matz took and old lisp, matzacred it, (removing good
> features, adding horrors from such monster languagesas perl, etc), and
> most importantly, changed the name, and called the result Ruby.
>
> You can again do it anyday.
>
> Take an implementation of Common Lisp, removing some sizeable
> percentage of what makes it such a wonderful language, introduce as
> many irregularities and idiosyncrasies from other programming
> languages as you can, rename it for some precious stone (I like blue,
> so I'd suggest some blue stone name), implement some web server on it
> (be lazy just take one of the lisp web servers/frameworks and port it
> to your "language") et voilà: instant popularity!
>
> It can also help:
>
> - not to publish any specification of the language, just provide THE
> reference implementation,
>
> - to change the language every six months (or more often if you can),
> to suscitate press release and noise around your stone named
> language.
>
> --
> __Pascal Bourguignon__
Explained here:
http://rubyconf2008.confreaks.com/matzs-keynote.html
From: Pascal J. Bourguignon
Subject: Re: Making Lisp popular - can it be done?
Date:
Message-ID: <87zlhtwqun.fsf@galatea.local>
·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
> On 13 Jan., 17:51, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> MishoM <···············@gmail.com> writes:
>> > So I formed my own opinion on why Lisp isn't popular and summarized it
>> > in the following two points:
>> > [...]
>>
>> Making Lisp popular can definitively be done.
>> It has been done, several times.
>>
>> For example, Matz took and �old lisp, matzacred it, (removing good
>> features, adding horrors from such monster languagesas perl, etc), and
>> most importantly, changed the name, and called the result Ruby.
>>
>> You can again do it anyday.
>>
>> Take an implementation of Common Lisp, removing some sizeable
>> percentage of what makes it such a wonderful language, introduce as
>> many irregularities and idiosyncrasies from other programming
>> languages as you can, rename it for some precious stone (I like blue,
>> so I'd suggest some blue stone name), implement some web server on it
>> (be lazy just take one of the lisp web servers/frameworks and port it
>> to your "language") et voil�: instant popularity!
>>
>> It can also help:
>>
>> - not to publish any specification of the language, just provide THE
>> � reference implementation,
>>
>> - to change the language every six months (or more often if you can),
>> � to suscitate press release and noise around your stone named
>> � language.
>>
>> --
>> __Pascal Bourguignon__
>
> Explained here:
>
> http://rubyconf2008.confreaks.com/matzs-keynote.html
Indeed, he says that he designed Ruby because:
- he wanted to be in the aristocracy of language designers (but
appearently didn't care his users remained plebean or "Oridinary").
- he wanted the popularity of a mellow language.
Well done! He archieved his goals.
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
> For example, Matz took and old lisp, matzacred it, (removing good
> features, adding horrors from such monster languagesas perl, etc), and
> most importantly, changed the name, and called the result Ruby.
I always thought that Ruby was the bastard lovechild of Perl and
Smalltalk, rather than Perl and Lisp (though Smalltalk has a fair-sized
Lisp influence).
-- [mdw]