The Lisp Curse
fernando
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html,
posted in http://news.ycombinator.com/ ,
comments: http://news.ycombinator.com/item?id=2450973
Mario S. Mommer
The essay does not say anything that hasn't been said before, and
doesn't do that in a particularly elegant way.
Anyone that knows the lisp community knows the article is wrong in one
way or another on almost every count. It is also pretty stupid at times
("Unless they pay thousands of dollars, Lisp hackers are still stuck
with Emacs") and makes you wonder if he knows what he's talking about.
Marco Antoniotti
Cool. I agree... non I am off to re-implement some stuff. ;)
--
Marco
kodifik
of creating a community- considered C/unix was preferable.
Pascal J. Bourguignon
> That would explain why Richard Stallman -when confronted with the need
> of creating a community- considered C/unix was preferable.
At his time, he didn't really have a choice.
Unfortunately, it was only ten years later that cheap computers
(ie. "personnal computers") became powerful enough so that a real OS
could be written on them.
If he had been confronted by the software situation at that time, he
might have choosen to rewrite a lisp machine OS on PCs, and instead of
having linux distributions still failing at recreating the wheel today,
we'd have artificial intelligences running on lisp machines on our
hardware instead.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Mark Tarver
wrote:
It was doable in 1990 I think. At that time at Europal 90 I bench
tested every machine on exhibition.
Texas Explorer II
Symbolics Ivory Chip
Mu Lisp running on a 386 PC
Harlequin on a Sun
Now defunct - a Lisp machine from a company called 4th Wave which cost
£30,000
The Mu lisp was only 3x slower than the 4th Wave offering. About 10X
slower than the other guys, but in 1990 CPU performance was going up
and up. It is just that Lisp did not have a Linus Torvalds.
I also liked the article from the OP.
Mark
Pascal J. Bourguignon
> On Apr 18, 3:14 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
> wrote:
>> kodifik <kodi...@eurogaran.com> writes:
>> > That would explain why Richard Stallman -when confronted with the need
>> > of creating a community- considered C/unix was preferable.
>>
>> At his time, he didn't really have a choice.
>>
>> Unfortunately, it was only ten years later that cheap computers
>> (ie. "personnal computers") became powerful enough so that a real OS
>> could be written on them.
>>
>> If he had been confronted by the software situation at that time, he
>> might have choosen to rewrite a lisp machine OS on PCs, and instead of
>> having linux distributions still failing at recreating the wheel today,
>> we'd have artificial intelligences running on lisp machines on our
>> hardware instead.
>
> It was doable in 1990 I think. At that time at Europal 90 I bench
> tested every machine on exhibition.
>
> Texas Explorer II
> Symbolics Ivory Chip
> Mu Lisp running on a 386 PC
> Harlequin on a Sun
> Now defunct - a Lisp machine from a company called 4th Wave which cost
> £30,000
>
> The Mu lisp was only 3x slower than the 4th Wave offering. About 10X
> slower than the other guys, but in 1990 CPU performance was going up
> and up. It is just that Lisp did not have a Linus Torvalds.
Indeed, I started to use emacs in 1992 on NeXTstep. ;-)
And too bad NeXTstep wasn't just a lisp OS, (I guess Interface Builder
came too late in the game).
> I also liked the article from the OP.
--
Mark Tarver
>
> And too bad NeXTstep wasn't just a lisp OS, (I guess Interface Builder
> came too late in the game).
I remember that machine; a sleek black number that stood out in a room
of beige Suns. Jobs always knew style.
Mark
Tim X
I remember seeing an interview with Jobs where he was asked his opinion
of Bill Gates. He answered he had considerable respect for what Bill had
done, but his big criticisism was that he never did anything with any
style.
Tim
--
tcross (at) rapttech dot com dot au
Raffael Cavallaro
> but his big criticisism was that he never did anything with any
> style.
"The only problem with microsoft is they just have no taste, they have
absolutely no taste, and what that means is - I don't mean that in a
small way, I mean that in a big way - in the sense that they don't
think of original ideas, and they don't bring much culture into their
product. And you say 'why is that important' well, you know,
proportionally spaced fonts come from typesetting and beautiful books,
that's where one gets the idea. If it weren't for the Mac, they would
never have that in their products.
So I guess I am saddened, not by Microsoft's success, I have no problem
with their success, they've earned their success, for the most part. I
have a problem with the fact that they just make really third rate
products."
<http://www.youtube.com/watch?v=mOgOP_aqqtg>
warmest regards,
Ralph
--
Raffael Cavallaro
Peter Hill
Maybe the price doesn't stretch to the cost of style?
Or it's the middle man. Most MS product comes preloaded on new
computers. Paying for Style would be a hit on their bottom line.
Back in the days of Win 3.11 I never used Word. I produced all
documents using Pagemaker. It came with proper fonts and gave me
precise layout control that is still lacking in Word. Word is only fit
for tech reports or memos. As typing stuff into Pagemaker was slow
even on a 486DX50 I abused Turbo Pascal as a text editor. MS have
largely ignored MS Publisher, which says just what they think of
style.
Other than Basic that went into so many 8 bit computer's roms MS
didn't earn their success they bought it, one OS or Killer App at a
time. The thing MS has against Linux is they had Unix on PC hardware
and threw it away - it wasn't ALL theirs, they couldn't buy AT&T and
the licence cost money.
--
Peter Hill
Spamtrap reply domain as per NNTP-Posting-Host in header
Can of worms - what every fisherman wants.
Can of worms - what every PC owner gets!
Bigos
> Anyone that knows the lisp community knows the article is wrong in one
> way or another on almost every count. It is also pretty stupid at times
> ("Unless they pay thousands of dollars, Lisp hackers are still stuck
> with Emacs") and makes you wonder if he knows what he's talking about.
Unfortunately ignorant masses will agree with the essay author.
Mark Tarver
> might have choosen to rewrite a lisp machine OS on PCs, and instead of
> having linux distributions still failing at recreating the wheel today,
> we'd have artificial intelligences running on lisp machines on our
> hardware instead.
The moment of opportunity passed; nowdays operating systems are so
huge that people get sucked into supporting one of the existing
monoliths. So innovation withers.
As you say, failing to reinvent the wheel with $x millions of free
programmer hours is not an impressive testimony to OS methodology. At
least Bill Gates sometimes delivers stuff that ordinary people are
happy to use. Vista should have been an open goal for Linux geeks.
You won't see your dream OS unless some corporation with deep pockets
lines up behind the idea.
Mark
Bakul Shah
> kodifik<kod...@eurogaran.com> writes:
>
>> That would explain why Richard Stallman -when confronted with the need
>> of creating a community- considered C/unix was preferable.
>
> At his time, he didn't really have a choice.
>
> Unfortunately, it was only ten years later that cheap computers
> (ie. "personnal computers") became powerful enough so that a real OS
> could be written on them.
Powerful personal computers have been available for 20+ years.
Has such a `real OS' been written? What distinguishes a real
OS (in your opinion) from, say, Unix, Windows, various real
time OSes, Plan 9, etc.? What changes can be made to one of
these OSes to become a `real OS'? Not just rhetorical questions,
I am interested in knowing if something can be done about this.
Surely it can't be too hard to mutate an existing small
footprint OS into something of your liking? RMS can't be the
only person who could've written a Lisp OS.
PS: I am looking for things like `this is what Unix does, this
is a better version that a real OS would provide'.
Peter Keller
> On 4/18/11 7:14 AM, Pascal J. Bourguignon wrote:
>> kodifik<kod...@eurogaran.com> writes:
>>
>>> That would explain why Richard Stallman -when confronted with the need
>>> of creating a community- considered C/unix was preferable.
>>
>> At his time, he didn't really have a choice.
>>
>> Unfortunately, it was only ten years later that cheap computers
>> (ie. "personnal computers") became powerful enough so that a real OS
>> could be written on them.
>
> Powerful personal computers have been available for 20+ years.
> Has such a `real OS' been written? What distinguishes a real
> OS (in your opinion) from, say, Unix, Windows, various real
> time OSes, Plan 9, etc.? What changes can be made to one of
> these OSes to become a `real OS'? Not just rhetorical questions,
> I am interested in knowing if something can be done about this.
> Surely it can't be too hard to mutate an existing small
> footprint OS into something of your liking? RMS can't be the
> only person who could've written a Lisp OS.
>
> PS: I am looking for things like `this is what Unix does, this
> is a better version that a real OS would provide'.
I think definition implied by the contextual usage of "real" is:
a preempting multi-tasking OS with real user identity boundaries
between resources.
An OS is hard to write not because of handling things like a
process/thread abstraction, memory management, or context switching,
or whatever. They are hard to write because of the drivers. Wanna shell
out 300 bucks for an ATA specification (which, after laborious hours,
you discover wrong stuff in it not covered by errata)? How about more
money to learn how to talk to the PCI bridge? Don't have enough money
to woo a video card vendor to give you specs for writing a driver? How
about that odd USB dongle for this 4 year old plotter? Hrm 5 different
types of SCSI, suck! etc, etc, etc. Identifying and talking to random
hardware that existed anywhere from the late 1980's to now is a *HUGE*
amount of effort.
If you want to know why an OS is hard to write, look at the first
pile of assembly instructions in the linux kernel. You'll see awesome
comments (at the time I looked at any rate) like:
# swap these two values from the PCI controller. Don't know why as
# this isn't in the spec, but it made it work.
Figuring that crap out is time consuming.
-pete
Frode V. Fjeld
> # swap these two values from the PCI controller. Don't know why as
> # this isn't in the spec, but it made it work.
>
> Figuring that crap out is time consuming.
But copying linux' behavior shouldn't be...?
--
Frode V. Fjeld
Pascal Costanza
The major fallacy is to believe that the state of affairs has good
reasons, while it is more likely to be just a string of accidents.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
The views expressed are my own, and not those of my employer.
Tim X
I think there is a little irony going on here.
I don't think the essay said anything very original. It is a point of
view I have some agreement with. To some extent, the lisp curse does
exist. As a language, it provides incredible power and makes many things
that appear difficult in other languages much easier and does tend to
foster a "do it yourself" or "roll your own" mentality. You often see
discussions narrowing down onto a single, often minor, point at the
expense of the original issue and for whatever reason, there does seem
to be more 'one person' projects and less medium to large team projects
that you see in many other language groups. What I'm not sure about is
whether he has identified the correct causes or has in fact attributed
some of the additional symptoms as being the cause.
What I find ironic is that many of the criticisms I've read regarding
this essay seem to confirm what the author is saying rather than refute
it. Responses like "the author is wrong because he says we don't have X
in lisp, but I have X" or "the author is wrong because we says we don't
have X in lisp, but I can implement X in 10 lines of code i.e. ....."
etc. seem to be missing the point. The essay is not about the technical
strengths/weaknesses of the language, but rather about the mindset,
personalities and levels of cooperation/collaboration amongst those who
tend to be attracted to the language - its about the community of users,
not about the technology IMO
Pascal J. Bourguignon
> On 4/18/11 7:14 AM, Pascal J. Bourguignon wrote:
>> kodifik<kod...@eurogaran.com> writes:
>>
>>> That would explain why Richard Stallman -when confronted with the need
>>> of creating a community- considered C/unix was preferable.
>>
>> At his time, he didn't really have a choice.
>>
>> Unfortunately, it was only ten years later that cheap computers
>> (ie. "personnal computers") became powerful enough so that a real OS
>> could be written on them.
>
> Powerful personal computers have been available for 20+ years.
> Has such a `real OS' been written? What distinguishes a real
> OS (in your opinion) from, say, Unix, Windows, various real
> time OSes, Plan 9, etc.? What changes can be made to one of
> these OSes to become a `real OS'? Not just rhetorical questions,
> I am interested in knowing if something can be done about this.
> Surely it can't be too hard to mutate an existing small
> footprint OS into something of your liking?
You need to cater to the network effect: people will use your OS only if
people use your OS. (That means you have a bootstrapping problem, but
it's not insurmountable).
To have people use your OS, it should be at least ten times better than
existing OSes. Have ten times as many apps, be ten times easier to use,
have ten times as many compatible devices, and ten times cheaper.
(which, given the cost of obtaining linux from the Internet, is hard to
beat, but still; it could be one tenth the size of a linux distribution,
it must be ten times as easy to install as linux (and linux is ten times
easier to install than MS-Windows, I can witness it).
RG
Pascal Costanza <p...@p-cos.net> wrote:
> On 16/04/2011 12:18, fernando wrote:
> > An essay by Rudolf Winestock,
> > http://www.winestockwebdesign.com/Essays/Lisp_Curse.html,
> > posted in http://news.ycombinator.com/ ,
> > comments: http://news.ycombinator.com/item?id=2450973
>
> The major fallacy is to believe that the state of affairs has good
> reasons, while it is more likely to be just a string of accidents.
That's not a fallacy. The proposition that there are reasons for things
being the way they are is one of the bedrock assumptions of science.
rg
Pascal J. Bourguignon
Is the situation in the Java world so enviable? Or even in C++?
Last time I envisaged to use Qt, I had a look at their Xml stuff.
Just to parse XML and process a tree, there was more than fifteen
XmlSomething classes to deal with... I'm sorry, my brain is not big
enough for that, I'd prefer to rewrite xmls in ten lines indeed.
This is fundamental. A Computer Scientist needs to understand (if not
to proove) his code, so it's a good thing to be able to write anything
we need in ten lines of lisp, and it's even better than to spend half a
day to locate the right library, read the doc if unfortunately there's
one, ascertain the validity and correctness of the library, integrate it
in your code (convert calling conventions, value types, etc).
So, I really I don't see that as a problem, but as a good thing.
Now, perhaps for Software Engineers, a different kind of language is
needed. Yes, perhaps Lisp is not for Software Engineers. So be it.
Peter Keller
It's fine to copy if the beginning part of your new OS has the
same viewpoint as Linux. But as soon as it diverges, it'll get time
consuming very quickly.
-pete
Pascal J. Bourguignon
You can present to linux drivers a linux API even if you're not linux.
IIRC, there's a BSD kernel that does that to benefit from linux drivers.
Bakul Shah
> Bakul Shah<use...@bitblocks.com> writes:
>
>> On 4/18/11 7:14 AM, Pascal J. Bourguignon wrote:
>>> kodifik<kod...@eurogaran.com> writes:
>>>
>>>> That would explain why Richard Stallman -when confronted with the need
>>>> of creating a community- considered C/unix was preferable.
>>>
>>> At his time, he didn't really have a choice.
>>>
>>> Unfortunately, it was only ten years later that cheap computers
>>> (ie. "personnal computers") became powerful enough so that a real OS
>>> could be written on them.
>>
>> Powerful personal computers have been available for 20+ years.
>> Has such a `real OS' been written? What distinguishes a real
>> OS (in your opinion) from, say, Unix, Windows, various real
>> time OSes, Plan 9, etc.? What changes can be made to one of
>> these OSes to become a `real OS'? Not just rhetorical questions,
>> I am interested in knowing if something can be done about this.
>> Surely it can't be too hard to mutate an existing small
>> footprint OS into something of your liking?
>
> You need to cater to the network effect: people will use your OS only if
> people use your OS. (That means you have a bootstrapping problem, but
> it's not insurmountable).
Note that Dennis Ritchie & Ken Thompson didn't consider this. Neither
did Linus. I think they were just scratching an "intellectual" itch &
their s/w just happened to find a niche. The same is also true of most OSS.
> To have people use your OS, it should be at least ten times better than
> existing OSes. Have ten times as many apps, be ten times easier to use,
> have ten times as many compatible devices, and ten times cheaper.
> (which, given the cost of obtaining linux from the Internet, is hard to
> beat, but still; it could be one tenth the size of a linux distribution,
> it must be ten times as easy to install as linux (and linux is ten times
> easier to install than MS-Windows, I can witness it).
As a hobbyist you build such software for yourself. If it fills a
need and is any good, people will flock. But thinking more about it,
I suspect writing a Lisp OS is not a burning desire for anyone --
what can it do that can't be done by a regular OS + lisp on top?
There would be no point in emulating Unix.
c...@clsnet.nl
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
Does it really matter?
I do not think so.
It really is nice to have the skills and the tools avilable to make a
Duesenburg or nifty hors-buggy fot that matter while the masses ride
their lifeless compact-hybrids.
Or debug a mars-rover at 10 lightminutes distance while at the same time
some billion-dollar cie can't keep simple spyware out of their OS.
Do I suffer from the cusrse in any form or shape?
Of course , and do so gladly, no sheople stuff is allowed on the
premises here.
Cor
--
Monosyllabisch antwoorden is makkelijker, en ik kan mij melk veroorloven
Geavanceerde politieke correctheid is niet te onderscheiden van sarcasme
First rule of engaging in a gunfight: HAVE A GUN
spam DELENDA EST http://www.spammesenseless.nl
Frode V. Fjeld
I'm not entirely sure I understand or agree with this. It's pretty much
the name of the game that hardware has its fixed "viewpoint" and that
software needs to dance around this. So long as you duplicate the basic
structure of linux' drivers, I'd be surprised if this didn't reduce the
programmer's workload by 90% or more.
--
Frode V. Fjeld
Mark Tarver
> On 4/19/11 3:52 PM, Pascal J. Bourguignon wrote:
>
>
>
>
>
> > Bakul Shah<use...@bitblocks.com> writes:
>
> >> On 4/18/11 7:14 AM, Pascal J. Bourguignon wrote:
>
> - Show quoted text -
I think one benefit, if it could be done, would be the move from
seeing an operating system
as a collection of various utilities chucked into a large bag, towards
seeing them as a collection of stateful functions with type signatures
attached to them which tell how these utilities can be composed.
Windows 7, despite being a slick piece of work for the non-
computerate, remains stuck at the grab-bag model. I cannot easily
connect my email to my word processor and there is no general model
for doing it.
In Unix you have pipes, which are a sort of poor man's attempt to
provide this sort of functionality (IMO so is Emacs), but it is a long
way below the functionality provided by a type secure programming
language like Qi. An operating system built on top of this technology
would not only be much shorter in lines of code, it would also be more
reliable and much more flexible.
Functional languages are a very natural candidate for this sort of
work. The Unix command line is, if you think about it, a sort of
repl, except what lies below it is very weak.
Mark
Marco Parrone
> Peter Keller <psi...@cs.wisc.edu> writes:
>
>> Frode V. Fjeld <fro...@gmail.com> wrote:
>>> Peter Keller <psi...@cs.wisc.edu> writes:
>>>
>>>> # swap these two values from the PCI controller. Don't know why as
>>>> # this isn't in the spec, but it made it work.
>>>>
>>>> Figuring that crap out is time consuming.
>>>
>>> But copying linux' behavior shouldn't be...?
>>
>> It's fine to copy if the beginning part of your new OS has the
>> same viewpoint as Linux. But as soon as it diverges, it'll get time
>> consuming very quickly.
>
> You can present to linux drivers a linux API even if you're not linux.
> IIRC, there's a BSD kernel that does that to benefit from linux drivers.
There is a toolkit for building operating systems:
http://www.cs.utah.edu/flux/oskit/
it is used by the GNU Mach microkernel:
http://www.gnu.org/software/hurd/microkernel/mach/gnumach.html
http://cvs.savannah.gnu.org/viewvc/gnumach/?root=hurd
--
Marco Parrone <ma...@marcoparrone.com>
PGP Key fingerprint = 5E21 BED2 BF47 B3FB F17F 1DB4 D9BE B2B7 3C3A 07E2
Eric Schulte
> "Pascal J. Bourguignon" <p...@informatimago.com> writes:
>
>> Peter Keller <psi...@cs.wisc.edu> writes:
>>
>>> Frode V. Fjeld <fro...@gmail.com> wrote:
>>>> Peter Keller <psi...@cs.wisc.edu> writes:
>>>>
>>>>> # swap these two values from the PCI controller. Don't know why as
>>>>> # this isn't in the spec, but it made it work.
>>>>>
>>>>> Figuring that crap out is time consuming.
>>>>
>>>> But copying linux' behavior shouldn't be...?
>>>
>>> It's fine to copy if the beginning part of your new OS has the
>>> same viewpoint as Linux. But as soon as it diverges, it'll get time
>>> consuming very quickly.
>>
>> You can present to linux drivers a linux API even if you're not linux.
>> IIRC, there's a BSD kernel that does that to benefit from linux drivers.
>
> There is a toolkit for building operating systems:
>
> http://www.cs.utah.edu/flux/oskit/
>
> it is used by the GNU Mach microkernel:
>
> http://www.gnu.org/software/hurd/microkernel/mach/gnumach.html
> http://cvs.savannah.gnu.org/viewvc/gnumach/?root=hurd
One nice aspect upon building an OS on top of the gnumach kernel as part
of the Hurd ecosystem could be the use of subhurds [1], to run a
developmental lisp OS alongside a traditional linux OS on the same box.
Also, presumably building on top of a mach kernel would be much easier
than building directly on hardware, and would allow the lisp to get
/close-enough/ to the metal to enable most of the benefits of a lisp OS
(e.g., global introspection, uniform types).
To my mind once such a lispOS could run Emacs (ported from elisp to the
common-lisp of the OS) it would be functional enough to use.
Best -- Eric
Footnotes:
[1] http://www.gnu.org/s/hurd/hurd/subhurd.html
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Pascal J. Bourguignon
> On 4/19/11 3:52 PM, Pascal J. Bourguignon wrote:
>> You need to cater to the network effect: people will use your OS only if
>> people use your OS. (That means you have a bootstrapping problem, but
>> it's not insurmountable).
>
> Note that Dennis Ritchie & Ken Thompson didn't consider this. Neither
> did Linus. I think they were just scratching an "intellectual" itch &
> their s/w just happened to find a niche. The same is also true of most OSS.
They lived in different times. There were tens of different OS ideas
being researched and developed them. Today, researchers are just
studying the JVM and teaching Java.
>> To have people use your OS, it should be at least ten times better than
>> existing OSes. Have ten times as many apps, be ten times easier to use,
>> have ten times as many compatible devices, and ten times cheaper.
>> (which, given the cost of obtaining linux from the Internet, is hard to
>> beat, but still; it could be one tenth the size of a linux distribution,
>> it must be ten times as easy to install as linux (and linux is ten times
>> easier to install than MS-Windows, I can witness it).
>
> As a hobbyist you build such software for yourself. If it fills a
> need and is any good, people will flock. But thinking more about it,
> I suspect writing a Lisp OS is not a burning desire for anyone --
> what can it do that can't be done by a regular OS + lisp on top?
> There would be no point in emulating Unix.
Exactly. As a simple programmer, it's easier to write a virtual
machine, and to write an "OS" as an application, than to deal with the
drivers and difficult stuff of bare-to-the-metal OS development.
There are even people writing OSes in Javascript nowadays!
Bigos
> Some entity, AKA Bigos...
I have been called many names, but never have been called an entity,
now I have to check my dictionary to see if I should start a flame
war ;-)
> Do I suffer from the cusrse in any form or shape?
> Of course , and do so gladly, no sheople stuff is allowed on the
> premises here.
I'd say that Lisp is a bug, and people who don't get Lisp are immune
to it. Although I will never be an elite Lisper I think I was infected
by it.
Jack
Marco Parrone
Android is structured is a way to encourage application components reuse:
http://developer.android.com/guide/topics/fundamentals.html
There are also some Lispy interpretes:
http://www.jawara.org/public/top.html
http://code.google.com/p/dialcode
I've not tried them, so I don't know about their capabilities, but I
suspect they could be a nice interface to the OS for users having coding
skills.
Mario S. Mommer
Tim X <ti...@nospam.dev.null> writes:
> I don't think the essay said anything very original. It is a point of
> view I have some agreement with. To some extent, the lisp curse does
> exist. As a language, it provides incredible power and makes many
> things that appear difficult in other languages much easier and does
> tend to foster a "do it yourself" or "roll your own" mentality. You
> often see discussions narrowing down onto a single, often minor, point
> at the expense of the original issue and for whatever reason, there
> does seem to be more 'one person' projects and less medium to large
> team projects that you see in many other language groups. What I'm not
> sure about is whether he has identified the correct causes or has in
> fact attributed some of the additional symptoms as being the cause.
He did not even mention the syntax as a possible reason why lisp does
not have a major following, which I think is a rather hefty omission. In
my experience, this is the most important reason by about two orders of
magnitude. Many people find the syntax gross and that's the end of
it.
> What I find ironic is that many of the criticisms I've read regarding
> this essay seem to confirm what the author is saying rather than refute
> it. Responses like "the author is wrong because he says we don't have X
> in lisp, but I have X" or "the author is wrong because we says we don't
> have X in lisp, but I can implement X in 10 lines of code i.e. ....."
Maybe I read another thread than you; I think it went off to a tangent
rather quickly, and none of the things you are claiming happened.
Anyway. I think the author is wrong because he says we don't have
functioning and positive community around lisp, but I know there is a
functioning and positive community around lisp.
> etc. seem to be missing the point. The essay is not about the technical
> strengths/weaknesses of the language, but rather about the mindset,
> personalities and levels of cooperation/collaboration amongst those who
> tend to be attracted to the language - its about the community of users,
> not about the technology IMO
That much was clear. My point is that it is wrong in its claims.
ccc31807
> That's not a fallacy. The proposition that there are reasons for things
> being the way they are is one of the bedrock assumptions of science.
Which is exactly why science cannot deal with things that have no
reason. This isn't an insult to science, but an observation that some
things have no reason, and cannot be dealt with by science, no matter
how hard scientists try.
Perhaps attempting to do science with things that have no reason is
the chief fallacy of science.
CC.
Zach Beane
> This isn't an insult to science, but an observation that some things
> have no reason, and cannot be dealt with by science, no matter how
> hard scientists try.
Your post to usenet is a good example.
Zach
Tim Bradshaw
> He did not even mention the syntax as a possible reason why lisp does
> not have a major following, which I think is a rather hefty omission.
Yes, it's obvious that Lisp's syntax would put anyone off, while XML,
say, is bound to succeed, because it's just so much more terse and
clear.
Pascal Costanza
I think Mario is actually right. People seem to think that traditional
C-style, or whatever non-Lisp style syntax, is how programming languages
ought to look like, that seeing something like Lisp syntax indeed puts
them off. (I think the same is actually true for switching between other
kinds of language syntaxes as well.)
Another issue is that everything is in prefix notation, and that several
operators have "weird" names.
It takes a while to realize that Lisp syntax actually works well once
you're used to it, and that even when it's not necessarily optimal in
some respects (like mathematical operators), it has profound technical
advantages that are much more important.
RG
wrote:
Actually, the success of XML over sexprs lends credence to the original
theory, that Lisp fails *because* it is too empowering and therefore
tends to attract people who aren't team players. XML, like C, is so
broken that it is not possible for anyone to do anything productive with
it except by working as part of a team.
rg
Tim Bradshaw
> Actually, the success of XML over sexprs lends credence to the original
> theory, that Lisp fails *because* it is too empowering and therefore
> tends to attract people who aren't team players. XML, like C, is so
> broken that it is not possible for anyone to do anything productive with
> it except by working as part of a team.
That's at least plausible (I haven't read the original reference), but
I think that, given XML is essentially sexps implemented by a
bureaucracy, it does make it implausible that it's the syntax that's
the killer. It doesn't work to say that bureaucratic syntaxes win,
because C clearly isn't. You'd have to claim some complicated compound
thing - syntaxes which aren't like C need to be bureaucratic or
something. Or just admit it's not the syntax (not that you are
claiming it is: others were).
Blake McBride
used many languages. I see lisp as an unmatched thing of beauty. I
have often thought of why lisp isn't much more popular. I think the
reasons have changed over time but this is the reason why now.
Lisp has two problems as follows:
1. Too many people view lisp as an ancient language. Out of date.
Dated. Old ideas that have been superseded. They see C# as modern. I
mean imagine, C# even has lambda functions now. What do us lispers
have to say about that? Lambda functions are so new, and as a new
language, C# is able to take advantage of these new ideas. Ha.
2. This is a real biggie!! Lisp libraries are too out of date.
Really. The world is using portable GUI's, standard SQL interfaces,
XML, Web Services, etc.. Yes, Lisp has libraries that support many
(but not all) of these sorts of things but I have experimented with
them. They really don't work. They're kludgy, lacking, non-portable,
unsupported, half-implemented, impossible to setup and configure, etc..
It's just too much work. Lisp has got all the language features
totally nailed down in the most elegant way imaginable but the
libraries needed to interact with the modern world are awful (a
technical term).
Again, I have tried many of those libraries and found many half-baked
attempts but few fully supported, portable libraries needed to do real
work. Just try doing Web Services in Lisp!
If there were a critial mass of interest in Lisp the libraries would be
built. Other aspects of the beauity and strength (combined with the
libraries) would help with people's view of lisp as out dated. Support
of (good or bad) standards is the path to popularity. Fix #2 and #1
will fix itself.
Blake McBride
Krzysztof Bieniasz
> I thought I'd add my two cents. I have 30+ years programming and have
> used many languages. I see lisp as an unmatched thing of beauty. I
> have often thought of why lisp isn't much more popular. I think the
> reasons have changed over time but this is the reason why now.
...
< snip >
...
> Blake McBride
If I may add some of my thoughts to the discussion, though I'm far from
being an experienced programmer. I think that the primary reasons for
Lisp's unpopularity are historical/political. We all know of the AI
winter, perhaps some of you guys even remember the time. After the AI
people failed to deliver real artificial intelligence products the
industry simply became suspicious of the AI stuff. I suppose everyone
know the famous thesis title: "If it works, it's not AI".
Since Lisp has always been "the AI language", whatever that would mean,
it became unpopular, carrying the stigma of AI. So, after the commercial
programmers stopped using it, Lisp became sort of forgotten. Since then a
new generation of programmers have come, most of whom either never used
Lisp or only passed some minor Scheme course at college, and have since
forgotten the thing. They learn C++ and Java, because those are the
languages they'll be needing for their daily work. They may have heard of
Perl or Python if they're into FOSS but that's just about it. The best
reaction to Lisp you could expect of them would be: "You mean you
actually program in Lisp? That arcane AI language? That's so old-
fashioned."
So the problem is how to convince the people that think Lisp is a thing
of the past, that in fact it's the thing of the future. Think about it
this way: how do you imagine convincing a "modern" programmer to use
Fortran instead of C++ ?! Because that's more or less what most people
think of Lisp -- as something old and annoying like a yet another Fortran.
KTB
Cthun
> 2. This is a real biggie!! Lisp libraries are too out of date. Really.
> The world is using portable GUI's, standard SQL interfaces, XML, Web
> Services, etc.. Yes, Lisp has libraries that support many (but not all)
> of these sorts of things but I have experimented with them. They really
> don't work. They're kludgy, lacking, non-portable, unsupported,
> half-implemented, impossible to setup and configure, etc.. It's just too
> much work. Lisp has got all the language features totally nailed down in
> the most elegant way imaginable but the libraries needed to interact
> with the modern world are awful (a technical term).
Clojure to the rescue, then. All the power of Lisp's language features,
plus all the power of Java's extensive standard libraries, and the
ability to be deployed in all the places where Java is used, such as
servlet containers.
Cthun
> So the problem is how to convince the people that think Lisp is a thing
> of the past, that in fact it's the thing of the future.
Bell bottoms and polyester came back. Other things go and then come
back. Maybe it just takes waiting until the generation *after* the one
that was raised to consider Lisp inherently sucky to come of age and
start hacking?
Krzysztof Bieniasz
Yes, but who's going to convince them it's worth it? I mean I wouldn't
expect anyone to get involved in Fortran of their own free will. For new
hackers there are a multitude of new, attractive languages to hack in.
There's Python (which, as Peter Norvig showed, is just a stripped down
Lisp without macros and sexps), Haskell is growing fast and there's the
hot new topic called concurrency, for which there are specialised
languages developed, like Go or Erlang. How in this multitude of new toys
are the new hackers supposed to find Lisp, if there is no one to show
them the right way? I simply don't think this matter will sort out
itself, the Lisp community needs to attract more programmers. And we all
know that's not an easy task since we're already considered some sort of
a sect.
KTB
TheFlyingDutchman
Functional programming is getting traction as the best way to program
for concurrency. Lisp is associated with functional programming. And
Clojure adds immutable data structures as a feature to make
concurrency easy.
Clojure sells itself as a Lisp - but makes certain to distance itself
from existing Lisps. It is a "new Lisp". Something that likely feels
better for young programmers looking for a language, and is something
Common Lisp could never be. Although there could be a "new revised
version" Common Lisp.
TheFlyingDutchman
saw a table comparison by a new JVM language to 6 other JVM languages,
one of which was Clojure. It had 10 features for comparison, the last
of which was inexplicably "Not Lisp". This allowed it to put a check
mark in that row for 6 languages and leave a blank for Clojure. Which
then caused 3 languages to get one more check mark than Clojure,
leaving Clojure in last place in number of features met.
D Herring
Honestly, for several years after my CS course taught in Scheme, I
would have strongly agreed that "not lisp" was a feature. The course
was so bad, that I couldn't figure out why another student was proud
of embedding a small scheme interpreter into the simulator he was
writing...
Today, I'd probably rate intro lisp courses taught by dull CS
lecturers as one of lisp's worst problems. Every year, we get waves
of these poor lost souls, looking simply to get a decent grade and
hoping to avoid the perceived curse.
Two benefits to starting from a clean slate: plenty of low-hanging
fruit, and no old baggage.
I enjoy reading theories about the rise and fall of industrialized
nations. Some seem relevant to computer languages. CL is in a state
of slow decay relative to other languages, but I'm banking on a
rebirth that involves a "new language", capable of running CL code
(scheme too?) and having strong interop for several others (C, C++,
C#, Java, etc.). The ultimate glue language.
Rich Hickey did well with Clojure, but I'm hoping for something a bit
different.
- Daniel
Pascal Costanza
If the libraries are really so bad, how come professional Lisp
programmers achieve so much? There is something wrong in that reasoning.
You can find bad libraries in any programming language. Dan Weinreb of
ITA Sofware said in a presentation at an ECLM that they have never
experienced a library problem for their Common Lisp development, and
they probably use more or less all Common Lisp libraries that exist. ;)
Just one example.
If you want to get things done in Lisp, you can. (Maybe that's the
difference, that mainstream languages cater to the people whose primary
goal is not to get things done.)
Cthun
> Dnia Mon, 25 Apr 2011 20:44:02 -0400, Cthun napisał(a):
>
>> On 25/04/2011 8:11 PM, Krzysztof Bieniasz wrote:
>>> So the problem is how to convince the people that think Lisp is a thing
>>> of the past, that in fact it's the thing of the future.
>>
>> Bell bottoms and polyester came back. Other things go and then come
>> back. Maybe it just takes waiting until the generation *after* the one
>> that was raised to consider Lisp inherently sucky to come of age and
>> start hacking?
>
> Yes, but who's going to convince them it's worth it? I mean I wouldn't
> expect anyone to get involved in Fortran of their own free will. For new
> hackers there are a multitude of new, attractive languages to hack in.
Like Clojure?
> There's Python (which, as Peter Norvig showed, is just a stripped down
> Lisp without macros and sexps)
Clojure is not stripped down.
> Haskell is growing fast
Clojure emphasizes functional programming.
> and there's the hot new topic called concurrency, for which there are
> specialised languages developed, like Go or Erlang.
Or Clojure.
> How in this multitude of new toys are the new hackers supposed to find
> Lisp
> if there is no one to show them the right way?
What am I, chopped liver?
> I simply don't think this matter will sort out itself, the Lisp
> community needs to attract more programmers.
By developing a modernized Lisp like Clojure?
> And we all know that's not an easy task since we're already considered
> some sort of a sect.
Classic unsubstantiated and erroneous claim. We're way too disorganized
to be a sect. Us forming a sect would be like a group of cats
pack-hunting. ;)
Ankur
>> I simply don't think this matter will sort out itself, the Lisp
>> community needs to attract more programmers.
>
> By developing a modernized Lisp like Clojure?
What is so good about being modern?
Common Lisp is still unsurpassed as a general purpose programming
language; its philosophy is something I wish more people understood.
>> And we all know that's not an easy task since we're already considered
>> some sort of a sect.
>
> Classic unsubstantiated and erroneous claim. We're way too disorganized
> to be a sect. Us forming a sect would be like a group of cats
> pack-hunting. ;)
It doesn't have to be true for people to believe it.
--
Ankur
Pascal J. Bourguignon
> Dnia Mon, 25 Apr 2011 20:44:02 -0400, Cthun napisał(a):
>
>> On 25/04/2011 8:11 PM, Krzysztof Bieniasz wrote:
>>> So the problem is how to convince the people that think Lisp is a thing
>>> of the past, that in fact it's the thing of the future.
>>
>> Bell bottoms and polyester came back. Other things go and then come
>> back. Maybe it just takes waiting until the generation *after* the one
>> that was raised to consider Lisp inherently sucky to come of age and
>> start hacking?
>
> Yes, but who's going to convince them it's worth it?
http://ai-contest.com/rankings.php
That's a start.
If we could maintain this "trend" for a few years, I guess they'd notice.
That would put the ball in their field, either they'd switch to Lisp, or
they'd forbid any "language with too many parentheses" from AI contests.
Stefan Nobis
> As an example of some of the negative impressions regarding Lisp, I
> saw a table comparison by a new JVM language to 6 other JVM languages,
I think you mean
<http://gosu-lang.org/comparison.shtml>
but be also aware of
where one of the Gosu team writes, the comparison table is largely a joke.
--
Stefan.
TheFlyingDutchman
> TheFlyingDutchman schrieb:
>
> > As an example of some of the negative impressions regarding Lisp, I
> > saw a table comparison by a new JVM language to 6 other JVM languages,
>
> I think you mean
>
> <http://gosu-lang.org/comparison.shtml>
>
> but be also aware of
>
>
> where one of the Gosu team writes, the comparison table is largely a joke.
>
one other row as being a joke. So I can't see where it could possibly
be "largely a joke", even if someone says that the "Not Lisp" row was.
Mario S. Mommer
I wrote that this is what I observed. You are essentially saying that my
data is wrong because it contradicts your theory. Frankly, I really
can't help you there.
I agree with you that from a practical point of view it doesn't make any
sense, but it is the way it is.
kodifik
> Clojure to the rescue, then. All the power of Lisp's language features,
> plus all the power of Java's extensive standard libraries, and the
> ability to be deployed in all the places where Java is used, such as
> servlet containers.
Programming languages normally use words and punctuation marks,
as most written languages do.
I am no expert, but looks to me that if you give more importance
to punctuation marks, and take them as the starting point in defining
a language, then you end up with something similar to Lisp or Xml.
Whereas taking words as more fundamental then you get everything else.
Does Clojure follow the first, or the second approach?
Pascal J. Bourguignon
> On Apr 26, 2:42 am, Cthun <cthun_...@qmail.net.au> wrote:
>> Clojure to the rescue, then. All the power of Lisp's language features,
>> plus all the power of Java's extensive standard libraries, and the
>> ability to be deployed in all the places where Java is used, such as
>> servlet containers.
>
> Programming languages normally use words and punctuation marks,
> as most written languages do.
> I am no expert, but looks to me that if you give more importance
> to punctuation marks, and take them as the starting point in defining
> a language, then you end up with something similar to Lisp
There's no punctuation marks in lisp, only words.
> or Xml.
Yes, XML does includes punctuation marks.
> Whereas taking words as more fundamental then you get everything else.
> Does Clojure follow the first, or the second approach?
More than lisp anyways.
Krzysztof Bieniasz
>
> Functional programming is getting traction as the best way to program
> for concurrency. Lisp is associated with functional programming. And
> Clojure adds immutable data structures as a feature to make concurrency
> easy.
>
> Clojure sells itself as a Lisp - but makes certain to distance itself
> from existing Lisps. It is a "new Lisp". Something that likely feels
> better for young programmers looking for a language, and is something
> Common Lisp could never be. Although there could be a "new revised
> version" Common Lisp.
Fine, Clojure might actually attract some attention to Lisp family and at
the expense of Java too. But will CL benefit from it? Of course CL isn't
necessarily the ultimate language, we might need a new Lisp in its place.
But do you think that Clojure is this new Lisp? Or that it goes in the
right direction? Would you switch to it and say its the future? I don't
think so.
Clojure is a bit like Ubuntu. It attracts new users and makes some
publicity for other Lisps as well. But the risk is that the users will
stick to it and never move to things that are more powerful though less
user-friendly. Naturally Clojure developers don't view it in this
perspective, for them this is an opportunity for a success. But most of
their users will simply stay Lisp ignorants.
KTB
kodifik
wrote:
> There's no punctuation marks in lisp, only words.
Both exist in Lisp.
But you are right, I'm Sorry I used the expression "punctuation marks"
incorrectly to include also separation/grouping characters.
Krzysztof Bieniasz
> Krzysztof Bieniasz <krzysztof....@gmail.com> writes:
>
>> Dnia Mon, 25 Apr 2011 20:44:02 -0400, Cthun napisał(a):
>>
>>> On 25/04/2011 8:11 PM, Krzysztof Bieniasz wrote:
>>>> So the problem is how to convince the people that think Lisp is a
>>>> thing of the past, that in fact it's the thing of the future.
>>>
>>> Bell bottoms and polyester came back. Other things go and then come
>>> back. Maybe it just takes waiting until the generation *after* the one
>>> that was raised to consider Lisp inherently sucky to come of age and
>>> start hacking?
>>
>> Yes, but who's going to convince them it's worth it?
>
> http://ai-contest.com/rankings.php
> That's a start.
> If we could maintain this "trend" for a few years, I guess they'd
> notice.
>
>
> That would put the ball in their field, either they'd switch to Lisp, or
> they'd forbid any "language with too many parentheses" from AI contests.
Yeah, Lisp is a drug, disqualify Lisp hackers :)
Tim Bradshaw
> I wrote that this is what I observed. You are essentially saying that my
> data is wrong because it contradicts your theory.
No, I'm saying that people give reasons for not liking Lisp which are
not their real reasons, because their real reasons are some kind of
primitive fear of difference, and people don't like to admit to that.
Pascal J. Bourguignon
> On Apr 26, 12:27 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
> wrote:
>> There's no punctuation marks in lisp, only words.
> Parenthesis are not words. Spaces are not words.
> Both exist in Lisp.
No. That's the point. There's no parenthesis and no space in a lisp
program:
(first '(if (equal a b) (f a) (g (b))))
--> IF
The first thing there is in the expression (if (= a b) (f a) (g (b))),
is the word IF. The second is the expression (= a b), no space in
between. And still no parenthesis:
(first (second '(if (equal a b) (f a) (g (b)))))
--> EQUAL
Antsan
Stefan Nobis
I think, the whole table is just a very small and subjective selection
of interesting features when comparing languages (focusing on what the
Gosu team is interested in and what they think is good for marketing).
Another point is that Carson Gross (in the article on stackoverflow)
mentions himself that even the comparison to Scala (the best contender
to Gosu according to the comparison table) is quite unfair, as Scala is
much more mature and he would himself today prefer Scala for a real
world project.
--
Stefan.
ccc31807
> ccc31807 <carte...@gmail.com> writes:
> > This isn't an insult to science, but an observation that some things
> > have no reason, and cannot be dealt with by science, no matter how
> > hard scientists try.
>
> Your post to usenet is a good example.
Zach, please forgive me for not supplying a context. I was mulling
over a statement that Peter Norvig makes in section 4.20 of PIAP, "...
there are some problems that computers can't solve -- not because a
theoretically correct program can't be written, but because execution
of the program will take too long." I think he's right, but for the
wrong reason.
In my job, I do a lot of reporting to management to answer specific
questions. Sometimes, my users will ask me to answer a question like,
'Should we open a new location, and if so, where?' Sometimes, I will
tell them that, if they give me a complete specification of all the
relevant facts and all the relevant rules, I can trivially write a
program that will answer the question. Of course, they cannot specify
all the relevant facts or rules, not because the quantity is immense,
but because in some sense the facts and rules are unknowable.
There are some professionals that seem to have skill embedded in them
somehow, like Bach (I listened to the 'St. Matthew Passion' this
Easter), or a great military leader, or a trial lawyer, that can't be
taught. Mozart and Salieri learned composition from the same schools
in the same way, yet one was a genius and the other was a hack. Could
you write an algorithm to have predicted (in advance) who would be
which?
I think that the 'Lisp Curse' falls into this category. Some few
people see the genius in Lisp, but most don't, and I don't think that
this can be quantified, or that an algorithm can be written to predict
a result, not because the computational complexity is so great, but
because in some sense the facts cannot be known.
Is there a God? We can't prove that God exists, but neither can we
prove that God doesn't exist. This is a question that is beyond
physical science, it's literally a metaphysical question. I think that
the question of Lisp is this kind of question, although it's a lot
less momentous than the question of God's existence.
CC.
Raffael Cavallaro
> Is there a God? We can't prove that God exists, but neither can we
> prove that God doesn't exist.
"An atheist doesn't have to be someone who thinks he has a proof that
there can't be a god. He only has to be someone who believes that the
evidence on the God question is at a similar level to the evidence on
the werewolf question."
John McCarthy, inventor/discoverer of lisp
warmest regards,
Ralph
--
Raffael Cavallaro
ccc31807
<raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
> > Is there a God? We can't prove that God exists, but neither can we
> > prove that God doesn't exist.
>
> "An atheist doesn't have to be someone who thinks he has a proof that
> there can't be a god. He only has to be someone who believes that the
> evidence on the God question is at a similar level to the evidence on
> the werewolf question."
'Evidence' consists of physical observations, or deductions drawn from
physical observations (circumstantial evidence) that are probative to
the issue. 'Proof' is a conclusion drawn from consideration of the
evidence. Reasonable people can legitimately draw different
conclusions from the evidence while agreeing on the evidence itself.
Belief in God is a matter of religious faith, not something based on
evidence, although religious people commonly cite various bits and
pieces of evidence to support their faith. Atheists are in a different
situation as there is no such thing as evidence that God doesn't
exist. Absence of evidence isn't evidence of absence.
With respect to the issue raised in this thread, the curse of Lisp,
the evidence appears that a much larger percentage of IT professionals
use other languages (Java, C#, C, Python, etc.), but in absolute terms
the number of Lispers may be as high as it ever has been.
I first thought that this couldn't be explainable, but after thinking
it over, the explanation might be as simple as the programming
language version of Gresham's Law. What do you think?
CC.
Raymond Wiker
Amen :-)
I'm using Lispworks and a whole bunch of Lisp libraries for
feeding the search engine at work (as well as doing a lot of work
related to the search engine). Some libraries I use directly, while
others are used by the libraries I use. With one or two small
exceptions, these libraries have worked flawlessly.
There have been cases where I have been unable to use pure Lisp
libraries, but RDNZL lets me use whatever I want from .NET. For example,
I have something like 100 lines of code that uses the .NET libraries to
give me the HTTP protocol support that I need (including
authentication), plus automatic retries, plus a macro that lets me
define web service calls in a straightforward manner. The resulting code
is easier to follow and debug than any of the generated crap I've seen
in Java.
To summarise the last half of the preceding paragraph: web
services in Lisp are trivial.
Cthun
> Clojure is a bit like Ubuntu. It attracts new users and makes some
> publicity for other Lisps as well. But the risk is that the users will
> stick to it and never move to things that are more powerful though less
> user-friendly. Naturally Clojure developers don't view it in this
> perspective, for them this is an opportunity for a success. But most of
> their users will simply stay Lisp ignorants.
Classic illogic. Where is Clojure "less powerful"? How are Clojure users
that work with sexps and macros and all of the usual stuff in any way
"staying Lisp ignorants[sic]"?
Cthun
> kodifik<kod...@eurogaran.com> writes:
>
>> On Apr 26, 12:27 pm, "Pascal J. Bourguignon"<p...@informatimago.com>
>> wrote:
>>> There's no punctuation marks in lisp, only words.
>> Parenthesis are not words. Spaces are not words.
>> Both exist in Lisp.
>
> No. That's the point. There's no parenthesis and no space in a lisp
> program:
>
> (first '(if (equal a b) (f a) (g (b))))
> --> IF
>
> The first thing there is in the expression (if (= a b) (f a) (g (b))),
> is the word IF. The second is the expression (= a b), no space in
> between. And still no parenthesis:
>
> (first (second '(if (equal a b) (f a) (g (b)))))
> --> EQUAL
This applies equally to Clojure, of course. And the textual
representation may actually have less punctuation, for a few reasons:
1. Fewer reader macros in general.
2. Less need for #' in particular, because of it being a Lisp-1.
3. (let [a 1 b 2 c 3] body) rather than (let ((a 1) (b 2) (c 3)) body),
and a few other bits of delimiter-economizing like that.
Cthun
> * Cthun<cthu...@qmail.net.au>
>>> I simply don't think this matter will sort out itself, the Lisp
>>> community needs to attract more programmers.
>>
>> By developing a modernized Lisp like Clojure?
>
> What is so good about being modern?
Classic illogic. The context of my remark had been a complaint that Lisp
is perceived as being too old-fashioned. In that context, the benefit of
being modern is obvious.
> Common Lisp is still unsurpassed as a general purpose programming
> language; its philosophy is something I wish more people understood.
Are you claiming to believe that Clojure lacks a similar philosophy, or
else that it is not a general-purpose programming language?
>>> And we all know that's not an easy task since we're already considered
>>> some sort of a sect.
>>
>> Classic unsubstantiated and erroneous claim. We're way too disorganized
>> to be a sect. Us forming a sect would be like a group of cats
>> pack-hunting. ;)
>
> It doesn't have to be true for people to believe it.
What does that have to do with Lisp, Ankur?
Eric Schulte
Clojure is purely functional, CL is multi-paradigm.
CL has mutable state, setf, loop, format, and the CLOS, none of which
are present in Clojure.
Clojure is an aesthetically clean wonderful language for purely
functional manipulation of lazy sequences, However after using it as my
main language for slightly over two years, I found myself all-to-often
butting heads with its paternalistic functionalism (trust me, I'm a
grown up, I can manage a little bit of mutable state without shooting
myself in the foot).
I think Clojure can be great for lisp in general through raising
awareness and bringing new users (e.g., me) to CL, however I also think
that it may be perpetuating some misapprehensions about lisp (e.g., lisp
is a functional language, CL is defunct).
Best -- Eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Cthun
> Cthun<cthu...@qmail.net.au> writes:
>
>> On 26/04/2011 7:06 AM, Krzysztof Bieniasz wrote:
>>> Clojure is a bit like Ubuntu. It attracts new users and makes some
>>> publicity for other Lisps as well. But the risk is that the users will
>>> stick to it and never move to things that are more powerful though less
>>> user-friendly. Naturally Clojure developers don't view it in this
>>> perspective, for them this is an opportunity for a success. But most of
>>> their users will simply stay Lisp ignorants.
>>
>> Classic illogic. Where is Clojure "less powerful"? How are Clojure
>> users that work with sexps and macros and all of the usual stuff in
>> any way "staying Lisp ignorants[sic]"?
>
> Clojure is purely functional
Classic unsubstantiated and erroneous claim. Clojure can use, and
instantiate, mutable Java objects and arrays, and even define new
classes of Java object with mutable fields.
> CL has mutable state, setf, loop, format, and the CLOS, none of which
> are present in Clojure.
Classic unsubstantiated and erroneous claim. Clojue has mutable state,
set! for thread-unsafe (e.g. mutable Java fields) mutation and alter,
ref-set, swap!, compare-and-set!, reset!, deliver, send, send-off, and
other functions that set thread-safe mutable values of various kinds.
> Clojure is an aesthetically clean wonderful language for purely
> functional manipulation of lazy sequences, However after using it as my
> main language for slightly over two years, I found myself all-to-often
> butting heads with its paternalistic functionalism (trust me, I'm a
> grown up, I can manage a little bit of mutable state without shooting
> myself in the foot).
So can Clojure, if you know how to use it right (and know how to get
down into the Java nuts and bolts when you need to).
> I think Clojure can be great for lisp in general through raising
> awareness and bringing new users (e.g., me) to CL, however I also think
> that it may be perpetuating some misapprehensions about lisp (e.g., lisp
> is a functional language, CL is defunct).
Classic illogic.
Eric Schulte
> On 26/04/2011 3:41 PM, Eric Schulte wrote:
>> Cthun<cthu...@qmail.net.au> writes:
>>
>>> On 26/04/2011 7:06 AM, Krzysztof Bieniasz wrote:
>>>> Clojure is a bit like Ubuntu. It attracts new users and makes some
>>>> publicity for other Lisps as well. But the risk is that the users will
>>>> stick to it and never move to things that are more powerful though less
>>>> user-friendly. Naturally Clojure developers don't view it in this
>>>> perspective, for them this is an opportunity for a success. But most of
>>>> their users will simply stay Lisp ignorants.
>>>
>>> Classic illogic. Where is Clojure "less powerful"? How are Clojure
>>> users that work with sexps and macros and all of the usual stuff in
>>> any way "staying Lisp ignorants[sic]"?
>>
>> Clojure is purely functional
>
> Classic unsubstantiated and erroneous claim. Clojure can use, and
> instantiate, mutable Java objects and arrays, and even define new
> classes of Java object with mutable fields.
>
>> CL has mutable state, setf, loop, format, and the CLOS, none of which
>> are present in Clojure.
>
> Classic unsubstantiated and erroneous claim.
What's the clojure equivalent of setf?
> Clojue has mutable state, set! for thread-unsafe (e.g. mutable Java
> fields) mutation and alter, ref-set, swap!, compare-and-set!, reset!,
> deliver, send, send-off, and other functions that set thread-safe
> mutable values of various kinds.
>
Yes, it is possible to mutate state, however only when that state is
explicitly wrapped up in a synchronization construct (atom, ref, agent)
each of which adds a layer of complexity/semantics. The closest Clojure
comes to allowing simple state is transients [1], which are a nice
concession but feel like a departure from the "Clojure way", and still
are unnecessarily painful to use.
>
>> Clojure is an aesthetically clean wonderful language for purely
>> functional manipulation of lazy sequences, However after using it as my
>> main language for slightly over two years, I found myself all-to-often
>> butting heads with its paternalistic functionalism (trust me, I'm a
>> grown up, I can manage a little bit of mutable state without shooting
>> myself in the foot).
>
> So can Clojure, if you know how to use it right
I spent too much time re-writing straight forward code as obfuscated
lazy list manipulation when the obvious solution either required local
state or lead to stack explosions (Clojure can't optimize tail-calls).
Sometimes doing it "right" leads to unintuitive and hard-to-maintain
code.
> (and know how to get down into the Java nuts and bolts when you need
> to).
>
I don't want to have to dive into Java to escape Rich Hickey's ideas of
how I should be writing my programs.
>
>> I think Clojure can be great for lisp in general through raising
>> awareness and bringing new users (e.g., me) to CL, however I also think
>> that it may be perpetuating some misapprehensions about lisp (e.g., lisp
>> is a functional language, CL is defunct).
>
> Classic illogic.
My main point is as follows. Clojure is a great functional programming
language, however pure functional programming (while currently trendy)
is (like pure OO programming, or any single approach) appropriate for
some situations, but not appropriate for all situations.
Hence, my desire to use a multi-paradigm language (like CL).
I'm happy Clojure works for you, it will remain my first choice for any
massively-parallel application which needs to run on the JVM, but it is
not a panacea.
Best -- Eric
Footnotes:
[1] http://clojure.org/transients
Raffael Cavallaro
> Belief in God is a matter of religious faith, not something based on
> evidence
To the extent a belief is not based on evidence, that belief is either
an untested hypothesis or a delusion. The belief in the sort of God
commonly denoted by that term in the West [1] is a testable,
falsifiable hypothesis, with no credible evidence; i.e., it is a
delusion.
warmest regards,
Ralph
[1] a being who can, for example, arrange for a pair of every
terrestrial animal species in existence to fit on a single boat, and
then cause it to rain for 40 days and 40 nights covering the whole land
surface of the earth with water, then arrange for the offspring of each
single pair to show the genetic diversity seen in the modern
populations of all these species in under 10,000 years. This cannot
have happened, so belief in the existence of such a being is delusional.
--
Raffael Cavallaro
ccc31807
<raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
> > Belief in God is a matter of religious faith, not something based on
> > evidence
>
> To the extent a belief is not based on evidence, that belief is either
> an untested hypothesis or a delusion. The belief in the sort of God
> commonly denoted by that term in the West [1] is a testable,
> falsifiable hypothesis, with no credible evidence; i.e., it is a
> delusion.
You are very much mistaken. 'Belief' (as in 'religious faith')as it is
generally used CAN'T(!!!) be based on evidence, otherwise it wouldn't
be belief. It would be fact, or a hypothesis for which a reasonable
argument could be made based on facts, that is, knowledge instead of
faith.
'God' as that noun is generally used in Christianity refers to a being
that is spiritual, supernatural, metaphysical, immortal, omnipresent,
omnipotent, invisible, and without any material substance. In other
words, we CAN'T(!!!) have any evidence of God because by the very
definition physical evidence is impossible.
It's possible that belief in God is a delusion, but it's a widely held
delusion, both in terms of time and space. We generally characterize
believers in God (in 21st century U.S.) as happier, more content, more
stable, better adjusted, etc., than those who have no belief in God.
Instead of calling it a delusion, call it a world view than generally
leads to greater happiness and contentment, at least in our culture.
Mind, I'm not arguing that God really exists. I'm just stating the
obvious fact that most Americans believe in the existence of some
spiritual being, and that those who follow the Christian or Jewish
form do better as a whole than those who hold no belief.
I'll also hazard a guess that if God appeared to you, as God did to
Paul on the road to Damascus, and spoke to you after striking you
blind, and then managed the restoration of your sight and called you
to be an apostle, you would probably believe in the existence of God,
even though you wouldn't be able to cite any evidence. I won't judge
either way, and you probably shouldn't either.
CC.
Tim X
> On Apr 19, 7:07 pm, RG <rNOSPA...@flownet.com> wrote:
>> That's not a fallacy. The proposition that there are reasons for things
>> being the way they are is one of the bedrock assumptions of science.
>
> Which is exactly why science cannot deal with things that have no
> reason. This isn't an insult to science, but an observation that some
> things have no reason, and cannot be dealt with by science, no matter
> how hard scientists try.
>
> Perhaps attempting to do science with things that have no reason is
> the chief fallacy of science.
>
How do you distinguish those things that have no reason from those whose
reason we don't know?
Tim
--
tcross (at) rapttech dot com dot au
Raffael Cavallaro
> You are very much mistaken. 'Belief' (as in 'religious faith')as it is
> generally used CAN'T(!!!) be based on evidence, otherwise it wouldn't
> be belief.
You're very confused. Belief is "acceptance that a statement is true or
that something exists[1]." Such acceptance is certainly based on
evidence among reasonable, sane people.
> I'll also hazard a guess that if God appeared to you, as God did to
> Paul on the road to Damascus, and spoke to you after striking you
> blind, and then managed the restoration of your sight and called you
> to be an apostle, you would probably believe in the existence of God,
> even though you wouldn't be able to cite any evidence.
Meaningless contrafactual. I'll hazard that if the Flying Spagetti Monster
<http://www.venganza.org/about/>
appeared to you and struck you blind, then restored your sight, then
demanded you wear your underwear on your head as a token of your
worship of Him, you would spend the rest of your life walking around
with boxers (or briefs?) on your head, praising the great Flying
Spaghetti Monster.
The whole point is that such a thing has never occurred, so no such
"evidence" for God (or the Flying Spaghetti Monster) exists.
To cut this off topic discussion short, you really want to read _The
God Delusion_ by Richard Dawkins.
<http://www.amazon.com/gp/product/0618918248/>
He covers all the major arguments for God, all the claims (such as
yours) that belief in God is not subject to evidentiary disproof, and
he systematically demolishes them all.
The summary is this: to maintain a belief in God as well as logical
consistency with reality, the claims for God must be so reduced as to
redefine God as "the Universe." Of course this makes the term "God"
both redundant and an essentially unrecognizable shell of its
conventional (and delusional) meaning.
I won't be replying to any more of your confused posts; read Dawkins.
Tim X
> On Apr 26, 12:35 pm, Raffael Cavallaro
> <raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
>> > Is there a God? We can't prove that God exists, but neither can we
>> > prove that God doesn't exist.
>>
>> "An atheist doesn't have to be someone who thinks he has a proof that
>> there can't be a god. He only has to be someone who believes that the
>> evidence on the God question is at a similar level to the evidence on
>> the werewolf question."
>
> 'Evidence' consists of physical observations, or deductions drawn from
> physical observations (circumstantial evidence) that are probative to
> the issue. 'Proof' is a conclusion drawn from consideration of the
> evidence. Reasonable people can legitimately draw different
> conclusions from the evidence while agreeing on the evidence itself.
>
Is that proof or merely hypothesis?
> Belief in God is a matter of religious faith, not something based on
> evidence, although religious people commonly cite various bits and
> pieces of evidence to support their faith. Atheists are in a different
> situation as there is no such thing as evidence that God doesn't
> exist. Absence of evidence isn't evidence of absence.
The difference you are supposing is artificial.
The atheist does not look for proof that god does not exist, but for
proof that one does exist. There is no real difference between the two
as both are based in faith - the religious person has faith that god
exists and the atheist has faith that god does not exist. Neither have
any proof.
>
> With respect to the issue raised in this thread, the curse of Lisp,
> the evidence appears that a much larger percentage of IT professionals
> use other languages (Java, C#, C, Python, etc.), but in absolute terms
> the number of Lispers may be as high as it ever has been.
>
> I first thought that this couldn't be explainable, but after thinking
> it over, the explanation might be as simple as the programming
> language version of Gresham's Law. What do you think?
>
I agree with a number of the observations outlined in the article. Some
of the conclusions would seem to follow, but I'm less convinced
regarding the overall suggestion of it being a curse. To some extent,
whether you see the issues as a curse or not depends on what your
expectations are.
Cthun
> It's possible that belief in God is a delusion, but it's a widely held
> delusion, both in terms of time and space. We generally characterize
> believers in God (in 21st century U.S.) as happier, more content, more
> stable, better adjusted, etc., than those who have no belief in God.
> Instead of calling it a delusion, call it a world view than generally
> leads to greater happiness and contentment, at least in our culture.
I guess ignorance really is bliss, then.
Tim X
> On 2011-04-25 12:59:21 +0100, Mario S. Mommer said:
>
>> He did not even mention the syntax as a possible reason why lisp does
>> not have a major following, which I think is a rather hefty omission.
>
> Yes, it's obvious that Lisp's syntax would put anyone off, while XML, say, is
> bound to succeed, because it's just so much more terse and clear.
>
I think the syntax differences and the argument it is that or it is the
parenthesis that put people off is generally over stated. As you point
out, XML is far worse and lisp actually has less syntax to learn than
almost any other language I've used.
Cthun
> ccc31807<cart...@gmail.com> writes:
>
>> Perhaps attempting to do science with things that have no reason is
>> the chief fallacy of science.
>
> How do you distinguish those things that have no reason from those whose
> reason we don't know?
Simple: the former do not exist, while the latter abound, so if you
encounter something that looks like it is one of those, then it is in
fact an example of the latter.
Cthun
> Cthun<cthu...@qmail.net.au> writes:
>
>> On 26/04/2011 3:41 PM, Eric Schulte wrote:
>>> CL has mutable state, setf, loop, format, and the CLOS, none of which
>>> are present in Clojure.
>>
>> Classic unsubstantiated and erroneous claim.
>
> What's the clojure equivalent of setf?
Which one would you prefer?
>> Clojue has mutable state, set! for thread-unsafe (e.g. mutable Java
>> fields) mutation and alter, ref-set, swap!, compare-and-set!, reset!,
>> deliver, send, send-off, and other functions that set thread-safe
>> mutable values of various kinds.
>
> Yes, it is possible to mutate state, however only when that state is
> explicitly wrapped up in a synchronization construct (atom, ref, agent)
> each of which adds a layer of complexity/semantics.
Classic unsubstantiated and erroneous claim. I already mentioned mutable
Java objects and arrays, Schulte, and those have no such wrapping
construct. Suffering from reading comprehension problems, Schulte?
>>> Clojure is an aesthetically clean wonderful language for purely
>>> functional manipulation of lazy sequences, However after using it as my
>>> main language for slightly over two years, I found myself all-to-often
>>> butting heads with its paternalistic functionalism (trust me, I'm a
>>> grown up, I can manage a little bit of mutable state without shooting
>>> myself in the foot).
>>
>> So can Clojure, if you know how to use it right
>
> I spent too much time re-writing straight forward code as obfuscated
> lazy list manipulation when the obvious solution either required local
> state or lead to stack explosions (Clojure can't optimize tail-calls).
Perhaps judicious use of recur and trampoline would have solved it.
> Sometimes doing it "right" leads to unintuitive and hard-to-maintain
> code.
Examples, please?
> I don't want to have to dive into Java to escape Rich Hickey's ideas of
> how I should be writing my programs.
What does that have to do with Lisp, Schulte?
>>> I think Clojure can be great for lisp in general through raising
>>> awareness and bringing new users (e.g., me) to CL, however I also think
>>> that it may be perpetuating some misapprehensions about lisp (e.g., lisp
>>> is a functional language, CL is defunct).
>>
>> Classic illogic.
>
> My main point is as follows. Clojure is a great functional programming
> language, however pure functional programming (while currently trendy)
> is (like pure OO programming, or any single approach) appropriate for
> some situations, but not appropriate for all situations.
On that score, all programming languages are appropriate for some
situations, but not for all, so your classic pontification does not
support a specific objection to Clojure.
> Hence, my desire to use a multi-paradigm language (like CL).
Most languages are multi-paradigm, including Clojure, which via
multimethods and Java has OO and via let and loop supports a more
imperative style for calculations and algorithms and the like.
> I'm happy Clojure works for you, it will remain my first choice for any
> massively-parallel application which needs to run on the JVM, but it is
> not a panacea.
Classic unsubstantiated and erroneous claim.
Cthun
> The atheist does not look for proof that god does not exist, but for
> proof that one does exist. There is no real difference between the two
> as both are based in faith - the religious person has faith that god
> exists and the atheist has faith that god does not exist. Neither have
> any proof.
The symmetry is broken by Ockham's Razor, however: taking a theory that
predicts, to a certain precision, what has been observed in the
universe, and then tacking on a hypothetical "God" to make a more
complex theory that has exactly as much, and no more, predictive and
explanatory power, obviously fails the razor. One more hypothesis; no
improvement in predictive and explanatory power.
Further to that, if no physical test can even in principle detect the
presence (or absence) of God or determine *which* God it is and what
behaviors on our parts would please or displease he, she, or it, then
the whole God question has zero practical value. It makes no difference
in this life, and we have no better or worse odds of avoiding ending up
in an unpleasant afterlife however we decide to behave given no way of
telling if it's going to turn out we're going to be judged by the
Christian God, or the Muslim one, or the Buddha, or Amun-Re, or Zeus, or
a squirming mass of tentacles that tortures anyone who was *not* a
mass-murderer, or etc., or nobody at all.
Cthun
Counterpoint: XML is also frequently machine-generated and used to
communicate between tools, rather than hand-edited; people who use Lisp
are expected to hand-edit Lisp sexps. :)
Ankur
> On 26/04/2011 3:05 AM, Ankur wrote:
>> * Cthun<cthu...@qmail.net.au>
>>>> I simply don't think this matter will sort out itself, the Lisp
>>>> community needs to attract more programmers.
>>>
>>> By developing a modernized Lisp like Clojure?
>>
>> What is so good about being modern?
>
> Classic illogic. The context of my remark had been a complaint that Lisp
> is perceived as being too old-fashioned. In that context, the benefit of
> being modern is obvious.
Being modern attracts people to Clojure, but it doesn't attract them
to Lisp.
>> Common Lisp is still unsurpassed as a general purpose programming
>> language; its philosophy is something I wish more people understood.
>
> Are you claiming to believe that Clojure lacks a similar philosophy, or
> else that it is not a general-purpose programming language?
Both.
>>>> And we all know that's not an easy task since we're already considered
>>>> some sort of a sect.
>>>
>>> Classic unsubstantiated and erroneous claim. We're way too disorganized
>>> to be a sect. Us forming a sect would be like a group of cats
>>> pack-hunting. ;)
>>
>> It doesn't have to be true for people to believe it.
>
> What does that have to do with Lisp, Ankur?
It has to do with your ironic, unsubstantiated and erroneous claim.
--
Ankur
Joost Kremers
> The difference you are supposing is artificial.
it is not.
> The atheist does not look for proof that god does not exist, but for
> proof that one does exist. There is no real difference between the two
> as both are based in faith - the religious person has faith that god
> exists and the atheist has faith that god does not exist. Neither have
> any proof.
the difference is that the burden of proof is on the one positing the existence
of god. absence of evidence does not mean evidence of absence, but it *does*
mean that if there is no evidence for X, then there is no need to assume X. (and
in fact every reason *not* to, because the non-existence of something can rarely
be proven.) i could posit the famous teapot in the sky, but as long as i don't
produce any evidence for its existence, no-one is obliged to *disprove* its
existence.
IOW the assumption of non-existence is the default, it applies automatically as
long as no evidence of existence has been given and need not be argued for.
--
Joost Kremers joostk...@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
Cthun
> Being modern attracts people to Clojure, but it doesn't attract them
> to Lisp.
Classic inconsistency. Clojure is a dialect of Lisp.
>>> Common Lisp is still unsurpassed as a general purpose programming
>>> language; its philosophy is something I wish more people understood.
>>
>> Are you claiming to believe that Clojure lacks a similar philosophy, or
>> else that it is not a general-purpose programming language?
>
> Both.
Both are classic unsubstantiated and erroneous claims.
>>>> Classic unsubstantiated and erroneous claim. We're way too disorganized
>>>> to be a sect. Us forming a sect would be like a group of cats
>>>> pack-hunting. ;)
>>>
>>> It doesn't have to be true for people to believe it.
>>
>> What does that have to do with Lisp, Ankur?
>
> It has to do with your ironic, unsubstantiated and erroneous claim.
What does your classic erroneous presupposition that I made an ironic,
unsubstantiated and erroneous claim have to do with Lisp, Ankur?
Toby Thain
One tends to think this is its only reasonable use.
Tim X
> On 25/04/2011 22:48, Tim Bradshaw wrote:
>> On 2011-04-25 12:59:21 +0100, Mario S. Mommer said:
>>
>>> He did not even mention the syntax as a possible reason why lisp does
>>> not have a major following, which I think is a rather hefty omission.
>>
>> Yes, it's obvious that Lisp's syntax would put anyone off, while XML,
>> say, is bound to succeed, because it's just so much more terse and clear.
>
> I think Mario is actually right. People seem to think that traditional C-style,
> or whatever non-Lisp style syntax, is how programming languages ought to look
> like, that seeing something like Lisp syntax indeed puts them off. (I think the
> same is actually true for switching between other kinds of language syntaxes as
> well.)
>
> Another issue is that everything is in prefix notation, and that several
> operators have "weird" names.
>
> It takes a while to realize that Lisp syntax actually works well once you're
> used to it, and that even when it's not necessarily optimal in some respects
> (like mathematical operators), it has profound technical advantages that are
> much more important.
>
>
My main reason for disagreeing with the role of syntax in reducing
acceptance is that it is too simplistic. Most of those I've talked to
and asked them why they haven't considered lisp for doing something
are not even familiar enough with the language to reject it because of
syntax. Those I've spoken with who have expressed a problem with
the syntax have not really given the language an honest assessment -
they have read a paper or two and tried one hello world script and given
up.
I think there are far more fundamental reasons, many of which are
perceptions and not necessarily based in fact. Most often, the reason
something like CL is rejected in favor of some other language has little
to do with the technical pros or cons of the language. Reasons I've
encountered include -
- It is old and there is an assumption that new/modern is
better.
- Lack of easy integration with other common commercial
products. I was going to use either SBCL/Clisp for a
project that required Oracle integration. There was no
support for this (clsql was not sufficient as it does not
support calling of stored procedures).
- Difficulty in finding skilled/experienced technical staff. In the last
10 years of being involved in recruitment, I would be over
stating matters if I said there had been 10 people who
included lisp as one of their skills. There have been
absolutely none who stated they had commercial/paid
experience with lisp in that time. Fewer universities are
using lisp for teaching and many at best, only cover it in
a single semester course that also inclues things like
prolog, smalltalk etc.
- No high profile lisp based projects. Look at most of the
more widely used languages and you will find they either
have strong commercial support from a well known vendor
(Microsoft .NET, Sun/Oracle Java etc) are extensively used by a high
profile organisations (Google and python), have grabbed
community attention through some significant innovation or
solved a problem at just the right time (Ruby, rails,
basecamp) or perl, web/sys admin etc). Lots of decisions,
especially in larger organisations and corporations are
based on perceptions of risk and a tendency towards risk
avoidance. It is rare you will find a mid level decision
maker who is prepared to support use of a language if they
cannot point to other places (preferrably in the same
bsuiness sector) who are also using it.
- Too flexible. This may seem like an odd limitation - how
can something be too flexible. The issue is that big
organisations generally don't handle flexible well. They
like standard, uniform things that are easy to
manage/replace.
One of the things I like about lisp is that it is usually quite
straight-forward to bend it to suit my needs and solve my problem. If I
want to use perl, C, Java etc, I will normally spend the initial stage
researching and identifying the libraries and modules I'm going to use
and determining how I will use the language to solve the problem. With
CL, things are sort of reversed. I start by exploring the problem and
working out how to do what I want to do with the language - I bend lisp
to fit with how I think about/understand the problem rather than having
to bend how I think to fit with how the language wants me to solve the
problem. A common criticism of CL has been the lack of an extensive high
level library of extended functionality. I've rarely found this an
issue. More often than not, it is faster for me to just implement the
functionality I need. I do use third party libraries, but don't look for
libraries to do everything. Often, all I need is just one small part of
any library anyway and it can be easier (both from a development and
maintenance standpoint) to just implement what I need in a few lines of
code. Sure, it won't be a comprehensive library with a well defined API,
but often that is not what I need. Yes, I may find the same
funcitonality or something similar is needed for the next problem I work
on and I may find myself writing it again. If this happens frequently
enough, I may create a library or I may look for a 3rd party one.
However, much of the time, this doesn't happen and my few lines of code
implemented for that specific case are sufficient and all I ever need.
While this is great for me because it often means I'm into actually
finding a solution quicker, I'm not as convinced it is also as good for
others who may also want to work with me or use what I have done. In
addition to having to know lisp, they now also need to
know/understand/appreciate how I think to a greater degree than may be
the case when using a language that forces everyone to do things in a
defined, common way.
I've seen references to lisp being like a big ball of mud you can mould
into whatever you need. Other languages seem more like lego blocks - you
can do some pretty amazing things, but your limited to the blocks you
have and cannot easily just craft a radically new sort of block. More
importantly, everyone else using that lego langauge is familiar with
most of the core blocks and many of the more obscure ones and can
therefore quicly grasp how you constructed your solution. With the ball
of mud, they know what the base is, may be in awe of what you have
created, may be able to build on what you have done, but may find it
very difficult to understand how you got there or know how to
modify/update what you have done.
Some people like to start with the ball of mud - they like the freedom
and potential it offers. Others find this overwhelming and would prefer
a set of well defined blocks. Some people like to start with a blank
sheet, others prefer a structured outline.
Currently, the industry favors structured, mass produced, standard
solutions. The more ad hoc, crafted solution makes them nervous because
they don't understand it. There are a few, small "cottage" industries
out there making the crafted product, but they are unlikely to ever
become widespread, large, popular or mainstream etc. This, for me, is
largely the lisp curse.
Pascal J. Bourguignon
writes:
> [1] a being who can, for example, arrange for a pair of every
> terrestrial animal species in existence to fit on a single boat, and
> then cause it to rain for 40 days and 40 nights covering the whole
> land surface of the earth with water, then arrange for the offspring
> of each single pair to show the genetic diversity seen in the modern
> populations of all these species in under 10,000 years. This cannot
> have happened, so belief in the existence of such a being is
> delusional.
Of course it may happen. Remember, He's God. Here is how you could do
it:
(defvar *gamete-bank* (make-hash-table :test 'equal))
(dolist (an *animals*)
(setf (gethash (cons (animal-specie an)
(animal-sex an)) *gamete-bank*)
(one-of (animal-gametes an))))
(deluge)
(defmethod mate ((male animal) (female animal))
(assert (eq :male (animal-sexp male)))
(assert (eq :female (animal-sexp female)))
(let ((mg (gethash (cons (animal-specie male) :male) *gamete-bank*))
(fg (gethash (cons (animal-specie female) :female) *gamete-bank*)))
(remhash (cons (animal-specie male) :male) *gamete-bank*)
(remhash (cons (animal-specie female) :female) *gamete-bank*)
(if (and mg fg)
(fertilize female fg mg)
nil)))
(mp:make-thread
(lambda ()
(loop
:while (plusp (hash-table-count *gamete-bank*))
:do (sleep +one-year+)
:finally (progn
(remove-method (function mate)
(find-method (function mate)
'()
(list (find-class 'animal)
(find-class 'animal))))
(setf *gamete-bank* nil)))))
So if *I* can imagine the process in less than thirty lines of lisp
code, imagine how *God* *Himself* could have done it!
Therefore, you haven't proved that belief in the existence of such a
being is delusional. Try again. If you like losing your time.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Ankur
> Clojure is a dialect of Lisp.
Whether or not one PL is a dialect of another is a fuzzy concept.
Simply saying "a is a dialect of b" doesn't make it true.
Practically, it is very different to Common Lisp and thus even if more
people use Clojure (or Scheme), they are still missing an understanding
of the Common Lisp philosophy. There are many people on the internets
saying "Common Lisp was too hard, but Clojure is so cool because I can
has all my Java libraries!1!1!!!one". Common Lisp will likely always
be a minority language because it requires considerable study.
--
Ankur
Teemu Likonen
> [...] they are still missing an understanding of the Common Lisp
> philosophy.
How would you define the Common Lisp philosophy? Is this philosophy
described somewhere? (In case I have missed it too since Common Lisp and
Emacs Lisp are pretty much the only programming languages I know.)
Teemu Likonen
> [...] they are still missing an understanding of the Common Lisp
> philosophy.
How would you characterize the Common Lisp philosophy? Is this
Cthun
> * Cthun<cthu...@qmail.net.au>
>> Clojure is a dialect of Lisp.
>
> Whether or not one PL is a dialect of another is a fuzzy concept.
> Simply saying "a is a dialect of b" doesn't make it true.
What does your classic erroneous presupposition that I am a liar have to
do with Lisp, Ankur?
> Practically, it is very different to Common Lisp and thus even if more
> people use Clojure (or Scheme), they are still missing an understanding
> of the Common Lisp philosophy.
What does your classic unsubstantiated and erroneous claim ... unless,
of course, you'd like to substantiate it by being less vague than "the
Common Lisp philosophy", whatever you mean by that phrase.
> There are many people on the internets saying "Common Lisp was too
> hard, but Clojure is so cool because I can has all my Java
> libraries!1!1!!!one". Common Lisp will likely always be a minority
> language because it requires considerable study.
Classic illogic. You yourself just argued that it will likely always be
a minority language because it lacks good standard library support for
common modern host-interop, UI, and networking tasks, forcing reliance
on dodgy third-party libraries and wheel-reinvention.
ccc31807
<raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
> You're very confused. Belief is "acceptance that a statement is true or
> that something exists[1]." Such acceptance is certainly based on
> evidence among reasonable, sane people.
Circular reasoning. You assume that 'reasonable, sane people' base
belief on 'evidence', and then conclude that people who don't base
belief 'evidence' are not reasonable and sane.
> Meaningless contrafactual. I'll hazard that if the Flying Spagetti Monster
...
> with boxers (or briefs?) on your head, praising the great Flying
> Spaghetti Monster.
Of course. The difference is that historical evidence (and by that I
mean secular contemporaneous records) exists that an event like my
conjecture occurred, while no evidence of any kind exists that your
conjecture occurred.
> The whole point is that such a thing has never occurred, so no such
> "evidence" for God (or the Flying Spaghetti Monster) exists.
You must be deaf, blind, and dumb. If nothing else, the Neronic
persecution in 64 AD certainly is evidence that a number of people
accepted a belief in a resurrected God and held that belief to the
point of death. The point is NOT that God exists (we have no evidence
that God exists or not) but that people BELIEVE that God exists.
> To cut this off topic discussion short, you really want to read _The
> God Delusion_ by Richard Dawkins.
Read it and found it shallow and essentially meaningless, a waste of
my time. I'll be happy to discuss this with you, but not in this
thread.
> The summary is this: to maintain a belief in God as well as logical
> consistency with reality, the claims for God must be so reduced as to
> redefine God as "the Universe." Of course this makes the term "God"
> both redundant and an essentially unrecognizable shell of its
> conventional (and delusional) meaning.
You haven't been paying attention. My original point was that God
isn't amenable to reason, logic, empiricism, or the scientific method.
Seems to me you just made that point for me, so maybe I should thank
you.
CC.
ccc31807
> The atheist does not look for proof that god does not exist, but for
> proof that one does exist. There is no real difference between the two
> as both are based in faith - the religious person has faith that god
> exists and the atheist has faith that god does not exist. Neither have
> any proof.
Agreed.
> I agree with a number of the observations outlined in the article. Some
> of the conclusions would seem to follow, but I'm less convinced
> regarding the overall suggestion of it being a curse. To some extent,
> whether you see the issues as a curse or not depends on what your
> expectations are.
As one who has attempted to learn Common Lisp for several years with
little success, and who has reasonable proficiency in other languages
(mainly Perl) and has actively written code on a daily basis for the
past five years or so, I think one of the major factors is the
proliferation of Lisp implementations and the scarcity of standardized
libraries, like CPAN or CRAN.
CC
ccc31807
On Apr 26, 7:13 pm, Cthun <cthun_...@qmail.net.au> wrote:
> The symmetry is broken by Ockham's Razor, however: taking a theory that
> predicts, to a certain precision, what has been observed in the
> universe, and then tacking on a hypothetical "God" to make a more
> complex theory that has exactly as much, and no more, predictive and
> explanatory power, obviously fails the razor. One more hypothesis; no
> improvement in predictive and explanatory power.
This deals with phenomena in the natural world. It assumes that you
are hypothesizing God to explain natural events. The fallacy lies in
seeking to explain the natural world as the result of God's activity.
For example, assuming the Big Bang, you would rely on reason or
observation to answer the question of the state of things prior to the
Big Bang. There's simply no way we can get past the Big Bang by
logical or scientific means, and by the same token we can't get past
the physical universe to ask questions about heaven.
> Further to that, if no physical test can even in principle detect the
> presence (or absence) of God or determine *which* God it is and what
> behaviors on our parts would please or displease he, she, or it, then
> the whole God question has zero practical value. It makes no difference
> in this life, and we have no better or worse odds of avoiding ending up
> in an unpleasant afterlife however we decide to behave given no way of
> telling if it's going to turn out we're going to be judged by the
> Christian God, or the Muslim one, or the Buddha, or Amun-Re, or Zeus, or
> a squirming mass of tentacles that tortures anyone who was *not* a
> mass-murderer, or etc., or nobody at all.
The fallacy of this is (and I ask that you read this very carefully to
avoid misunderstanding) -- If our knowledge of God comes from
revelation, and God reveals Himself to particular people, then people
who haven't experienced such revelation don't have any evidence for
the existence of God. All they have is the personal witness of those
to whom God speaks, and this eye-witness testimony is at best
ambiguous and subject to different interpretations. After all, the
people who claim that God speaks to them may all be liars or
delusional or simply mistaken. Or, on the other hand, God might
actually be speaking to them. Who can tell? If someone claims that God
speaks to him, how can you disprove it?
JK's statement about the burden of proof is well taken, but the burden
of proof relates to the individual believer, not to a jury or to the
world at large. If we had evidence of the existence of God like we
have evidence of subatomic particles, or genetics, then (almost)
everyone would believe in God, except that we would not call it faith
but knowledge.
I totally agree that the natural assumption is that God does not
exist, if only because God has no material form that can be seen,
weighed, measured, or detected by any empirical means. That assumption
can be overcome in particular cases by the experience of the
individual believer, but that individual's experience cannot be
enlarged to any group of people. Religious faith is an individual
matter, not something to be demonstrated in a physics lab.
CC.
Pascal J. Bourguignon
> As one who has attempted to learn Common Lisp for several years with
> little success, and who has reasonable proficiency in other languages
> (mainly Perl) and has actively written code on a daily basis for the
> past five years or so, I think one of the major factors is the
> proliferation of Lisp implementations
So how do you compile your perl program with gcc?
How do you make DLL written in perl?
How do you run perl scripts on the JVM?
How do you generate fast executable for programs written in perl?
> and the scarcity of standardized libraries, like CPAN or CRAN.
You're out-dated. There's quicklisp!
Welcome to a modern programming world: Common Lisp, with refined tools
and de-facto standardized libraries.
Pascal J. Bourguignon
> I totally agree that the natural assumption is that God does not
> exist, if only because God has no material form that can be seen,
> weighed, measured, or detected by any empirical means.
It had: Jesus Christ.
Frode V. Fjeld
> <raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
>> You're very confused. Belief is "acceptance that a statement is true or
>> that something exists[1]." Such acceptance is certainly based on
>> evidence among reasonable, sane people.
ccc31807 <cart...@gmail.com> writes:
> Circular reasoning. You assume that 'reasonable, sane people' base
> belief on 'evidence', and then conclude that people who don't base
> belief 'evidence' are not reasonable and sane.
You are in a sense correct that this is "circular reasoning", although
it's better known as a "postulate" or an "axiom". There's no formal
logic that compels you to accept it, but I think that those who don't
tend to be classified as clinically insane.
--
Frode V. Fjeld