Here's more of a strategic platform question.
Simply put if you had 10 man years at your disposal, how would you allocate
it to advance Common Lisp?
I originally framed this as $1,000,000, which can be argued as "10 man
years", but I didn't want folks to quibble about salaries and taxes and
crap.
So.
Given that you can "spend" the budget as you like (20 people for 6 months, 2
for 5 years, etc), what would you do with it?
You could add threads to CLISP, say, but that really only advances CLISP but
not really Common Lisp. Is the fact that CLISP doesn't have threads holding
back Common Lisp? I don't think so, regardless of how much it would be nice
for CLISP to have them.
Would updating the ANSI standard help? Put the 10 man years into committees,
and specifications, etc, so that ANSI CL can have sockets, threads, etc now
"standard"?
That would help formalize what CL is in reality, and perhaps help in
portability, but I don't think that is what's holding CL back either.
Give the 10MY to Symbolics to port Open Genera to a new platform? That may
be enough to do the port, but it's certainly not enough to have them "give
it away". So, they'd get OG 2.0 on a more modern platform, but we can't
really strut the results around against the Javas and such of the world.
Create a new LispOS from scratch? Lock 3 guys in a room with some hardware
for 3 years, I'd like to think that could make a dent in that project.
Finish MacCLIM?
What about crafting and writing an AppServer like system on top of CL?
Pour all of the resources into Dylan??? :-)
Fancy print campaigns to "get the word out"?
I look at companies like Franz (arguably the Commercial CL leader), and they
are pretty much purely market driven (as well they should be), letting their
customers lead the product. Tweaking for customer needs, assimilating
customer suggestions into new features, custom compilers, and ports. These
folks are basically tied to their customer base, so while they may well have
good and interesting ideas, they simply may not have the time and $$$ to be
speculative. We throw the 10MY at them, but, again, there may well be a
better ACL, but does it help CL in the Large?
But if given essentially Carte Blanche to "Advance the CL platform", where
would your nickles go?
(And no, I don't have $1M burning a hole in my pocket...it's a completely
speculative question.)
Regards,
Will Hartung
(·····@msoft.com)
In article <···············@ID-197644.news.uni-berlin.de>, "Will Hartung"
<·····@msoft.com> wrote:
> Here's more of a strategic platform question.
>
> Simply put if you had 10 man years at your disposal, how would you allocate
> it to advance Common Lisp?
http://www.flownet.com/gat/ciel.pdf
E.
From: ·······@noshpam.lbl.government
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <4pkr7vgwvvr.fsf@thar.lbl.gov>
Associative arrays/maps as the primary data type? Have you taken a
look at the Lua scripting/extension language? It is a very small
language that claims that it uses associative arrays "in the same way
that Lisp uses lists".
www.lua.org
(no relation to www.alu.org :-) )
Ciel is a very interesting project!
There's a new Scheme SRFI which is trying to standardize a
"parenthesis-free" extension to Scheme. It is based on the
indentation-sensitive package for Scheme called "Sugar". The resulting
code looks very Pythonic to me (disclaimer: I've never programmed in
Python, I've just seen some code).
http://srfi.schemers.org/srfi-49/srfi-49.html
~Tomer
·········@flownet.com (Erann Gat) writes:
> In article <···············@ID-197644.news.uni-berlin.de>, "Will Hartung"
> <·····@msoft.com> wrote:
>
>> Here's more of a strategic platform question.
>>
>> Simply put if you had 10 man years at your disposal, how would you allocate
>> it to advance Common Lisp?
>
> http://www.flownet.com/gat/ciel.pdf
>
> E.
--
()
In article <···············@thar.lbl.gov>, ·······@noshpam.lbl.government wrote:
> Associative arrays/maps as the primary data type? Have you taken a
> look at the Lua scripting/extension language? It is a very small
> language that claims that it uses associative arrays "in the same way
> that Lisp uses lists".
>
> www.lua.org
Never heard of it before, and lua.org seems to be down. But based on what
I found at lua-users.org it seems like an interesting project. Seems a
lot like a cleaner Python with keywords instead of syntactically
significant whitespace (but without a mapping of the surface syntax to
S-expressions, which I really want so I can have CL-style macros). I'm
pleasantly surprised that a project like LUA can get as much traction as
it seems to have gotten given how similar it seems to be to Python.
> Ciel is a very interesting project!
Thanks. In the interests of full disclosure it should be noted that Ciel
is vaporware, and is likely to remain so for some time (like until someone
fullfills the antecedant of the question that started this thread).
E.
Erann Gat wrote:
>
> Never heard of it before, and lua.org seems to be down. But based on
> what
> I found at lua-users.org it seems like an interesting project. Seems
> a lot like a cleaner Python
Lua cannot do what Python does, and was not designed to. Lua is intended to
be a trivial configuration language, nothing more. It is not, for instance,
object oriented. It has gained a brand identity among game developers for
being 'fast' relative to other scripting options. This is partly
unjustified, as all scripting languages are slow compared to compiled code,
as benchmarks such as the following prove:
http://www.bagley.org/~doug/shootout/
http://dada.perl.it/shootout/
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
"Brandon J. Van Every" <·····························@yahoo.com> wrote in message news:<···············@ID-207230.news.uni-berlin.de>...
> It has gained a brand identity among game developers for
> being 'fast' relative to other scripting options. This is partly
> unjustified, as all scripting languages are slow compared to compiled code,
Although scripting (interpreted) language is slower than native
compiled code, scripting capability is quite handy for some type
of games (e.g. RPG, adventure, or even action game titles).
The production I know have been using in-house scripting language to
describe all stories and events in the very large volume RPG title
on consumer game consoles.
They are compiled to bytecode and interpreted at runtime. The reasons
to use a scripting language are:
- those who write event code aren't really programmers, but rather
game designers. they want to concentrate to storytelling than
programming aspects, so they prefer a language in which "programming"
parts are not very intrusive.
- they need quick turnaround time to check their scripts, so
they prefer byte-compiling & incremental-reloading to
recompiling, relinking and restarting.
Given this situation, I see usefulness of "fast" interpreted
languages.
However, if we can provide a development pipeline with a compiler
system that allows compiling and linking on-the-fly, that could be
a win. (Sounds like Lisp? Yes!)
The problem in the actual production is that you hardly have enough
manpower to create such a pipeline (NaughtyDog seems an exception
in this regard; I know another studio that tweaked gcc when a
new platform came, but it's a huge challenge to create entire
compiler suite).
Shiro Kawai wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> wrote in message
> news:<···············@ID-207230.news.uni-berlin.de>...
>> It has gained a brand identity among game developers for
>> being 'fast' relative to other scripting options. This is partly
>> unjustified, as all scripting languages are slow compared to
>> compiled code,
>
> Although scripting (interpreted) language is slower than native
> compiled code, scripting capability is quite handy for some type
> of games (e.g. RPG, adventure, or even action game titles).
I'm not speaking against the utility of scripting. Scripting is very useful
in game development. I'm speaking against the belief that the speed of the
scripting language matters, and that Lua has some tremendous advantage in
this regard. For the scripting jobs most people are currently undertaking
in the game industry, speed doesn't matter, and thus the choice of Python
vs. Lua should simply be whatever offers better functionality and ease of
use. For those people who think scripting speed *does* matter, they should
take a look at languages such as Lisp. The idea that scripting has to be
slow is a rather primitive programmatic notion. It will go away within 10
years.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
In article <···············@ID-207230.news.uni-berlin.de>, "Brandon J. Van
Every" <·····························@yahoo.com> wrote:
> The idea that scripting has to be
> slow is a rather primitive programmatic notion. It will go away within 10
> years.
Actually, IMO the idea that scripting and programming are distinct in any
way is a rather primitive notion and ought to go away. But I'm not
holding my breath.
E.
Erann Gat <·········@flownet.com> wrote:
+---------------
| "Brandon J. Van Every" <·····························@yahoo.com> wrote:
| > The idea that scripting has to be slow is a rather primitive
| > programmatic notion. It will go away within 10 years.
|
| Actually, IMO the idea that scripting and programming are distinct in
| any way is a rather primitive notion and ought to go away. But I'm not
| holding my breath.
+---------------
I suspect the popularity of that idea has come from a common misreading
of Ousterhout's paper <URL:http://home.pacbell.net/ouster/scripting.html>,
which, when read closely, does *not* actually separate scripting and
programming at all; rather, it distinguishes scripting LANGUAGES from
"system programming" LANGUAGES. Even in the paper's abstract it's clear
that it's all programming.
Another thing that tends to get overlooked in reading that paper is the
comment on Lisp near the end, where he says:
...there are many interesting languages that can't be characterized
cleanly as a system programming language or a scripting language.
For example, the Lisp family of languages lies somewhere between
scripting and system programming, with some of the attributes of
each. Lisp pioneered concepts such as interpretation and dynamic
typing that are now common in scripting languages, as well as
automatic storage management and integrated development environments,
which are now used in both scripting and system programming languages.
Personally, I've become quite happy using Common Lisp for "scripting",
particularly since, if there are some especially time-consuming functions,
it's so easy to compile them right there in the "script".
"Lisp: A scripting language with system programming language performance..."
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Erann Gat wrote:
> In article <···············@ID-207230.news.uni-berlin.de>, "Brandon
> J. Van Every" <·····························@yahoo.com> wrote:
>
>> The idea that scripting has to be
>> slow is a rather primitive programmatic notion. It will go away
>> within 10 years.
>
> Actually, IMO the idea that scripting and programming are distinct in
> any way is a rather primitive notion and ought to go away. But I'm
> not holding my breath.
We are saying essentially the same thing with different words and emphasis.
The computers are now good enough; it's the industrial practices which are
lacking.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed Mckenzie
From: Cameron MacKinnon
Subject: Re: Lua (was Re: What would you do with 10 Man Years?)
Date:
Message-ID: <9KadnWA1f4ED8vndRVn-tw@golden.net>
Brandon J. Van Every wrote:
> I'm not speaking against the utility of scripting. Scripting is very useful
> in game development. I'm speaking against the belief that the speed of the
> scripting language matters, and that Lua has some tremendous advantage in
> this regard. For the scripting jobs most people are currently undertaking
> in the game industry, speed doesn't matter, and thus the choice of Python
> vs. Lua should simply be whatever offers better functionality and ease of
> use. For those people who think scripting speed *does* matter, they should
> take a look at languages such as Lisp. The idea that scripting has to be
> slow is a rather primitive programmatic notion. It will go away within 10
> years.
"Scripting" used to be automating a series of commands that the sysadmin
would have otherwise typed by hand. Speed obviously wasn't an issue.
Somehow, in the time of CGI web programming, the term was co-opted to
mean writing dynamic web pages. Speed *usually* didn't matter, unless
your site got popular all of a sudden. Scripters, during the dot com
boom years, were fairly low in the technical hierarchy.
Then someone coined the phrase "script kiddie", a perjorative. As well,
Microsoft called their language for non-programmers "VBScript". The
effect of these last three is that the term "scripting language" isn't
exactly flattering. It seems to describe languages that are good for
lightweight tasks, but which will run out of steam if pushed too hard.
So to address your post, I'd say that if it isn't slow, it isn't a
scripting language. A generalization to be sure, but I feel that it
reflects current usage.
As to scripting speed not mattering in games, I wonder... Obviously the
most CPU intensive parts are elsewhere, but 1) gamers are notorious
performance freaks, griping over whether they get 140 frames/s or only
139, and 2) some consoles have very strong graphics hardware but
relatively anemic CPUs. This says to me that game developers can't
really afford to throw away cycles even in the parts that only eat 0.5% CPU.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
>
> So to address your post, I'd say that if it isn't slow, it isn't a
> scripting language. A generalization to be sure, but I feel that it
> reflects current usage.
Agreed. However, there are systems languages which are capable of handling
the tasks that scripting languages are typically put to, i.e. interpreted
programming. Lisp is an example.
> As to scripting speed not mattering in games, I wonder... Obviously
> the
> most CPU intensive parts are elsewhere, but 1) gamers are notorious
> performance freaks, griping over whether they get 140 frames/s or only
> 139, and 2) some consoles have very strong graphics hardware but
> relatively anemic CPUs. This says to me that game developers can't
> really afford to throw away cycles even in the parts that only eat
> 0.5% CPU.
You are simply incorrect. I would suggest you learn about game industry
practices if you care. The reality is, computers are pretty fast nowadays,
and game developers are usually pretty good at separating out the
performance critical tasks.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Trollhunt" - (n.) A searching out for persecution
of persons accused of Trolling. (c.f. witch-hunt)
From: Cameron MacKinnon
Subject: Lisp and Gaming (was Re: Lua (was Re: What would you do with 10 Man Years?))
Date:
Message-ID: <QvGdnSpW6ItKDfndRVn-tw@golden.net>
Brandon J. Van Every wrote:
> Cameron MacKinnon wrote:
>>As to scripting speed not mattering in games, I wonder...
> You are simply incorrect. I would suggest you learn about game industry
> practices if you care. The reality is, computers are pretty fast nowadays,
> and game developers are usually pretty good at separating out the
> performance critical tasks.
Where would you point me to to learn more?
I read the online ACM Queue last month, and that was pretty interesting.
It talked about game companies having to predict likely average
machine performance a year or three in advance, and having multiple
versions depending on the customer's CPU and graphics capability. One
guy was quoted as being disappointed that graphics performance was lower
than he thought we'd have by now, as compared to CPU speed; that
bolsters your assertion.
I was under the impression that games' AI was still on a pretty tight
CPU budget. No? Nowhere did I imply that game programmers were too
stupid to use code profilers, but if you have to limit the cycles given
to your search algorithms to maintain realtime performance, then
everything else is time-critical, in the sense that it steals cycles
from your AI.
Computers were pretty fast when I was a kid, they'll be pretty fast when
I'm dead, but never fast enough. The broad spread between a gamers'
dream machine and the lowly hardware that game publishers spec as
minimum is a challenge as well.
On a related note, for an example of the opposite of Lisp, see
http://www.zeroc.com/ - they do a lightweight CORBA replacement aimed at
MMORPG developers. The manual for it is full of explanations as to why
they don't support features that their customers obviously desire,
likewise with their online forums. I couldn't help thinking that it was
exactly the opposite of (Orbitz, Viaweb, can't remember which) who
copied competitors' features with one day turnaround, and fixed bugs
while the customer was still on the phone. The poor schmos at ZeroC are
quite obviously limited by their language, and their customers suffer
the consequences.
--
Cameron MacKinnon
Toronto, Canada
From: Pascal Bourguignon
Subject: Re: Lisp and Gaming (was Re: Lua (was Re: What would you do with 10 Man Years?))
Date:
Message-ID: <87lllnw5hg.fsf@thalassa.informatimago.com>
Cameron MacKinnon <··········@clearspot.net> writes:
> Computers were pretty fast when I was a kid, they'll be pretty fast
> when I'm dead, but never fast enough. The broad spread between a
> gamers' dream machine and the lowly hardware that game publishers spec
> as minimum is a challenge as well.
They'll be fast enough for game programmers and game players when
they'll be universes.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Larry Elmore
Subject: Re: Lisp and Gaming (was Re: Lua (was Re: What would you do with 10 Man Years?))
Date:
Message-ID: <Pr49c.102019$Cb.1284763@attbi_s51>
Pascal Bourguignon wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>>Computers were pretty fast when I was a kid, they'll be pretty fast
>>when I'm dead, but never fast enough. The broad spread between a
>>gamers' dream machine and the lowly hardware that game publishers spec
>>as minimum is a challenge as well.
>
>
> They'll be fast enough for game programmers and game players when
> they'll be universes.
Probably not even then. _This_ universe is sometimes way too damned slow
for my taste -- especially during staff meetings and commutes.
--Larry
From: Pascal Bourguignon
Subject: Re: Lisp and Gaming (was Re: Lua (was Re: What would you do with 10 Man Years?))
Date:
Message-ID: <87vfkrujny.fsf@thalassa.informatimago.com>
Larry Elmore <·········@_comcast_._net> writes:
> Pascal Bourguignon wrote:
> > Cameron MacKinnon <··········@clearspot.net> writes:
> >
> >>Computers were pretty fast when I was a kid, they'll be pretty fast
> >>when I'm dead, but never fast enough. The broad spread between a
> >>gamers' dream machine and the lowly hardware that game publishers spec
> >>as minimum is a challenge as well.
> > They'll be fast enough for game programmers and game players when
> > they'll be universes.
>
> Probably not even then. _This_ universe is sometimes way too damned
> slow for my taste -- especially during staff meetings and commutes.
But it's inside the rules of this universe that you can get out of
slow meetings and you can drive an helicopter instead of a car. Given
you have a score high enough. $-)
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Cameron MacKinnon wrote:
> Brandon J. Van Every wrote:
>> Cameron MacKinnon wrote:
>>> As to scripting speed not mattering in games, I wonder...
>
>> You are simply incorrect. I would suggest you learn about game
>> industry practices if you care. The reality is, computers are
>> pretty fast nowadays, and game developers are usually pretty good at
>> separating out the performance critical tasks.
>
> Where would you point me to to learn more?
comp.games.development.programming.misc
> I was under the impression that games' AI was still on a pretty tight
> CPU budget. No?
Yes it is. But if people care about the AI's performance, they usually use
C++.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed Mckenzie
Brandon J. Van Every wrote:
> For the scripting jobs most people are currently undertaking
> in the game industry, speed doesn't matter, and thus the choice of Python
> vs. Lua should simply be whatever offers better functionality and ease of
> use.
My understanding is that Lua may have an edge in terms of its footprint &
embeddability - and also possibly in the simplicity of the language, which
seems from the little I've looked at it to be smaller and have a somewhat
more orthogonal design than Python. It reminds me somewhat of Javascript.
For game scripting purposes, I imagine the full breadth and quirkality
(technical term) of Python might be unnecessary in many cases.
Anton
Anton van Straaten wrote:
> Brandon J. Van Every wrote:
>> For the scripting jobs most people are currently undertaking
>> in the game industry, speed doesn't matter, and thus the choice of
>> Python vs. Lua should simply be whatever offers better functionality
>> and ease of use.
>
> My understanding is that Lua may have an edge in terms of its
> footprint & embeddability -
Yes probably so.
> and also possibly in the simplicity of
> the language, which seems from the little I've looked at it to be
> smaller and have a somewhat more orthogonal design than Python. It
> reminds me somewhat of Javascript.
Python is easy. People who think Lua is easy but Python isn't are whiners.
It's slightly more difficult than Lua, maybe 1 day's additional use of the
brain. Python's ease-of-use is the main touted feature of the language. I
read an O'Reilley Python book and when I was done I said, "That's it?"
> For game scripting purposes, I
> imagine the full breadth and quirkality (technical term) of Python
> might be unnecessary in many cases.
Unnecessariness, yes, that has been cited to me recently by someone choosing
Lua over Python. But I think they're misguided and doomed to pursue
spaghetti "if..then" code until it hurts. Really people get into a
production mentality and then they won't change their minds. Not until the
project is over 18 months later.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed Mckenzie
Brandon J. Van Every wrote:
> Anton van Straaten wrote:
> > and also possibly in the simplicity of
> > the language, which seems from the little I've looked at it to be
> > smaller and have a somewhat more orthogonal design than Python.
> > It reminds me somewhat of Javascript.
>
> Python is easy. People who think Lua is easy but Python isn't are
whiners.
> It's slightly more difficult than Lua, maybe 1 day's additional use of the
> brain. Python's ease-of-use is the main touted feature of the language.
I
> read an O'Reilley Python book and when I was done I said, "That's it?"
I wasn't referring to easiness so much, as consistency and simplicity of
design, which also relates to the size of implementation issue which I
mentioned.
> Unnecessariness, yes, that has been cited to me recently by someone
> choosing Lua over Python. But I think they're misguided and doomed
> to pursue spaghetti "if..then" code until it hurts. Really people get
into
> a production mentality and then they won't change their minds. Not
> until the project is over 18 months later.
Except that Lua actually seems to have already been successful in a number
of real cases. I don't know enough about the requirements of game scripting
to comment further.
However, before assuming that Lua can't possibly fit some niche better than
Python, you might look at things like what Norman Ramsey at Harvard is doing
with it: he's implemented Lua in OCaml, and uses that for configuration of
the C-- compiler. See:
http://www.eecs.harvard.edu/~nr/activities.html#interp
Anton
Brandon J. Van Every wrote:
> Erann Gat wrote:
>
>>Never heard of it before, and lua.org seems to be down. But based on
>>what
>>I found at lua-users.org it seems like an interesting project. Seems
>>a lot like a cleaner Python
>
> Lua cannot do what Python does, and was not designed to. Lua is intended to
> be a trivial configuration language, nothing more. It is not, for instance,
> object oriented.
blablabla
It's very easy to build your own OO layer on top of Lua. It even has
hooks explicitly designed for such extensions.
> It has gained a brand identity among game developers for
> being 'fast' relative to other scripting options. This is partly
> unjustified, as all scripting languages are slow compared to compiled code,
> as benchmarks such as the following prove:
> http://www.bagley.org/~doug/shootout/
> http://dada.perl.it/shootout/
BTW, why do you think that ILM uses Python?
Pascal
P.S.: Another nice scripting language built on top of Lisp ideas is
Pico. See http://pico.vub.ac.be/
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza wrote:
>
> It's very easy to build your own OO layer on top of Lua. It even has
> hooks explicitly designed for such extensions.
Is this a case of first class quality engineering, or cruft ala "you can do
OO in C if you really want to?"
> BTW, why do you think that ILM uses Python?
Because Python excels as a process control language. See Python Success
Stories http://www.pythonology.org/success for numerous examples.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
Brandon J. Van Every wrote:
> Pascal Costanza wrote:
>
>>It's very easy to build your own OO layer on top of Lua. It even has
>>hooks explicitly designed for such extensions.
>
> Is this a case of first class quality engineering, or cruft ala "you can do
> OO in C if you really want to?"
What part of "explicitly designed for such extensions" is it that you
don't understand? You have to check on your own whether it meets your
specific criteria. Such things cannot be answered generally. IMHO,
there's no reason not to choose Common Lisp or Scheme for whatever
purpose, but I may have different criteria.
>>BTW, why do you think that ILM uses Python?
>
> Because Python excels as a process control language. See Python Success
> Stories http://www.pythonology.org/success for numerous examples.
So performance isn't the only critical aspect of a language
implementation? Gosh! ;)
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza wrote:
> Brandon J. Van Every wrote:
>> Pascal Costanza wrote:
>>
>>> It's very easy to build your own OO layer on top of Lua. It even has
>>> hooks explicitly designed for such extensions.
>>
>> Is this a case of first class quality engineering, or cruft ala "you
>> can do OO in C if you really want to?"
>
> What part of "explicitly designed for such extensions" is it that you
> don't understand?
The part that may depend upon your level of personal exaggeration.
> You have to check on your own whether it meets your specific criteria.
Either that or wait for second opinions.
>>> BTW, why do you think that ILM uses Python?
>>
>> Because Python excels as a process control language. See Python
>> Success Stories http://www.pythonology.org/success for numerous
>> examples.
>
> So performance isn't the only critical aspect of a language
> implementation? Gosh! ;)
You are seriously taking this into non-sequitor land.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
At Thu, 25 Mar 2004 20:33:08 -0800, Brandon J. Van Every <·····························@yahoo.com> wrote:
>
> Lua cannot do what Python does, and was not designed to. Lua is intended to
> be a trivial configuration language, nothing more. It is not, for instance,
> object oriented.
It has lexical closures and first class anonymous functions (something
Python lacks) which is enough to implement your own OO system even if
the language didn't provide one built-in (which Lua *does*).
Python cannot do what Lua does, and was not designed to. Python is
intended to be an object-oriented language, nothing more.
--
Alex
·········@flownet.com (Erann Gat) wrote in message news:<··························@k-137-79-50-101.jpl.nasa.gov>...
> Never heard of it before, and lua.org seems to be down. But based on what
> I found at lua-users.org it seems like an interesting project. Seems a
> lot like a cleaner Python with keywords instead of syntactically
> significant whitespace (but without a mapping of the surface syntax to
> S-expressions, which I really want so I can have CL-style macros). I'm
> pleasantly surprised that a project like LUA can get as much traction as
> it seems to have gotten given how similar it seems to be to Python.
I hope these projects do not underestimate Python. Apparently, Guido
took on Python as an interface project -- the unusual, apparently
redundant colons are actually there for a reason:
http://discuss.fogcreek.com/redirect.asp?http://www.python.org/tim_one/000573.html
Controversial but thoughtful; he seems to have an aesthetics that sees
merit in good irregularities.
It is not clear if it can be reproduced by someone who does not
respect the user as much. To be frank, "dumbed-down lisps" are doomed
for failure.
Arc seems interesting though; I hope they keep the syntax thing. And
Moon's comments are very interesting; I've wondered about supporting
better data types than cons cells for code, and AFAICT he's coming at
it from the angle of modularity.
·········@flownet.com (Erann Gat) wrote in message news:<··························@k-137-79-50-101.jpl.nasa.gov>...
> In article <···············@ID-197644.news.uni-berlin.de>, "Will Hartung"
>
> http://www.flownet.com/gat/ciel.pdf
>
Interesting reading. I would also take a look at comp.lang.pop, maybe
it has some inspiring qualities.
RolandOfAmerica
From: Julian Stecklina
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <861xnflrte.fsf@web.de>
·········@flownet.com (Erann Gat) writes:
> In article <···············@ID-197644.news.uni-berlin.de>, "Will Hartung"
> <·····@msoft.com> wrote:
>
>> Here's more of a strategic platform question.
>>
>> Simply put if you had 10 man years at your disposal, how would you allocate
>> it to advance Common Lisp?
>
> http://www.flownet.com/gat/ciel.pdf
The server refuses connections from me. Is there a copy somewhere
else?
Regards,
--
Julian Stecklina
Signed and encrypted mail welcome.
Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
Any sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
- Greenspun's Tenth Rule of Programming
Will Hartung wrote:
> Here's more of a strategic platform question.
>
> Simply put if you had 10 man years at your disposal, how would you
> allocate it to advance Common Lisp?
Take over game development. It isn't interesting unless it's a game. Most
of the game developers are still stuck in clunky C++ land because they're
afraid nothing else has decent performance. I would concentrate on
automagically wrapping up legacy C++ APIs such as DirectX, and erasing the
"2 language" model of C++ for heavy lifting, scripting languages for
flexible stuff. I would work on whatever increases programmer productivity.
Of course, since I'm a broke open source developer, I don't have 10 man
years to pursue this, nor do I need it. Nor am I sold yet that Lisp is the
right horse for this agenda. Currently I'm weighing Lisp vs. OCaml.
Incidentally I've decided that Python cannot solve this strategic problem.
Not until it fixes its performance problems. If PSF would get serious about
real world marketing, it would help a lot too. It may happen within the
next 3 years, but I'm in no mood to hold my breath.
I find your question interesting, because I've been mainly reviled on Usenet
for daring to have such strategic perspectives on languages, technologies,
and business models. It seems that if you are not some ideological open
source hippie who likes to download and play with programming toys all day
long, there's something wrong with you.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."
Will Hartung wrote:
> You could add threads to CLISP, say,
I don't think I'd do any work specific to one implementation, or any
work on the implementations at all. That is really only work that would
benefit the already convinced.
> Would updating the ANSI standard help?
I'd love to see the specs upgraded, but it seems that the community of
vendors/implementors, plus people who know enough for their technical
comments to be useful (not me!), is small enough that they could all
thrash it out on a new c.l.l.std for a year, IF there is the desire to
compromise (Please!). Subsidizing a "my API is better that yours" fight
seems less productive.
> Create a new LispOS from scratch? Lock 3 guys in a room with some hardware
> for 3 years, I'd like to think that could make a dent in that project.
I would think that creating an ethernet driver and a video card driver
for CMUCL would take less time than that. The thing to realize is that
by creating a new OS, you're insourcing device driver development, at
least until the hordes see the value and learn enough Lisp that they
write your drivers for you. Linux and Windows may represent "worse is
better" and "worse is worse", respectively, but at least you get the
device drivers for free.
> Finish MacCLIM?
Isn't Kenny our go-to guy for eye candy?
> Fancy print campaigns to "get the word out"?
SICP got the word out to a large number of people. Could another
textbook help?
Maybe you just want to write a bot that responds with variations on
"Lisp can do that, here's how..." in various newsgroups, Slashdot,
bulletin boards, etc. After all, posters seem to ask the same
predictable questions over and over. Do for neophyte programmers what
AliceBot did for jaded chat users?
> But if given essentially Carte Blanche to "Advance the CL platform", where
> would your nickles go?
Amazing applications impress programmers, many of whom will want to know
"How did they do that?" You have to pick your applications carefully,
because anything that can be done easily in a static language isn't
likely to impress the hordes much. Multipliers that allow 1 coder to
generate (not write) lots of code should impress.
When Java first came out, the things that impressed me the most were the
promise of cross platform GUI and the sandbox security model.
Things we can count on (2-10 year horizon):
Global network connectivity ubiquity, at 1-10Mb/s
Local storage and CPU cycles available are increasing
Latency to RAM, disk, net gets worse, relative to CPU speed
People/governments will want to snoop protocols
Eye candy impresses
How about working with one or more of the big video card manufacturers
to put Lisp hardware into their graphics chips? They get a better
language to drive the high level aspects of rendering, game writers get
more power on the "right" side of a bus which is often a bottleneck, and
people like me get a freakin' fast Lisp machine for $200.
If the above seems like vague, blue-sky handwaving, then I've answered
the OP ;-)
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> Will Hartung wrote:
> > You could add threads to CLISP, say,
>
> I don't think I'd do any work specific to one implementation, or any
> work on the implementations at all. That is really only work that would
> benefit the already convinced.
Besides CMUCL / SBCL.
> > Create a new LispOS from scratch? Lock 3 guys in a room with some hardware
> > for 3 years, I'd like to think that could make a dent in that project.
>
> I would think that creating an ethernet driver and a video card driver
> for CMUCL would take less time than that. The thing to realize is that
> by creating a new OS, you're insourcing device driver development, at
> least until the hordes see the value and learn enough Lisp that they
> write your drivers for you. Linux and Windows may represent "worse is
> better" and "worse is worse", respectively, but at least you get the
> device drivers for free.
Windows port for SBCL
Windows/Unix low-level drivers for SBCL (which will eventually leed to a LispOS)
A high-level GUI cross-platform interface, not necessarely McCLIM.
--
rurban
Cameron MacKinnon <··········@clearspot.net> writes:
>> Finish MacCLIM?
>
> Isn't Kenny our go-to guy for eye candy?
Possibly. Compare and contrast
<http://www.tilton-technology.com/cello-fg1.jpg> with
<http://www.common-lisp.net/project/gsharp/blomsteroffret.png> and see
if you don't develop a little less of a sweet tooth.
:-)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>
>>>Finish MacCLIM?
>>
>>Isn't Kenny our go-to guy for eye candy?
>
>
> Possibly. Compare and contrast
> <http://www.tilton-technology.com/cello-fg1.jpg> with
> <http://www.common-lisp.net/project/gsharp/blomsteroffret.png> and see
> if you don't develop a little less of a sweet tooth.
You got something against children?
:)
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Cameron MacKinnon wrote:
> Isn't Kenny our go-to guy for eye candy?
And you better have the crew lash you to the mast, OpenAL should come on
line this weekend to deliver music to soothe the savage cll beast.
Can any of you yo-yos guess what music will accompany the Cello splash
screen?
:)
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> Can any of you yo-yos guess what music will accompany the Cello splash
> screen?
Fanfare for the Common Man?
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> Kenny Tilton wrote:
>
>> Can any of you yo-yos guess what music will accompany the Cello splash
>> screen?
>
>
> Fanfare for the Common Man?
Gawdy, pretentious... perfect! Yo-yo Ma covered that?
:)
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
"Will Hartung" <·····@msoft.com> wrote in message news:<···············@ID-197644.news.uni-berlin.de>...
> Here's more of a strategic platform question.
>
> Simply put if you had 10 man years at your disposal, how would you allocate
> it to advance Common Lisp?
I will understand your question as "how to make it more popular". Here
is my
answer:
- Most programming today is putting together glue code for existing
Objects/API.
- That's why a language like Java is successfull, although being
simple and restricted.
- The popularity of the language is related to the size of the
existing APIs and
libraries that it offers. This is what makes programming easy.
- In the above scenarios the power of lisp makes little difference
because you
are only glueing code.
- Most programmer won't bother learning a strange-looking language
like lisp.
So what could make lisp more popular? Write a lisp system with all
those APIs,
that everyone uses and needs all the time. Or even better, enable lisp
to interact with Java(C# ...).
The good thing is, that this has already been done for Scheme, because
there
are Scheme implementations that run on the JVM.
The bad news is, that it won't make a difference for most programmers,
because
they don't want to learn a new language, and the power of lisp makes
little
difference in simple projects.
RolandOfAmerica
Will Hartung wrote:
> Here's more of a strategic platform question.
>
> Simply put if you had 10 man years at your disposal, how would you allocate
> it to advance Common Lisp?
- Let them carry out an empirical study what the most widely used
libraries and idioms are that have been established in the past two
decades, describe those libraries and idioms in a way that is consistent
with the specification standards set forth in ANSI CL, and then install
an SRFI-like process and use the results of that study as a starting point.
- Work on ideas how to turn Common Lisp into a multi-language platform.
Implement languages like Python, Ruby and Java as surface languages on
top of Common Lisp. In other words, take the vision of .NET and do it right.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
"Will Hartung" <·····@msoft.com> writes:
> Simply put if you had 10 man years at your disposal, how would you
> allocate it to advance Common Lisp?
Firstly, in terms of budgeting, I would prefer to spend your money
quickly rather than slowly; while the man year might be a mythical
thing, I think advancing CL's "cause" (whatever that means) is
probably best served at this point by rapid progress (whatever that
means) than a slower path to the same point.
What are we talking about, though, when we talk about "advancing
Common Lisp"? To an extent, this is a question I don't really
understand. I can use Common Lisp to my heart's desire, because it is
a tool; in a sense, the question is a little like asking how one could
advance computers, or screwdrivers. I understand that there are
worlds out there where people are expected to solve problems, and yet
aren't given a free choice of tools for solving those problems; to be
honest, I'm not particularly interested in dealing with that issue, so
I'm going to interpret your question as asking how I think people can
turn CL into a tool for solving difficult problems better than it
currently does, rather than asking how to solve perceptions _about_
the language and its environments.
To do this, I would find a few people (say five, in our hypothetical
world) who both have a proven record of good quality in some,
preferably several facets of Lisp technology (compilers or development
environments, library specification and/or implementation[*],
application development, middleware components, whatever, but ideally
at least two of these each), ask them to relocate to a centre where
Lisp is currently being used (in academia, I can name Bordeaux's
LaBRI, Paris' IRCAM, and (London) City University's Centre for
Computational Creativity for starters without really thinking; various
labs in industry are probably candidates as well -- it's a bit of a
shame that AT&T labs in Cambridge closed down, but Microsoft Research
could be accomodating, or a friendly Frenchman could talk to INRIA
nicely, or whatever) and encourage these people as much as possible to
free their minds from some (not all!) of their worldly concerns (you'd
be paying their salaries for two years, after all) and look at some of
the issues you raised -- or simply go wherever their interest lies.
[*] Tim Bradshaw may say that no-one comes into this category.
One which you didn't was infrastructure for distribution of portable
or semi-portable code; volunteer labour has given us
common-lisp-controller and asdf-install, but I think it's fair to say
that both of those have a fairly high impedance mismatch. Of course,
since it has been stated here that this problem isn't actually hard
and a good solution could be found in one man-week, this may not take
so long, in which case, good -- all the more time for harder stuff.
What do I think this kind of environment would achieve? Well, partly,
it might increase awareness that Lisp still exists, still breathes,
among the trade. I would expect that in addition to competence in
Lisp specifically, these people would have other interests and would
partly be working on making these other interests more tractable to
deal with -- whether that's in automatic musical indexing,
computer-aided art, redundant networking, typography, symbolic
algebra, visualisation aids, graphical user interface building,
artificial opponents in complex games, or just plain something I
haven't thought of; in addition, I'd have thought that even a good
partial result, let alone a complete solution, would be worth talking
to others about in its own right, because in quite a lot of the fields
I mentioned, or at least subfields thereof, there are no good partial
results beyond the ad-hoc.
Maybe I'm saying we should quit resting on our laurels? In any case,
I don't know if what would follow from all this activity would be a
golden age in which everyone who has ever typed a parenthesis will be
in demand in industry, or even whether funding would be renewed after
two years... but I'd be surprised if some interest didn't result.
> Finish MacCLIM?
Just a note -- I'm sure one of the McCLIM developers might want to say
something here, but I don't think it would take 10 man-years to
"finish" McCLIM by any means. It might take a little while to polish
it up to Scott McKay's standards, but even that I think is not a
multiple man-year project. While underestimating the difficulty of
certain things isn't necessarily ideal, there seems to be a kind of
paralysis sometimes from overestimating difficulties, costs, and the
like.
> (And no, I don't have $1M burning a hole in my pocket...it's a
> completely speculative question.)
That's a shame. Anyone listening? :-)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> > Finish MacCLIM?
>
> Just a note -- I'm sure one of the McCLIM developers might want to say
> something here, but I don't think it would take 10 man-years to
> "finish" McCLIM by any means. It might take a little while to polish
> it up to Scott McKay's standards, but even that I think is not a
> multiple man-year project.
I pretty much agree. Though, there is some interesting
open-endedness in the specification, such as half a page
talking about a "text-editor" gadget.
> While underestimating the difficulty of
> certain things isn't necessarily ideal, there seems to be a kind of
> paralysis sometimes from overestimating difficulties, costs, and the
> like.
While this sounds right to me, I could not think of any concrete
examples. Did you have any examples in mind.
--
Robert Strandh
----- Original Message -----
From: "Robert STRANDH" <·······@labri.fr>
Newsgroups: comp.lang.lisp
Sent: Friday, March 26, 2004 1:23 AM
Subject: Re: What would you do with 10 Man Years?
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > > Finish MacCLIM?
> >
> > Just a note -- I'm sure one of the McCLIM developers might want to say
> > something here, but I don't think it would take 10 man-years to
> > "finish" McCLIM by any means. It might take a little while to polish
> > it up to Scott McKay's standards, but even that I think is not a
> > multiple man-year project.
>
> I pretty much agree. Though, there is some interesting
> open-endedness in the specification, such as half a page
> talking about a "text-editor" gadget.
Yeah, specs and standards are funny things, I've found.
- Sometimes you want to make things really, really clear so
that everyone does exactly the same thing
- Sometimes you want to make things rather vague, so that
multiple existing systems can "conform"
- Sometimes the author doesn't really know what he's talking
about, but wants to leave a place-holder
The "text editor" gadget falls pretty squarely into the third class.
The DUIM <text-editor> gadget ended up having very much the
same API as the simpler <text-field> gadget, but it's not exactly
the same. The <text-field> gadget was rich enough to support
Windows text boxes. The <text-editor> gadget was rich enough
to support "Deuce", a full-strength program text-editor.
BTW, I think if MacCLIM gets "most things" working "pretty
darned well", that makes for a compelling story. If I happen
to quibble, well, the MacCLIM'ers can tell me to piss off!
> > While underestimating the difficulty of
> > certain things isn't necessarily ideal, there seems to be a kind of
> > paralysis sometimes from overestimating difficulties, costs, and the
> > like.
>
> While this sounds right to me, I could not think of any concrete
> examples. Did you have any examples in mind.
>
> --
> Robert Strandh
In article <·····················@attbi_s02>,
"Scott McKay" <···········@comcast.net> wrote:
> ----- Original Message -----
> From: "Robert STRANDH" <·······@labri.fr>
> Newsgroups: comp.lang.lisp
> Sent: Friday, March 26, 2004 1:23 AM
> Subject: Re: What would you do with 10 Man Years?
>
>
> > Christophe Rhodes <·····@cam.ac.uk> writes:
> >
> > > > Finish MacCLIM?
> > >
> > > Just a note -- I'm sure one of the McCLIM developers might want to say
> > > something here, but I don't think it would take 10 man-years to
> > > "finish" McCLIM by any means. It might take a little while to polish
> > > it up to Scott McKay's standards, but even that I think is not a
> > > multiple man-year project.
> >
> > I pretty much agree. Though, there is some interesting
> > open-endedness in the specification, such as half a page
> > talking about a "text-editor" gadget.
>
> Yeah, specs and standards are funny things, I've found.
> - Sometimes you want to make things really, really clear so
> that everyone does exactly the same thing
> - Sometimes you want to make things rather vague, so that
> multiple existing systems can "conform"
> - Sometimes the author doesn't really know what he's talking
> about, but wants to leave a place-holder
>
> The "text editor" gadget falls pretty squarely into the third class.
>
> The DUIM <text-editor> gadget ended up having very much the
> same API as the simpler <text-field> gadget, but it's not exactly
> the same. The <text-field> gadget was rich enough to support
> Windows text boxes. The <text-editor> gadget was rich enough
> to support "Deuce", a full-strength program text-editor.
>
> BTW, I think if MacCLIM gets "most things" working "pretty
> darned well", that makes for a compelling story. If I happen
> to quibble, well, the MacCLIM'ers can tell me to piss off!
Scott, it is McCLIM. ;-) sorry ;-)
Though it also runs under OpenMCL on a Mac. ;-)
(see the smilies ;-) )
Will Hartung wrote:
> Here's more of a strategic platform question.
>
> Simply put if you had 10 man years at your disposal, how would you allocate
> it to advance Common Lisp?
>
> I originally framed this as $1,000,000, which can be argued as "10 man
> years", but I didn't want folks to quibble about salaries and taxes and
> crap.
I would invest it in IZware with some provisions that they continue to
use CL (I assume they already do). http://www.izware.com
My son (who is 10 years old) has used their Nendo product to do 3D modelling/
drawing for a couple of years now. I think there is an untapped market for
kids like mine. It's amazing what he can produce, IZware did a great job in
creating such an easy to use tool.
Wade
Well, the first task would be to guestimate what the priorities of
programmers will be in ten years...
...as a reformed C/C++ coder, I wouldn't be surprised if a lot of the
C/C++ community will be transitioning to other languages around then-
Currently, I would argue there are two main draws for C/C++:
1. Speed
2. Power (from libraries/language features)
I think both of these draws are going to weaken over the next decade:
Raw speed keeps becoming less critical. For instance, the game
developers have all pretty much transitioned away from asm in the last
few years, and I think C/C++ will befall a similar fate eventually.
And in terms of "power", many C/C++ coders are starting to notice that
other languages such as Java/C#/etc are developing quite respectable
libraries and that "template metaprogramming" is not in fact the
end-all of computer science sophistication, as Python/Lisp/Perl/ML are
becoming more well-known.
Clearly, other companies are banking on this belief as well, as the
syntax of Java/C# are designed specifically to entice the C/C++ crowd.
So in order to improve the success of CL in the near future, I think
the critical goal would be to entice as much of the C/C++ crowd as
possible to take a leap into lisp. The following (rambling) ideas come
to mind in helping towards this goal:
1. Ease of end user installation/simplification the development stack-
C/C++ programmers love that they can just take an ASCII file, run it
through a compiler, and BAM! instant fully self-contained executable
application. If you built a lisp that could just operate through a
website, you could make it even "cleaner": Build a development IDE
that functions through a browser window, so that noone has to ever set
up a Lisp dev machine- Execute the code through the browser through a
lightweight VM (JAVA or in ten years maybe parrot or some other
open-source VM) and end user installation/ development box setup would
be super easy! (not that these things are hard now, its just that they
are not as simple currently as the ASCII file + GCC = EXE equation...)
- the cirCLe CD I think was already a good step in the ease-of-use
direction...
2. C/C++ isn't great for web development. Make Lisp strengths even
stronger in this area if possible. Somehow make it EVEN EASIER to do
XML through sexps, make it EVEN EASIER to do HTML building with lisp
quasiquote magic. And add additonal features to CL that can help in
web dev. *cough* continuations *cough*. Currently, the PLT folks have
the lead in web development for LISPs, I would say, because DrScheme
just makes these things look so EASY.
3. No language has really figured out how to make refactoring of old
source code in fundamental ways any less painful. Lisp sexp should
allow for a natural advantage in this area- And the many C/C++
programmers would learn ANY language that solves this problem, as they
are all-to-familiar with the torture of patching legacy code.
Oh, and do something that will make people notice that Lisp
programming is just COOL. If anyone could get Lisp into a movie or
into an iPod or onto the next white stripes album it would take of
instantly :)
Conrad Barski wrote:
> Well, the first task would be to guestimate what the priorities of
> programmers will be in ten years...
Why 10 years? Why not right now?
> ...as a reformed C/C++ coder, I wouldn't be surprised if a lot of the
> C/C++ community will be transitioning to other languages around then-
> Currently, I would argue there are two main draws for C/C++:
>
> 1. Speed
> 2. Power (from libraries/language features)
I agree.
> 2. C/C++ isn't great for web development. Make Lisp strengths even
> stronger in this area if possible.
C/C++ programmers *aren't doing* web development. C++ programmers who want
to do web development move to Java or C# - languages that are essentially
"cleaned up" C++. C++ programmers are doing systems programming, high
performance number crunching, device drivers, embedded systems, and legacy
coding. If you want to capture web developers, you have to go after Java or
C# adherants, not C++ adherants.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> C/C++ programmers *aren't doing* web development. C++ programmers who want
> to do web development move to Java or C# - languages that are essentially
> "cleaned up" C++. C++ programmers are doing systems programming, high
> performance number crunching, device drivers, embedded systems, and legacy
> coding. If you want to capture web developers, you have to go after Java or
> C# adherants, not C++ adherants.
That's not entirely true. C and C++ surely aren't dominant in web
development, but they're certainly used. Some web apps are written as
Apache modules, often in C. On the inside, Apache is essentially a
nice web framework for C. And it looks like newer versions finally
support C++ in the modules (which had been hacked in independantly
several times, but there wasn't a mod_c++ in Apache until fairly
recently).
Of course, I'd be surprised if there was much use of C or C++ on the
web outside of statistics, image processing, or other similar
number-crunching domains.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
> C/C++ programmers *aren't doing* web development. C++ programmers who want
> to do web development move to Java or C#
Right. They're moving to Java and C# as we speak, and will continue to
do so over the next 10 years as web development is becoming harder and
harder to avoid...
...and we might be able to tempt them to move to lisp instead of
Java/C#.
Those who use java/c# have little pressure to switch platforms in the
near future and would be more difficult to interest in Lisp, I would
argue.
> ...as a reformed C/C++ coder, I wouldn't be surprised if a lot of the
> C/C++ community will be transitioning to other languages around then-
As one of the same, I agree.
> many C/C++ coders are starting to notice that
> other languages such as Java/C#/etc are developing quite respectable
> libraries and that "template metaprogramming" is not in fact the
> end-all of computer science sophistication, as Python/Lisp/Perl/ML are
> becoming more well-known.
I think the template-metaprogramming furor might attract a lot of
coders to Lisp. The STL, Boost, and Loki clearly show that there is a
demand for the advanced features present in Lisp (and its cousins).
They might not necessarily be able to put a name to the feature they
want "gee, I wish I could use for_each() without writing a function
object class every time" but when they see those things in Lisp, I
think they'll immediately recognize their value.
·······@mindspring.com (Rayiner Hashem) writes:
> I think the template-metaprogramming furor might attract a lot of
> coders to Lisp. The STL, Boost, and Loki clearly show that there is a
> demand for the advanced features present in Lisp (and its cousins).
> They might not necessarily be able to put a name to the feature they
> want "gee, I wish I could use for_each() without writing a function
> object class every time" but when they see those things in Lisp, I
> think they'll immediately recognize their value.
For what it is worth, this is exactly what brought me to lisp about a year
ago. Having done some nontrivial expression template and template
metaprogramming for numerical simulations in C++, I found out exactly how
painful it can be. The whole purpose having been to add some flexibilty to
what is a pretty 'stiff' language, I was left thinking 'There has to be a
better way.''
Turns out there is ;)
Simon
Rayiner Hashem wrote:
> I think the template-metaprogramming furor might attract a lot of
> coders to Lisp. The STL, Boost, and Loki clearly show that there is a
> demand for the advanced features present in Lisp (and its cousins).
> They might not necessarily be able to put a name to the feature they
> want "gee, I wish I could use for_each() without writing a function
> object class every time" but when they see those things in Lisp, I
> think they'll immediately recognize their value.
Right. As soon as I wrapped my head around macros, the light went off. I
finally got it. The fact that "compile time" exists with the full power of
Lisp there to manipulate it is huge.
--
Dave Roberts
·············@re-move.droberts.com
Many forget that read eval provides much of this power too.
Just wrote this.
> (prefix "(122/4+2)*(456-35)")
(* (+ (/ 122 4) 2) (- 456 35))
> #.(prefix "(122/4+2)*(456-35)")
27365/2
pretty neat!
On Sun, 28 Mar 2004 08:46:25 GMT, Dave Roberts
<·············@re-move.droberts.com> wrote:
> Rayiner Hashem wrote:
>
>> I think the template-metaprogramming furor might attract a lot of
>> coders to Lisp. The STL, Boost, and Loki clearly show that there is a
>> demand for the advanced features present in Lisp (and its cousins).
>> They might not necessarily be able to put a name to the feature they
>> want "gee, I wish I could use for_each() without writing a function
>> object class every time" but when they see those things in Lisp, I
>> think they'll immediately recognize their value.
>
> Right. As soon as I wrapped my head around macros, the light went off. I
> finally got it. The fact that "compile time" exists with the full power
> of
> Lisp there to manipulate it is huge.
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Marco Baringer
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <m21xnfihj9.fsf@bese.it>
·····················@yahoo.com (Conrad Barski) writes:
> 2. C/C++ isn't great for web development. Make Lisp strengths even
> stronger in this area if possible. Somehow make it EVEN EASIER to do
> XML through sexps, make it EVEN EASIER to do HTML building with lisp
> quasiquote magic. And add additonal features to CL that can help in
> web dev. *cough* continuations *cough*. Currently, the PLT folks have
> the lead in web development for LISPs, I would say, because DrScheme
> just makes these things look so EASY.
*cough* uncommon web *cough*
you want XML/HTML? done. hell, we've got _executable_ xhtml templates,
who wants xslt when you've got lisp.
you want continuations? done. (more or less)
you want a component based UI? done.
you want it to compile to native machine code? done. (kudos to cmucl,
sbcl and openmcl).
you want to develop on remote systems? done. (kudos to slime)
you want a web inspectable backtrace? done. (kudos to slime)
you want a web based repl? done.
you want built-in i18n and l10n? done. (kudos to ICU)
you want to run it through apache _or_ a pure lisp web server?
done. (kudos to mod_lisp and portableaserve)
so, you want to help? http://common-lisp.net/project/ucw/
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
> *cough* uncommon web *cough*
That CPS transformer sounds cool... I haven't had a chance to look at
it yet... Is it more flexible than Paul Grahams' CPS transformation
macros? I found those somewhat difficult to work with...
> you want it to compile to native machine code? done. (kudos to cmucl,
> sbcl and openmcl).
...and they do this very well- I would just argue that "joe C++" is
used to the simplicity of the "standalone exe" concept... and I'm not
saying that the open Lisps need this feature, just that the easier
development/installation of apps becomes (in whatever ways this may
be) the more "Joe C++" will be interested in Lisp.
> you want XML/HTML? done. hell, we've got _executable_ xhtml templates,
> who wants xslt when you've got lisp.
Exactly. These are the kinds of things lisp is so great at and the
more accessible they can be made the more other programmers will be
interested in lisps.
> so, you want to help? http://common-lisp.net/project/ucw/
...I was just writing down some thoughts in response to an email
asking the lisp community what parts of lisp could benefit most from
new development- Should I be doing more for the community to make
improvements possible? Probably...
From: Marco Baringer
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <m2r7vee5zk.fsf@bese.it>
·····················@yahoo.com (Conrad Barski) writes:
>> *cough* uncommon web *cough*
>
> That CPS transformer sounds cool... I haven't had a chance to look at
> it yet... Is it more flexible than Paul Grahams' CPS transformation
> macros? I found those somewhat difficult to work with...
you can use graham's macros in any code you want if you're willing to
write your code in quasi-cps style (the bind= macro must be in a
"tail" position). uncommon web's cps transformer allows you to write
the code just like you would normally but has three issues:
1) you can't grab a continuation which spans call stacks.
2) you get errors and warnings like this one:
;Compiler warnings :
; Undeclared free variable #:G6732, in an anonymous lambda form inside an anonymous lambda form inside an anonymous lambda form inside an anonymous lambda form inside an anonymous lambda form.
this makes debugging "interesting".
3) you can't use all of common lisp. no unwind-protect (so no
with-output-to-file either), no progv, no catch/throw and no
multiple values. i consider this last item a bug which i'd like to
fix (sooner or later).
Basically the CPS transformer is just enough to be able to write page
flow logic in a web app linearly, however it does that quite well and
doesn't require people to wrap their heads around continuations to use
it.
>> you want it to compile to native machine code? done. (kudos to cmucl,
>> sbcl and openmcl).
>
> ...and they do this very well- I would just argue that "joe C++" is
> used to the simplicity of the "standalone exe" concept... and I'm not
> saying that the open Lisps need this feature, just that the easier
> development/installation of apps becomes (in whatever ways this may
> be) the more "Joe C++" will be interested in Lisp.
once upon a time i did some part time work in a university lab helping
people do the examples in a data structures and algorithms class. the
whole hedaer vs source vs object vs executable caused some major
headaches for people who'd never programmed before. the "standalone
exe" concept isn't "standalone" nor "simple" and it's a real shame
that this is what people consider simple.
the only thing the current implementations can't do is provide a
single file to put in /usr/bin, but, imho, this is a minuscule subset
of programs people want. what the current common lisp implementations
can do is provide you with the runtime and an image which runs your
app, pasting these two things together is trivial. On MacOS X you can
even use Bosco (http://evins.net/weblog) to produce double clickable
.app bundles.
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer wrote:
> ·····················@yahoo.com (Conrad Barski) writes:
>
>
>>2. C/C++ isn't great for web development. Make Lisp strengths even
>>stronger in this area if possible. Somehow make it EVEN EASIER to do
>>XML through sexps, make it EVEN EASIER to do HTML building with lisp
>>quasiquote magic. And add additonal features to CL that can help in
>>web dev. *cough* continuations *cough*. Currently, the PLT folks have
>>the lead in web development for LISPs, I would say, because DrScheme
>>just makes these things look so EASY.
>
>
> *cough* uncommon web *cough*
>
> you want XML/HTML? done. hell, we've got _executable_ xhtml templates,
> who wants xslt when you've got lisp.
>
> you want continuations? done. (more or less)
>
> you want a component based UI? done.
>
> you want it to compile to native machine code? done. (kudos to cmucl,
> sbcl and openmcl).
>
> you want to develop on remote systems? done. (kudos to slime)
>
> you want a web inspectable backtrace? done. (kudos to slime)
>
> you want a web based repl? done.
>
> you want built-in i18n and l10n? done. (kudos to ICU)
>
> you want to run it through apache _or_ a pure lisp web server?
> done. (kudos to mod_lisp and portableaserve)
>
> so, you want to help? http://common-lisp.net/project/ucw/
>
You mean it's not? done.
<g>
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Joe Marshall
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <smfvbdgy.fsf@comcast.net>
·····················@yahoo.com (Conrad Barski) writes:
> Currently, I would argue there are two main draws for C/C++:
>
> 1. Speed
> 2. Power (from libraries/language features)
Too bad that C/C++ don't actually have these features.
--
~jrm
From: André Thieme
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <c42j4j$rsa$1@ulric.tng.de>
Joe Marshall wrote:
> ·····················@yahoo.com (Conrad Barski) writes:
>
>
>>Currently, I would argue there are two main draws for C/C++:
>>
>>1. Speed
>>2. Power (from libraries/language features)
>
>
> Too bad that C/C++ don't actually have these features.
Sometimes I think it is not very important that a language actually has
some special features. It seems to me that it is important that a
majority of users /thinks/ it has those featurs.
Andr�
--
Joe Marshall wrote:
> ·····················@yahoo.com (Conrad Barski) writes:
>
>> Currently, I would argue there are two main draws for C/C++:
>>
>> 1. Speed
>> 2. Power (from libraries/language features)
>
> Too bad that C/C++ don't actually have these features.
It has speed.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed Mckenzie
Brandon J. Van Every wrote:
> Joe Marshall wrote:
>
>>·····················@yahoo.com (Conrad Barski) writes:
>>
>>>Currently, I would argue there are two main draws for C/C++:
>>>
>>>1. Speed
>>>2. Power (from libraries/language features)
>>
>>Too bad that C/C++ don't actually have these features.
>
> It has speed.
A language can't "have" speed. Only the programs written with it. Since
it is very hard to accomplish program generation in C/C++, it's harder
to write efficient programs in those languages on a large scale.
Consider the Interpreter pattern from the Design Patterns book (Gamma et
al. '95). They don't even mention the idea that one could use a compiler
for an embedded language instead of an interpreter.
The widely held assumption that C/C++ are efficient languages comes from
the fact that their basic language constructs are close to the
abstractions provided by the hardware. But it's relatively easy to
accomplish the same degree of closeness with program generators built in
any language. Real power comes from being able to seamlessly embed
program generators in a language.
It's better to start from a flexible language and optimize the
performance-critical parts of a program later on than start from a
supposedly efficient but inflexible language that makes evolving the
program in any direction very hard.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza wrote:
> Brandon J. Van Every wrote:
>
>> Joe Marshall wrote:
>>
>>> ·····················@yahoo.com (Conrad Barski) writes:
>>>
>>>> Currently, I would argue there are two main draws for C/C++:
>>>>
>>>> 1. Speed
>>>> 2. Power (from libraries/language features)
>>>
>>> Too bad that C/C++ don't actually have these features.
>>
>> It has speed.
>
> A language can't "have" speed. Only the programs written with it.
You have peculiar notions of speed if you think a language can't have it.
Although it is possible to cripple your performance in any language, when
one writes straightforward, optimizeable code, different languages
definitely do show differences in speed for things like floating point
execution, function call dispatch, memory footprint, etc. To be more
precise, these are properties of the compilers and interpreters, but
benchmarks show that language technologies tend to clump in certain places
at certain times, i.e. you can look at what's currently the best readily
available compiler technology.
> Since it is very hard to accomplish program generation in C/C++, it's
> harder to write efficient programs in those languages on a large
> scale.
So what? Industry proves that it is accomplished nevertheless, and many
programs are not large scale. Just as a language can be fast or slow, for
any given task it can be more or less productive for the programmer.
> The widely held assumption that C/C++ are efficient languages comes
> from the fact that their basic language constructs are close to the
> abstractions provided by the hardware.
Yep. It's pretty easy to write C/C++ code that's one-for-one with ASM
statements. Also the inlining of ASM code is idiomatic in the X86 world,
wherever there's a hole.
> But it's relatively easy to
> accomplish the same degree of closeness with program generators built
> in any language.
If that were actually true, MSVC++ and g++ compiler ASM output wouldn't be
so bad on the X86.
> Real power comes from being able to seamlessly embed
> program generators in a language.
You can argue about the power of such approaches all you like. The reality
is, C++ code is fast when coded by someone who understands ASM on her given
platform. It is also pretty fast in a lot of cases where people aren't
trying to understand ASM at all. You're welcome to peruse the following
benchmarks to your heart's content:
http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html
http://www.bagley.org/~doug/shootout/
http://dada.perl.it/shootout/
> It's better to start from a flexible language and optimize the
> performance-critical parts of a program later on than start from a
> supposedly efficient but inflexible language that makes evolving the
> program in any direction very hard.
That's an opinion on how to pursue software engineering, not a statement of
fact. For instance, if you have abundant cheap labor and the product has a
throwaway aspect to it, you may not care about long-term evolution of
anything. This circumstance often happens in game development, good
practice or not.
Interesting as this subject is, I'm going to decline further debate and
unsubscribe from c.l.l. Some other life pressures are asserting themselves
prominently at this time,and I can no longer afford debates on unimportant
issues.
I've decided against Lisp not for reasons of speed, but for reasons of
availability and support tools. At the present time I would need an open
source compiled Lisp on Windows (i.e. no funds), and none is available. Nor
are 30 day free trials enough time. Once I do rectify my funding problems,
price is a barrier to getting other Windows open source developers to give
Lisp a serious try. Far more important, I am dismayed at the lack of C++
migration tools. This an unacceptable cramp in a C++ coder's style, as all
sorts of industrial APIs will continue to be written in C++ and not Lisp for
the foreseeable future. Also there doesn't seem to be much of a standards /
packaging / convenience culture in the Lisp world, it seems quite
Balkanized.
Contrast this to OCaml, where I can just download stuff and get at it. Also
OCaml has "imperative comfort features" for C++ turncoats; not so important
to me, but useful as I try to get other C++ coders to adopt it. SWIG
supports OCaml, doesn't support Lisp. So, I'm going to start marching in
the OCaml direction, and keep marching until it fails me somehow. Maybe it
won't.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed Mckenzie
On Sat, 27 Mar 2004 11:48:06 -0800, "Brandon J. Van Every" <·····························@yahoo.com> wrote:
> I've decided against Lisp not for reasons of speed, but for reasons
> of availability and support tools. At the present time I would need
> an open source compiled Lisp on Windows (i.e. no funds), and none is
> available. Nor are 30 day free trials enough time.
There are three commercial Lisps available for Windows and none of
them has a trial version which is restricted to a 30 day period.[1]
Looks like you didn't do your homework very well...
Edi.
[1] With the exception of the Corman Lisp IDE. You can replace it with
Emacs and use the compiler as long as you like.
Naw, but they are hobbled.
Liquid lisp concs out after an hour's (?) use.
Allegro sets limits on heap size and disallows making images and
save-application.
The only 'full' environment is Corman Common Lisp.
If you run that under emacs you get a resonably complete system.
Some limitations still apply but I really like the fact that I have full
source code for the system.
From the viewpoint of learning common lisp this is a great asset.
Wnen I worked under linux I used CMUCL and was reasonably happy with it.
On Sun, 28 Mar 2004 03:01:09 +0200, Edi Weitz <···@agharta.de> wrote:
> On Sat, 27 Mar 2004 11:48:06 -0800, "Brandon J. Van Every"
> <·····························@yahoo.com> wrote:
>
>> I've decided against Lisp not for reasons of speed, but for reasons
>> of availability and support tools. At the present time I would need
>> an open source compiled Lisp on Windows (i.e. no funds), and none is
>> available. Nor are 30 day free trials enough time.
>
> There are three commercial Lisps available for Windows and none of
> them has a trial version which is restricted to a 30 day period.[1]
> Looks like you didn't do your homework very well...
>
> Edi.
>
> [1] With the exception of the Corman Lisp IDE. You can replace it with
> Emacs and use the compiler as long as you like.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Sun, 28 Mar 2004 22:20:11 +0100, John Thingstad <··············@chello.no> wrote:
> Naw, but they are hobbled.
I didn't deny that. The OP's claims were wrong nevertheless and
deserved correction.
> Liquid lisp concs out after an hour's (?) use.
It's called "Lispworks" and the company is Xanalys.[1] The time limit
for the trial version is five hours, not one.
> Allegro sets limits on heap size and disallows making images and
> save-application.
As does Xanalys.
> The only 'full' environment is Corman Common Lisp.
If you count adherence to the ANSI standard and additional features
Franz and Xanalys certainly have more to offer (although Corman Lisp
is a great product given its price).
Edi.
[1] They still distribute Liquid Common Lisp for commercial Unix
platforms but I don't think they have a trial version available on
their website.
I agree. I have never used Liquid common Lisp (As you probably garthered ;)
However I have used Allegro Common Lisp 5.0 under windowsfor a year
and often miss it. Particularly porting stuff to Corman is a pain because
minor
incompatabillity problems break the code.
The big minuses are:
[1] imcomplete clos implementation
1) Doesn't update objects when the class spesification has changed
2) Doesn't allow runtime changes of inheritance
3) Many convenience functions not implemented
[2] functions don't return correct error condition (just use '(error
"string"))
(This will be fixed in the next version.)
[3] The portable file name handeling is broken
(altso being fixed)
On Sun, 28 Mar 2004 22:37:43 +0200, Edi Weitz <···@agharta.de> wrote:
> If you count adherence to the ANSI standard and additional features
> Franz and Xanalys certainly have more to offer (although Corman Lisp
> is a great product given its price).
>
> Edi.
>
> [1] They still distribute Liquid Common Lisp for commercial Unix
> platforms but I don't think they have a trial version available on
> their website.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Joe Marshall
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <isgobwj1.fsf@comcast.net>
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Joe Marshall wrote:
>> ·····················@yahoo.com (Conrad Barski) writes:
>>
>>> Currently, I would argue there are two main draws for C/C++:
>>>
>>> 1. Speed
>>> 2. Power (from libraries/language features)
>>
>> Too bad that C/C++ don't actually have these features.
>
> It has speed.
C is ok in speed, unless you want *serious* performance, in which case
you want to use assembly code. C++ can perform as well as C if you
avoid all the extra features, but when you start doing anything
complicated you'll find your performance disappearing into a myriad of
constructor/destructor calls that play around with refcounts,
initialize useless fields, compute default values, etc.
--
~jrm
Joe Marshall <·············@comcast.net> writes:
> C is ok in speed, unless you want *serious* performance, in which case
> you want to use assembly code. C++ can perform as well as C if you
> avoid all the extra features, but when you start doing anything
> complicated you'll find your performance disappearing into a myriad of
> constructor/destructor calls that play around with refcounts,
> initialize useless fields, compute default values, etc.
I once wrote a real time volume renderer in C++. It was faster than
the corresponding code in C would have been: Using templates I was
able to generate dozens of variations of the general algorithm in a
clean and maintainable way.
The C way would have been to implement the variations using function
pointers or (worse) if/switch-statements. Within a volume renderer's
inner loops you /really/ don't want to have that. It's
performance-wise a disaster (yes, I measured it).
C++'s templates offered a way to abstract certain aspects of my
algorithm /without/ paying a performance penalty at all (I looked at
the assembler code generated). This is really cool.
Yes, if you don't understand how C++ works chances are you end up
writing horribly inefficient code. But this is also true for many
other languages, including CL.
From: Joe Marshall
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <ekrbr8od.fsf@ccs.neu.edu>
Matthias <··@spam.pls> writes:
> I once wrote a real time volume renderer in C++. It was faster than
> the corresponding code in C would have been: Using templates I was
> able to generate dozens of variations of the general algorithm in a
> clean and maintainable way.
>
> The C way would have been to implement the variations using function
> pointers or (worse) if/switch-statements. Within a volume renderer's
> inner loops you /really/ don't want to have that. It's
> performance-wise a disaster (yes, I measured it).
>
> C++'s templates offered a way to abstract certain aspects of my
> algorithm /without/ paying a performance penalty at all (I looked at
> the assembler code generated). This is really cool.
You are using the templates as a mechanism for partial evaluation.
There is an interesting phenomenon here: templates are turing
complete, so you can write programs with them (which is what people
do). But templates are an *absolutely horrible* language in which to
program.
Joe Marshall <···@ccs.neu.edu> writes:
> > The C way would have been to implement the variations using function
> > pointers or (worse) if/switch-statements. Within a volume renderer's
> > inner loops you /really/ don't want to have that. It's
> > performance-wise a disaster (yes, I measured it).
> >
> > C++'s templates offered a way to abstract certain aspects of my
> > algorithm /without/ paying a performance penalty at all (I looked at
> > the assembler code generated). This is really cool.
>
> You are using the templates as a mechanism for partial evaluation.
>
> There is an interesting phenomenon here: templates are turing
> complete, so you can write programs with them (which is what people
> do). But templates are an *absolutely horrible* language in which to
> program.
No. I was using templates as replacement for function pointers. This
is no more horrible than using ordinary function pointers in C. It's
just faster. (At the price of potentially increased size of your
executable.)
I don't have my original code handy, but you can find the technique in
Todd Veldhuizen's "Techniques for Scientific C++"
http://osl.iu.edu/~tveldhui/papers/techniques/techniques01.html#l19
and probably also in more recent references.
Joe Marshall <···@ccs.neu.edu> writes:
> You are using the templates as a mechanism for partial evaluation.
>
> There is an interesting phenomenon here: templates are turing
> complete, so you can write programs with them (which is what people
> do). But templates are an *absolutely horrible* language in which to
> program.
Perhaps a good 10 M.y project would be to implement a common-lisp to
c++ template compiler...
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
On 8696 day of my life Brandon J. Van Every wrote:
> Joe Marshall wrote:
>> ·····················@yahoo.com (Conrad Barski) writes:
>>
>>> Currently, I would argue there are two main draws for C/C++:
>>>
>>> 1. Speed
>>> 2. Power (from libraries/language features)
>>
>> Too bad that C/C++ don't actually have these features.
>
> It has speed.
"There are no slow langauges. There are bad compilers and bad
programmers."
I do not remeber who is author of the quote.
--
Ivan Boldyrev
"Assembly of Japanese bicycle require great peace of mind."
·····················@yahoo.com (Conrad Barski) said:
>So in order to improve the success of CL in the near future, I think
>the critical goal would be to entice as much of the C/C++ crowd as
>possible to take a leap into lisp. The following (rambling) ideas come
>to mind in helping towards this goal:
Aren't there more Java programmers than C/C++ programmers? I would aim
there first; I think they are less performance-obsessed and more
interested in programming productivity.
Will Hartung wrote:
> Here's more of a strategic platform question.
>
> Simply put if you had 10 man years at your disposal, how would you allocate
> it to advance Common Lisp?
First of all, I am filing a sex discrimination class action against you
tomorrow. Cue the two-month OT thread. Now for those ten person-years:
We do a three-month reality TV show with Kenny as project manager. Ten
people-years is 120 monkey-months. Three five-human teams and one
five-chimpanzee team uses up sixty months, leaving sixty month-dollars
for me.
The project is a Lisp plug-in for the Web. The four teams means I get to
fire three people-chimps a week instead of one. After six weeks only two
chimpanzees are left, at which point I fire them both and have them and
the other chimps reintroduced to a nice rain forest somewhere and finish
the plug-in myself.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> The project is a Lisp plug-in for the Web. The four teams means I
> get to fire three people-chimps a week instead of one. After six
> weeks only two chimpanzees are left, at which point I fire them both
> and have them and the other chimps reintroduced to a nice rain
> forest somewhere and finish the plug-in myself.
chimps and gorillas are expected soon [like 20 years from now] to be
extinct in their natural habitat [rain forests?]. human population of
those places has no better option then to capture the youngsters for
smuggle to rich countries. the best you could do is to send them to
some nice place like Monkey World in UK, where green activists will
take care of them.
http://www.monkeyworld.co.uk/
shit, pressed the wrong button, i wanted to followup in
usenet... hope fiddling with the headers will help...
--
gr{oe|ee}t{en|ings}
artm
Artem Baguinski wrote:
> ... the best you could do is to send them to
> some nice place like Monkey World in UK, where green activists will
> take care of them.
>
> http://www.monkeyworld.co.uk/
Can you make an introduction? Paddy's group reminds me of the crew down
at my pub, and look like they can churn code like nobody's business. I
just need an ear job and I'm in.
Can't wait to show them Cells.
kt
On Thu, 25 Mar 2004 10:32:04 -0800, Will wrote:
>Here's more of a strategic platform question.
>
>Simply put if you had 10 man years at your disposal, how would you allocate
>it to advance Common Lisp?
>
>I originally framed this as $1,000,000, which can be argued as "10 man
>years", but I didn't want folks to quibble about salaries and taxes and
>crap.
>
>So.
>
>Given that you can "spend" the budget as you like (20 people for 6 months, 2
>for 5 years, etc), what would you do with it?
>
I'd have a two pronged approach.
First, get people to work on a fast (CMUCL or SBCL fast) compiler for
Windows, then wrap it in a Windows-friendly IDE similar to Visual
Studio that developers are used to. Have it build standalone
executables. Throw in a GUI that can be dragged & dropped to make
things, like VB. VB itself is icky, but most of the time I just want
to slap a dialog on my interesting code, and that part of VB is good.
This should be enough to get hobbyists interested and get articles in
Dr. Dobbs, .NET magazines, etc.
I love SBCL with the asdf-install -based installs, etc. but to use it
I had to get Linux, repartition my drive and learn emacs. Most people
aren't going to go to that much trouble.
CLisp is on Windows, but I think the standard for speed is Java.
Although SBCL is faster than Java on Linux, CLisp is slower than Java
on Windows (based on running Bagley shootout code for Lisp and Java).
As a backup, I'd hire a couple of mercenaries to kidnap Paul Graham
and make him finish Arc. (Just kidding, Paul...).
······@bellsouth.net (Ralph Richard Cook) said:
>As a backup, I'd hire a couple of mercenaries to kidnap Paul Graham
>and make him finish Arc. (Just kidding, Paul...).
I'm just a Lisp neophyte, but I'd give Graham the money to finish Arc
because he seems to know how to get people interested, and marketing
is the most important aspect of all.
To get folks where I work interested in Lisp, it needs to have a more
conventional free editor/IDE -- they just aren't going to learn emacs.
It would also need to have some immediate payoff for conventional
(i.e., not incredibly abstract) programming. The kind of thing they
would notice would be really slick access to databases. I realize that
may not be what most current Lisp developers need.
adam connor <···················@mail.com> wrote:
+---------------
| To get folks where I work interested in Lisp, it needs... some
| immediate payoff for conventional... programming. The kind of thing
| they would notice would be really slick access to databases.
| I realize that may not be what most current Lisp developers need.
+---------------
Hunh?!? Who says?
> (with-pg-connection (conn "rpw3" "rpw3") ; Using Marsden's "pg.lisp".
(let ((result (pg-exec conn "SELECT * FROM toy WHERE c1 LIKE 'x%'")))
(cons (mapcar #'car (pg-result result :attributes))
(pg-result result :tuples))))
(("c1" "c2" "c3" "upd")
("xmas" "book" "My Favorite Christmas" 2)
("xmas" "video" "The Grinch who Stole Christmas" 4)
("xmas" "video" "Home Alone" 6))
>
See <URL:http://www.cliki.net/Database> for a whole bunch more...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
adam connor <···················@mail.com> writes:
> ······@bellsouth.net (Ralph Richard Cook) said:
>
>>As a backup, I'd hire a couple of mercenaries to kidnap Paul Graham
>>and make him finish Arc. (Just kidding, Paul...).
>
> I'm just a Lisp neophyte, but I'd give Graham the money to finish
> Arc because he seems to know how to get people interested, and
> marketing is the most important aspect of all.
Of course given Graham's success selling Viaweb to Yahoo! I rather
doubt lack of money is what's holding Arc back.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
adam connor <···················@mail.com> wrote:
>
> The kind of thing they would notice would be really slick access to
> databases. I realize that may not be what most current Lisp developers
> need.
Check out pg-dot-lisp
http://www.chez.com/emarsden/downloads/
a PostgreSQL library for CommonLisp. I'm currently using it in one of my
projects and I really like it.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Alexander Schreiber <···@usenet.thangorodrim.de> said:
>adam connor <···················@mail.com> wrote:
>>
>> The kind of thing they would notice would be really slick access to
>> databases. I realize that may not be what most current Lisp developers
>> need.
>
>Check out pg-dot-lisp
>
>http://www.chez.com/emarsden/downloads/
>
>a PostgreSQL library for CommonLisp. I'm currently using it in one of my
>projects and I really like it.
>
Not to put it down, but it looks like embedded SQL similar to what can
be done in many languages (e.g., Java's JDBC). It needs to be much
"slicker" than that to be an advantage for Lisp. See Joel Spolsky's
essay http://www.joelonsoftware.com/items/2004/03/25.html.
adam connor wrote:
> Not to put it down, but it looks like embedded SQL similar to what
> can be done in many languages (e.g., Java's JDBC). It needs to be
> much "slicker" than that to be an advantage for Lisp. See Joel
> Spolsky's essay http://www.joelonsoftware.com/items/2004/03/25.html.
The problem with slick, language specific database bindings is that they
encourage programmers to think that they understand database, or don't
need to, having read some simple introduction to MySQL plus the docs for
the language bindings.
To write high performance Lisp code, one must minimize consing and
unnecessary list traversal. Conversely, it is said that it's easy for
beginners to write inefficient code. There are similar issues with
database code. An example:
You want to find what country a website visitor hails from. So you punch
some likely stuff into Google and find a solution that involves a table
of network allocations, and a query of
SELECT country FROM countrybyip
WHERE ipstartaddress <= myip
AND ipendaddress >= myip
Piece of cake, except that this is the worst query ever, because it
guarantees that the database engine will have to test an average of half
the records in the table for every query. Since there's about 10,000
records in this table, that's a lot of wasted cycles. By the way, I'm
not making this example up, and I'm sure that there's hundreds or
thousands of websites doing exactly the above right now.
A relational database expert can look at the above SQL and tell you that
it's bad news. For a few dollars more, he'll rewrite it for you. Or you
can suck the whole table into a tree structure in RAM and find the
country with 14 compares.
But if you create some wonderful mapping into a lisp
(db-loop for country where (and (< ipstartaddress myip)...
you get the worst of both worlds, in a sense. Looks like perfectly good
Lisp code, translates to horribly inefficient database code, and to see
that, you've got to know lisp and database and do the translation in
your head.
I'm not saying that better language bindings aren't a worthy area of
exploration, but if the goal (or even a side effect) is saving the
programmer from understanding database internals, horribly inefficient
systems are the guaranteed result.
--
Cameron MacKinnon
Toronto, Canada
In article <······················@golden.net>, Cameron MacKinnon
<··········@clearspot.net> wrote:
> adam connor wrote:
>
> > Not to put it down, but it looks like embedded SQL similar to what
> > can be done in many languages (e.g., Java's JDBC). It needs to be
> > much "slicker" than that to be an advantage for Lisp. See Joel
> > Spolsky's essay http://www.joelonsoftware.com/items/2004/03/25.html.
>
> The problem with slick, language specific database bindings is that they
> encourage programmers to think that they understand database, or don't
> need to, having read some simple introduction to MySQL plus the docs for
> the language bindings.
>
> To write high performance Lisp code, one must minimize consing and
> unnecessary list traversal. Conversely, it is said that it's easy for
> beginners to write inefficient code. There are similar issues with
> database code. An example:
>
> You want to find what country a website visitor hails from. So you punch
> some likely stuff into Google and find a solution that involves a table
> of network allocations, and a query of
> SELECT country FROM countrybyip
> WHERE ipstartaddress <= myip
> AND ipendaddress >= myip
>
> Piece of cake, except that this is the worst query ever, because it
> guarantees that the database engine will have to test an average of half
> the records in the table for every query. Since there's about 10,000
> records in this table, that's a lot of wasted cycles. By the way, I'm
> not making this example up, and I'm sure that there's hundreds or
> thousands of websites doing exactly the above right now.
>
> A relational database expert can look at the above SQL and tell you that
> it's bad news. For a few dollars more, he'll rewrite it for you. Or you
> can suck the whole table into a tree structure in RAM and find the
> country with 14 compares.
>
> But if you create some wonderful mapping into a lisp
> (db-loop for country where (and (< ipstartaddress myip)...
> you get the worst of both worlds, in a sense. Looks like perfectly good
> Lisp code, translates to horribly inefficient database code, and to see
> that, you've got to know lisp and database and do the translation in
> your head.
>
> I'm not saying that better language bindings aren't a worthy area of
> exploration, but if the goal (or even a side effect) is saving the
> programmer from understanding database internals, horribly inefficient
> systems are the guaranteed result.
This reminds me of the old AI Koan:
A novice was trying to fix a broken lisp machine by turning the power off
and on. Knight, seeing what the student was doing spoke sternly- "You can
not fix a machine by just power-cycling it with no understanding of what
is going wrong."
Knight turned the machine off and on.
The machine worked.
(I have actually had experiences similar to this when my wife asks me to
fix problems with her machine.)
The canonical example of inefficient code is the straightforward recursive
implementation of the fibonacci sequence:
(defun fib (n) (if (<= n 1) 1 (+ (fib (- n 1)) (fib (- n 2)))))
This has exponential complexity, but not because of anything having to do
with consing or unnecessary list traversal, or indeed with with Lisp.
There's nothing going on here but addition and subtraction. It's just a
bad algorithm. With a very little effort even a beginning programmer can
optimize this to a linear time algorithm. To get to the optimal log(n)
time algorithm is generally considered an advanced excercise.
So language bindings and databases and all that are red herrings. If you
lack understanding you can end up with horrifically inefficient code no
matter what you're doing.
I will also note in passing that the SQL example above can be easily made
log(n) simply by adding indices on the ipstartaddress and ipendaddress
columns. Also, any table with a mere 10,000 entries on a modern machine
is almost certainly entirely RAM resident anyway.
E.
·········@flownet.com (Erann Gat) writes:
> This reminds me of the old AI Koan:
>
> A novice was trying to fix a broken lisp machine by turning the power off
> and on. Knight, seeing what the student was doing spoke sternly- "You can
> not fix a machine by just power-cycling it with no understanding of what
> is going wrong."
>
> Knight turned the machine off and on.
>
> The machine worked.
>
> (I have actually had experiences similar to this when my wife asks me to
> fix problems with her machine.)
It is worse than that! You have to actually take this koan *literally*!
"Knowing what you're doing" is a state in which the bogon flux is
highly reduced.
Perhaps it's less observed nowadays that _personnal_ computers are
generalized, but with mini-computers this has been observed more than
once, that the problem was not the computer but the operator.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
>
> Perhaps it's less observed nowadays that _personnal_ computers are
> generalized, but with mini-computers this has been observed more than
> once, that the problem was not the computer but the operator.
Experienced sysadmins know that the sources for most errors are neither
found in hardware nor software, but are firmly located in the ISO
protocol layers 8 and 9[0].
Or, as the acronym goes: PEBKAC.
Regards,
Alex.
[0] Which are, of course the user (layer 8) and the boss (layer 9).
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Erann Gat wrote:
> The canonical example of inefficient code is the straightforward recursive
> implementation of the fibonacci sequence:
>
> (defun fib (n) (if (<= n 1) 1 (+ (fib (- n 1)) (fib (- n 2)))))
>
> This has exponential complexity, but not because of anything having to do
> with consing or unnecessary list traversal, or indeed with with Lisp.
> There's nothing going on here but addition and subtraction. It's just a
> bad algorithm. With a very little effort even a beginning programmer can
> optimize this to a linear time algorithm. To get to the optimal log(n)
> time algorithm is generally considered an advanced excercise.
The optimal algorithm is O(1) (if we are counting the number of
mathematical operations, that is).
See formula (7) at
<http://mathworld.wolfram.com/FibonacciNumber.html>
--
Jens Axel S�gaard
In article <·······················@dread11.news.tele.dk>,
=?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <······@soegaard.net> wrote:
> Erann Gat wrote:
>
> > The canonical example of inefficient code is the straightforward recursive
> > implementation of the fibonacci sequence:
> >
> > (defun fib (n) (if (<= n 1) 1 (+ (fib (- n 1)) (fib (- n 2)))))
> >
> > This has exponential complexity, but not because of anything having to do
> > with consing or unnecessary list traversal, or indeed with with Lisp.
> > There's nothing going on here but addition and subtraction. It's just a
> > bad algorithm. With a very little effort even a beginning programmer can
> > optimize this to a linear time algorithm. To get to the optimal log(n)
> > time algorithm is generally considered an advanced excercise.
>
> The optimal algorithm is O(1) (if we are counting the number of
> mathematical operations, that is).
>
> See formula (7) at
>
> <http://mathworld.wolfram.com/FibonacciNumber.html>
Everything is O(1) if you precompute the answer and store it in a lookup
table, which is essentially what a floating point unit is. Once you
exceed the precision of the lookup table you get the wrong answer, which
for a double-float and the above formula starts to happen at around N=75
or so.
Which is not that say that it isn't a cool formula. But just because you
can write down a mathematical expression without any apparent loops in it
doesn't mean you've described an O(1) algorithm.
E.
From: Rahul Jain
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <87oeqgopds.fsf@nyct.net>
·········@flownet.com (Erann Gat) writes:
> Which is not that say that it isn't a cool formula. But just because you
> can write down a mathematical expression without any apparent loops in it
> doesn't mean you've described an O(1) algorithm.
I'd say that the expoentiation is a rather apparent loop, even if you
had O(1) irrational-number multiplication (HA!). For this specific
purpose, you're looking for an integral result, so maybe the amount of
precision needed could be determined before the exponentiation, avoiding
the need to recompute the result with a larger precision if the
precision has been overflowed.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Joe Marshall
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <isgnr96h.fsf@ccs.neu.edu>
·········@flownet.com (Erann Gat) writes:
> Everything is O(1) if you precompute the answer and store it in a lookup
> table, which is essentially what a floating point unit is.
Actually, table lookup is O(log n), but n is usually small and
bounded.
Jens Axel S�gaard <······@soegaard.net> writes:
> The optimal algorithm is O(1) (if we are counting the number of
> mathematical operations, that is).
Of course ALL algorithms are optimal and in O(1), if we are counting
the processor cycles!
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon wrote:
> Jens Axel S�gaard <······@soegaard.net> writes:
>
>>The optimal algorithm is O(1) (if we are counting the number of
>>mathematical operations, that is).
>
>
> Of course ALL algorithms are optimal and in O(1), if we are counting
> the processor cycles!
Hence the parenthetical remark.
Seriously, how expensive is EXPT in a fair comparison,
where bignum operations doesn't count O(1) ?
--
Jens Axel S�gaard
Erann Gat <·········@flownet.com> wrote:
+---------------
| This reminds me of the old AI Koan:
| ...
| Knight turned the machine off and on.
| The machine worked.
|
| (I have actually had experiences similar to this when my wife asks me to
| fix problems with her machine.)
+---------------
The most common case of that I've seen is when people don't understand
that power-cycling doesn't always "work" unless you leave the power off
long enough for the voltages to discharge "completely enough" to effect
a clean, thorough reset. So the novice goes "flipOFF, flipON", and the
thing still doesn't work. The expert comes in and goes "flipOFF... wait...
wait... wait... wait... flipON", and it does. ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Ray Dillinger
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <4069FF83.785286@sonic.net>
Rob Warnock wrote:
>
> Erann Gat <·········@flownet.com> wrote:
> +---------------
> | This reminds me of the old AI Koan:
> | ...
> | Knight turned the machine off and on.
> | The machine worked.
> |
> | (I have actually had experiences similar to this when my wife asks me to
> | fix problems with her machine.)
> +---------------
>
> The most common case of that I've seen is when people don't understand
> that power-cycling doesn't always "work" unless you leave the power off
> long enough for the voltages to discharge "completely enough" to effect
> a clean, thorough reset. So the novice goes "flipOFF, flipON", and the
> thing still doesn't work. The expert comes in and goes "flipOFF... wait...
> wait... wait... wait... flipON", and it does. ;-} ;-}
>
Actually, the expert comes along, and goes ... <flipOFF> then turns to the
novice and says "You cannot make a machine work just by flipping it off
and on without understanding what it is doing." then turns back to the
machine and goes ... <FlipON> and walks away humming to himself.
It's just efficient use of time to spend the moments explaining instead
of just waiting. Waiting is boring, and besides might give the novice a
clue that the time is what it was about rather than allowing them to
discover the mystery by contemplation and insight.
Bear
·········@flownet.com (Erann Gat) writes:
> The machine worked.
>
> (I have actually had experiences similar to this when my wife asks me to
> fix problems with her machine.)
That just adds to the pile of proof that cluons actually exist!
--
(espen)
Cameron MacKinnon <··········@clearspot.net> writes:
> adam connor wrote:
>
> > Not to put it down, but it looks like embedded SQL similar to what
> > can be done in many languages (e.g., Java's JDBC). It needs to be
> > much "slicker" than that to be an advantage for Lisp. See Joel
> > Spolsky's essay http://www.joelonsoftware.com/items/2004/03/25.html.
>
> The problem with slick, language specific database bindings is that they
> encourage programmers to think that they understand database, or don't
> need to, having read some simple introduction to MySQL plus the docs for
> the language bindings.
>
> To write high performance Lisp code, one must minimize consing and
> unnecessary list traversal. Conversely, it is said that it's easy for
> beginners to write inefficient code. There are similar issues with
> database code. An example:
>
> You want to find what country a website visitor hails from. So you punch
> some likely stuff into Google and find a solution that involves a table
> of network allocations, and a query of
> SELECT country FROM countrybyip
> WHERE ipstartaddress <= myip
> AND ipendaddress >= myip
[snip]
> But if you create some wonderful mapping into a lisp
> (db-loop for country where (and (< ipstartaddress myip)...
> you get the worst of both worlds, in a sense. Looks like perfectly good
> Lisp code, translates to horribly inefficient database code, and to see
> that, you've got to know lisp and database and do the translation in
> your head.
Hmm, with the SQLisp library I've been using recently, that would be:
(with-table (countrybyip)
(with-columns (country ipstartaddress ipendaddress) countrybyip
(project country (constrain countrybyip
(sql-and (sql<= ipstartaddress myip)
(sql>= ipstartaddress myip))))))
Of course, there's nothing really wrong with the query per se, it's
already been mentioned how to adjust your schema so that this is a
reasonable thing to ask. And in fact, when I get the time, I'm
planning on adding profiling tools to help with exactly this; if I
wrote something like the above, I could get SQLisp to yell at me.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Cameron MacKinnon wrote:
<snipped>
> You want to find what country a website visitor hails from. So you punch
> some likely stuff into Google and find a solution that involves a table
> of network allocations, and a query of
> SELECT country FROM countrybyip
> WHERE ipstartaddress <= myip
> AND ipendaddress >= myip
>
> Piece of cake, except that this is the worst query ever, because it
> guarantees that the database engine will have to test an average of half
> the records in the table for every query.
<snipped>
That indeed occurs when no table indexes exist for the fields
ipstartaddress and ipendaddress. The solution is to index those fields,
in which case the desired result set is returned with minimal searching.
Michael D. Kersey wrote:
> Cameron MacKinnon wrote:
> <snipped>
>
>> You want to find what country a website visitor hails from. So you punch
>> some likely stuff into Google and find a solution that involves a table
>> of network allocations, and a query of
>> SELECT country FROM countrybyip
>> WHERE ipstartaddress <= myip
>> AND ipendaddress >= myip
>>
>> Piece of cake, except that this is the worst query ever, because it
>> guarantees that the database engine will have to test an average of half
>> the records in the table for every query.
>
> <snipped>
> That indeed occurs when no table indexes exist for the fields
> ipstartaddress and ipendaddress. The solution is to index those fields,
> in which case the desired result set is returned with minimal searching.
Show your work! Using the first index and the first condition gives an
intermediate result set with no index, which must be scanned for the
second condition. Likewise if you start by using the second index.
Unless you know of an algorithm that can use both indexes at the same time?
Note that I assumed the existence of one index when I said "will have to
test an average of half the records." With no index, all the records
would need to be tested.
Is this clear? You can index both fields, but the query engine must pick
one of them to apply first, and the intermediate result of that first
selection is an unindexed set (which happens to be ordered by the field
that index was on, but that doesn't help). The DB could use the other
index to create a second unindexed set, and then AND (intersection) them
together, or it could just run the other half of the WHERE clause on the
first intermediate result (which is what it would do).
That several people believed that the database can efficiently answer
this query given the appropriate indexes gives weight to my original
argument. I wasn't trying to trick anyone with the example.
I wouldn't be entirely surprised if running the query on a table with no
indexes was the fastest of all (for this inefficient query). It takes
the query optimizer out of the equation and it reduces the data
cluttering up the CPU cache. On a table of only 10k rows, this might win.
--
Cameron MacKinnon
Toronto, Canada
In article <······················@golden.net>, Cameron MacKinnon
<··········@clearspot.net> wrote:
> Michael D. Kersey wrote:
> > Cameron MacKinnon wrote:
> > <snipped>
> >
> >> You want to find what country a website visitor hails from. So you punch
> >> some likely stuff into Google and find a solution that involves a table
> >> of network allocations, and a query of
> >> SELECT country FROM countrybyip
> >> WHERE ipstartaddress <= myip
> >> AND ipendaddress >= myip
> >>
> >> Piece of cake, except that this is the worst query ever, because it
> >> guarantees that the database engine will have to test an average of half
> >> the records in the table for every query.
> >
> > <snipped>
> > That indeed occurs when no table indexes exist for the fields
> > ipstartaddress and ipendaddress. The solution is to index those fields,
> > in which case the desired result set is returned with minimal searching.
>
> Show your work! Using the first index and the first condition gives an
> intermediate result set with no index, which must be scanned for the
> second condition.
Heh, good point. So add "limit 1" to the query. (But I guess that does
tend to vindicate your original point that writing efficient database
queries can be tricky.)
E.
Cameron MacKinnon wrote:
> Michael D. Kersey wrote:
>
>> Cameron MacKinnon wrote:
>> <snipped>
>>
>>> You want to find what country a website visitor hails from. So you punch
>>> some likely stuff into Google and find a solution that involves a table
>>> of network allocations, and a query of
>>> SELECT country FROM countrybyip
>>> WHERE ipstartaddress <= myip
>>> AND ipendaddress >= myip
>>>
>>> Piece of cake, except that this is the worst query ever, because it
>>> guarantees that the database engine will have to test an average of half
>>> the records in the table for every query.
>>
>> <snipped>
>> That indeed occurs when no table indexes exist for the fields
>> ipstartaddress and ipendaddress. The solution is to index those
>> fields, in which case the desired result set is returned with minimal
>> searching.
>
> Show your work! Using the first index and the first condition gives an
> intermediate result set with no index, which must be scanned for the
> second condition. Likewise if you start by using the second index.
> Unless you know of an algorithm that can use both indexes at the same time?
>
> Note that I assumed the existence of one index when I said "will have to
> test an average of half the records." With no index, all the records
> would need to be tested.
Sorry to take so long to post. Indeed you are correct and I had
incorrectly mentally conflated two separate indexes into one. I'm afraid
years of using SQL (and easier problems, as described below) has made my
mind somewhat flabby!8-((
All more the surprise when I realized that your sample query is an old
friend, a range-searching problem I'd dealt with many times before in
the 70's and 80's while working in computer graphics and geographical
information systems. At that time we _weren't_ using SQL or relational
databases. The problem took various forms but was essentially the following:
Given a point (x,y), determine which closed region(s) inside which that
point lies. The various regions were described by polygonal arrays. The
problem was/is computationally expensive and was not amenable to
sequential search due to the number of regions (typically 1000's and up)
and the multi-dimensional nature of the problem. And the solution was as
you described earlier: to build data structures characterizing the
polygonal regions that could be rapidly searched.
> Is this clear? You can index both fields, but the query engine must pick
> one of them to apply first, and the intermediate result of that first
> selection is an unindexed set (which happens to be ordered by the field
> that index was on, but that doesn't help). The DB could use the other
> index to create a second unindexed set, and then AND (intersection) them
> together, or it could just run the other half of the WHERE clause on the
> first intermediate result (which is what it would do).
>
> That several people believed that the database can efficiently answer
> this query given the appropriate indexes gives weight to my original
> argument. I wasn't trying to trick anyone with the example.
I'm glad I tripped over your problem: it's something I had not thought
about in a long time and thinking about it brought back many pleasant
memories.
> I wouldn't be entirely surprised if running the query on a table with no
> indexes was the fastest of all (for this inefficient query). It takes
> the query optimizer out of the equation and it reduces the data
> cluttering up the CPU cache. On a table of only 10k rows, this might win.
Michael D. Kersey wrote:
> Cameron MacKinnon wrote:
>
>> Michael D. Kersey wrote:
>>
>>> Cameron MacKinnon wrote:
>>>> SELECT country FROM countrybyip
>>>> WHERE ipstartaddress <= myip
>>>> AND ipendaddress >= myip
...
>> Unless you know of an algorithm that can use both indexes at the same
>> time?
...
> All more the surprise when I realized that your sample query is an old
> friend, a range-searching problem I'd dealt with many times before in
> the 70's and 80's while working in computer graphics and geographical
> information systems. At that time we _weren't_ using SQL or relational
> databases.
Did you end up discovering KD-Trees? I'm not sure if the algorithm was
around at the time.
> I'm glad I tripped over your problem: it's something I had not thought
> about in a long time and thinking about it brought back many pleasant
> memories.
Cheers!
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
<snipped>
> Did you end up discovering KD-Trees? I'm not sure if the algorithm was
> around at the time.
No, we didn't discover them AFAIK (not that we would have published
anything, had we - the atmosphere was very competitive!8-) We _did_
implement hierarchical structures of minimum bounding rectangles and
Burton's Binary Searchable Polygonal Representation (BSPR). For the
interested reader those and KD-trees are described nicely in:
http://www.cs.umd.edu/class/fall2003/cmsc420-0101/slides/cd.ps
adam connor <···················@mail.com> wrote:
> Alexander Schreiber <···@usenet.thangorodrim.de> said:
>
>>adam connor <···················@mail.com> wrote:
>>>
>>> The kind of thing they would notice would be really slick access to
>>> databases. I realize that may not be what most current Lisp developers
>>> need.
>>
>>Check out pg-dot-lisp
>>
>>http://www.chez.com/emarsden/downloads/
>>
>>a PostgreSQL library for CommonLisp. I'm currently using it in one of my
>>projects and I really like it.
>>
>
> Not to put it down, but it looks like embedded SQL similar to what can
> be done in many languages (e.g., Java's JDBC). It needs to be much
> "slicker" than that to be an advantage for Lisp. See Joel Spolsky's
> essay http://www.joelonsoftware.com/items/2004/03/25.html.
But the core problem of serious mismatch between the structure of
relational databases and the structure of most programming languages
persists. If there were a simple, elegant, correct and performant way to
map between relational databases and Lisp datastructures, I'll wager it
would have been put into a library years ago. But since one has to match
between two _very_ different data modelling systems (one based on atoms,
lists, cons cells and sequences, the other based on an interconnected
two dimensional table structure), any attempt at an automatic,
transparent mapping without any programmer intervention is bound to
either fail or produce something that would feel right at home in
R'lyeh.
The sanest approach IMHO is still an application specific interface
layer, working with relational structures (SQL queries and their
results) on one side and the data structuring abilities of Lisp on the
other side. Besides, if the programmer hasn't a sufficiently good
understanding of relational databases to write good, efficient queries,
he can now go to an RDBMS expert to get his queries (and before that,
the database structure) optimized. I guess at least some of us have seen
the horrors that result from programmers having only a very weak grasp
on relational databases - like treating database tables just as
spreadsheets one can ask with an arcane language. But this is a rant by
itself ...
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
From: Rahul Jain
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <874qs9pe3x.fsf@nyct.net>
Alexander Schreiber <···@usenet.thangorodrim.de> writes:
> But the core problem of serious mismatch between the structure of
> relational databases and the structure of most programming languages
> persists. If there were a simple, elegant, correct and performant way to
> map between relational databases and Lisp datastructures, I'll wager it
> would have been put into a library years ago. But since one has to match
> between two _very_ different data modelling systems (one based on atoms,
> lists, cons cells and sequences, the other based on an interconnected
> two dimensional table structure), any attempt at an automatic,
> transparent mapping without any programmer intervention is bound to
> either fail or produce something that would feel right at home in
> R'lyeh.
Prolog. Relations don't have to be 2-d.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Will Hartung" <·····@msoft.com> writes:
> Here's more of a strategic platform question.
>
> Simply put if you had 10 man years at your disposal, how would you allocate
> it to advance Common Lisp?
Write an interesting application. The domain does not matter, it just
must be interesting (new, faster, better, more flexible than
competitors). In the process of writing it you will find that a
couple of libs are lacking or undocumented (at least when using a
non-commercial CL). Write or port or document these libs.
The most frequently used Lisp today probably is ELISP. It won not
because it's such a well-designed language. It won because there was
a cool application people want to use, customize, and extend.
Matthias wrote:
> "Will Hartung" <·····@msoft.com> writes:
>
>
>>Here's more of a strategic platform question.
>>
>>Simply put if you had 10 man years at your disposal, how would you allocate
>>it to advance Common Lisp?
>
>
> Write an interesting application. The domain does not matter, it just
> must be interesting (new, faster, better, more flexible than
> competitors). In the process of writing it you will find that a
> couple of libs are lacking or undocumented (at least when using a
> non-commercial CL). Write or port or document these libs.
Forget the application, and just write and document the libraries, and
write and document one or more IDE's. And finish some stuff: I know it's
not the fault of the brilliant and tireless people slaving away mostly
for free, but when I come to McCLIM or SLIME or whatever and read that
these parts don't work, those great new bits will be coming real soon
now, and that issue over there is in the process of being resolved, it
makes me think, "best to come back in six months".
I know that I probably could get some real work done with these tools
now, but the idea of tracking tool changes and rebuilding on a weekly
basis, and possibly having to throw everything out if a new version
changes what my code should do puts me off. And I think it puts a lot of
potential converts off as well.
If you could point people to a stable, reasonably standardized set of
tools that just worked (that CD, for example, is a nice idea) that would
be a great use of as many programmer-years as you could throw at it.
(and yes, I know that what the commercial products are for, and yet...)
paul
Paul Wallich wrote:
> for free, but when I come to McCLIM or SLIME or whatever and read that
> these parts don't work, those great new bits will be coming real soon
> now, and that issue over there is in the process of being resolved, it
> makes me think, "best to come back in six months".
<sigh> While someone else (presumably the Open Source Fairy) finishes
them for you? What part of "open source" do you not understand? Get your
keyboard over here and get to work!
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> Paul Wallich wrote:
>> for free, but when I come to McCLIM or SLIME or whatever and read
>> that these parts don't work, those great new bits will be coming
>> real soon now, and that issue over there is in the process of being
>> resolved, it makes me think, "best to come back in six months".
>
> <sigh> While someone else (presumably the Open Source Fairy) finishes
> them for you? What part of "open source" do you not understand? Get
> your keyboard over here and get to work!
My understanding of Open Source is rather pragmatic. My philosophy:
- if you're going to give something away, give it away completely
- if it's too valuable to give away, don't
- if it's more loss than profit, don't contribute
I have no interest in Open Source as a matter of ideology. I only care
about Open Source as a business model. An Open Source project is a value
add when someone is working on something that you both want, and the goal is
readily achievable. But if you have to sit around contributing code to some
other project for months in order to get to square one with what you
actually want to do, then that is not a value add, it is a Complete Waste Of
Time [TM]. In such cases, it's better to wait for others to kick something
into a more usable condition. And if you're worried about the mercenary
evil in all of this, bear in mind that people can always get their Open
Source contributional ya-yas out somewhere else. Doesn't have to be for
your unfinished project.
This sort of pragmatism causes one to glom onto large projects that have
mature, useful bases of code to borrow from. Projects coming from
individuals are usually not so useful. More often than not, they're invites
to wild goose chases.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
Brandon J. Van Every wrote:
> I have no interest in Open Source as a matter of ideology.
Me, neither.
I only care
> about Open Source as a business model. An Open Source project is a value
> add when someone is working on something that you both want, and the goal is
> readily achievable.
You qualified achievable, I think you should also factor in how much you
want something.
But if you have to sit around contributing code to some
> other project for months in order to get to square one with what you
> actually want to do, then that is not a value add, it is a Complete Waste Of
> Time [TM].
Sure.
In such cases, it's better to wait for others to kick something
> into a more usable condition.
Sure, that's why I am futzing around with boring old scroller widgets
instead of adding More Great Libraries (to Cello).
And if you're worried about the mercenary
> evil in all of this,..
Not at all. I am just playfully (I hope) harrassing people sitting on
their hands doing nothing but whining about the absence of open source
libraries.
bear in mind that people can always get their Open
> Source contributional ya-yas out somewhere else.
Actually, I cannot complain, folks have stepped up nicely to help port
Cello and help with the common-lisp.net projects. Or I'd make a joke
about, "Right, everyone is over working on Marc's projects." :)
Doesn't have to be for
> your unfinished project.
>
> This sort of pragmatism causes one to glom onto large projects that have
> mature, useful bases of code to borrow from. Projects coming from
> individuals are usually not so useful. More often than not, they're invites
> to wild goose chases.
I suppose you are right about the ratio, but OTOH, where do you think
those large, stable, successful projects started? SuperCollider, one
guy. Ogre3d, one guy. Python, one guy.... there /is/ a middle ground of
sizing up a new project (software and developers) to identify projects
with a ways to go but excellent prospects.
Christophe got off a good one on Cello by posting a grotesque screenshot
he found in our ftp area, but why was that shot there? Because it was
the exact same full-featured GUI and application framework running on
Linux and Win32, and which (unlike CAPI) has run under two different
Lisps (ACL and LW). ie, game over: CL now actually has a portable,
industrial-strength, free as in "other people write it, you use it" GUI
and application framework. And not a C++ framework in Lisp wrappers, I
might add. That makes Frank's screenshot downright gorgeous.
Your fear of wild goose chases could be a self-fulfilling one. When can
you start?
:)
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> said:
>
>
>Paul Wallich wrote:
>> for free, but when I come to McCLIM or SLIME or whatever and read that
>> these parts don't work, those great new bits will be coming real soon
>> now, and that issue over there is in the process of being resolved, it
>> makes me think, "best to come back in six months".
>
><sigh> While someone else (presumably the Open Source Fairy) finishes
>them for you? What part of "open source" do you not understand? Get your
>keyboard over here and get to work!
I'm not the OP, but, here's how it is for me. To use Lisp at work
(which would take an awful lot of persuasion and demonstration to
begin with), there have to be lots of more-or-less finished pieces.
Java had this and it was still a slow and painful business. Perl has
this and we still only use Perl in a few places.
To use Lisp, you have to win the mind-share war first, and that
requires lots of nifty stuff. I'm not going to write it all. Hell,
I'll be lucky if I write any of it; I'm a newbie.
I'm not complaining, mind you -- just trying to inject a note of
realism. Perl, Python, and Java all have thriving communities, and
they all have big, accessible libraries. For Lisp (or any other
language) to take off, it either has to meet a common need that none
of these languages meet, or it has to have a huge library and do the
same things better.
I realize Lisp works well for lots of things now, and that may be the
boat most comp.lang.lisp readers are in. That's fine, but not
sufficient for growth.
adam connor wrote:
> Kenny Tilton <·······@nyc.rr.com> said:
>
>
>>
>>Paul Wallich wrote:
>>
>>>for free, but when I come to McCLIM or SLIME or whatever and read that
>>>these parts don't work, those great new bits will be coming real soon
>>>now, and that issue over there is in the process of being resolved, it
>>>makes me think, "best to come back in six months".
>>
>><sigh> While someone else (presumably the Open Source Fairy) finishes
>>them for you? What part of "open source" do you not understand? Get your
>>keyboard over here and get to work!
>
>
> I'm not the OP, but, here's how it is for me. To use Lisp at work
> (which would take an awful lot of persuasion and demonstration to
> begin with), there have to be lots of ....
Listen closely. If anyone asks, you do not know Lisp. When your employer
wants to send you to NYC for Lisp training at the Tilton Academy in the
year (1+ S) (one year after Seibel), you will be able to sleep all day
and drink all night and still ace the final. Just make sure you know
Cells, it's on the final.
Perl, Python, and Ruby are just stepping stones to Lisp. They are the
first manifestation of the demise of the static dinosaurs. I am sure
Microsoft already has a commercial Lisp product in the works. Make sure
you do not give those losers a dime. Java almost has an official Groovy
project (when's the vote?).
game over. from now on, any discussion of how to make Lisp more popular
is as OT as headscarf marriage.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
adam connor <···················@mail.com> writes:
> I'm not complaining, mind you -- just trying to inject a note of
> realism. Perl, Python, and Java all have thriving communities, and
> they all have big, accessible libraries. For Lisp (or any other
> language) to take off, it either has to meet a common need that none
> of these languages meet, or it has to have a huge library and do the
> same things better.
The difference is that these other languages have more or less one
common implementation. You need to port libs only once. Lisp has
dozens of implementations, all with different interfaces to the
non-Lisp world. And it has a relatively small user base.
This combination probably is one reason why the Lisp community grows
slower than some other language communities.
On 28 Mar 2004 11:12:04 +0200, Matthias <··@spam.pls> wrote:
> adam connor <···················@mail.com> writes:
>
>> I'm not complaining, mind you -- just trying to inject a note of
>> realism. Perl, Python, and Java all have thriving communities, and
>> they all have big, accessible libraries. For Lisp (or any other
>> language) to take off, it either has to meet a common need that none
>> of these languages meet, or it has to have a huge library and do the
>> same things better.
>
> The difference is that these other languages have more or less one
> common implementation. You need to port libs only once. Lisp has
> dozens of implementations, all with different interfaces to the
> non-Lisp world. And it has a relatively small user base.
>
> This combination probably is one reason why the Lisp community grows
> slower than some other language communities.
>
That this is probably true is supported by the experience of
another language with many similarities to Lisp - Forth.
Forth, only ten years younger than Lisp, is also an extensible
language with an even simpler REPL than Lisp. A few primitives
in C or asm, the rest in Forth, and you're on your way. As a
result, there are *lots* of Forths out there. There's a Forth
saying that "when you've seen one Forth, you've seen one Forth".
Like Lisp, Forth has an ANSI Standard definition since the 90s,
but that hasn't kept programmers from rolling their own as the
situation requires, and, like Lisp, the Forth community is small,
dedicated, but somewhat fragmented.
--
dg
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Paul Wallich <··@panix.com> writes:
> when I come to McCLIM or SLIME or whatever and read that these parts
> don't work, those great new bits will be coming real soon now, and
> that issue over there is in the process of being resolved, it makes
> me think, "best to come back in six months".
[...]
> the idea of tracking tool changes and rebuilding on a weekly basis,
> and possibly having to throw everything out if a new version changes
> what my code should do puts me off.
Note that "if you don't want to track changes on a weekly basis then
come back in six months" is pretty much the official SLIME slogan. ;-)
We've even erected small barriers (like only distributing from CVS)
purely to avoid raising false expectations and delaying the first
impressions of sensible people like yourself until a time when they'll
be more favourable.
We's doing our bit, I tells ya! :-)
P.S., our hats are off to Lisp hackerdom of the present! Our ChangeLog
currently records contributions of code from twenty-six (!) noble
souls from around the world since we got started last September, to
say nothing of the non-code help we've had. There's lots of "roll up
your sleeves" hackerish spirit about, even though this newsgroup isn't
the focal point that one might expect.
Cheers,
Luke
On Mon, 29 Mar 2004 21:09:02 +0200, Luke Gorrie <····@bluetail.com> wrote:
> There's lots of "roll up your sleeves" hackerish spirit about, even
> though this newsgroup isn't the focal point that one might expect.
From my experience with c.l.l in the last years I'd say that this is
/exactly/ what I would have expected... :)
Edi.
Lots of libraries that do both the mundane and interesting would be
nice. I mean lots in the Perl sense. Also there should be portable
GUIs, threading, etc. Like Java. Only done right.
That's the sort of thing that attracts programmers.
I personally am interested in a slightly different tack. I am more
of an applications developer than a systems hacker. I think an
application that was powerful and compelling enough that people would
buy a computer to run that application that just happens to also be
written in CL with CL as its built in extension language could go a
long way to building CL mindshare.
If such an application could be delivered with only ten human years
worth of programming effort, people would be impressed. Furthermore,
if the application itself was popular enough, third parties as well
as in-house developers would learn the APIs for extending the
application. By having the full CL compiler and features available
in the application, there would be no need to purchase seperate
development tools for extending the application.
I'm really thinking along the lines of a desktop application, but I
imagine it is possible to create a compelling server application like
this. The trick to that is selling to a Java based (or .NET based)
shop.
Then again, in a few years most Java developers will probably be
working in India.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber <·············@verizon.net> wrote:
> Lots of libraries that do both the mundane and interesting would be
> nice. I mean lots in the Perl sense. Also there should be portable
> GUIs, threading, etc. Like Java. Only done right.
Since Paolo and Christophe both said things I would
have wanted to say, but far more elequenty, I'll stray off topic:
It seems that sometime the desire to do the Right Thing paralyses lispers
-- where a perl hacker would have hacked out a quick and dirty solution
some lispers start thinking "what's this all about...", and quickly
conclude that doing the right thing is both complex and difficult. And
then use perl (or whatever) instead.
This is sad.
While the tradition doing things right is good thing, it should not be a
cause for inaction. If the general solution is either unnecessary for the
given task or impossible given the time constraints, it's OK to hack a
half-arsed semi-solution -- as long as you know it's that and label it as
such.
Once _a_ solution exists and is available to the lisp-using world,
a second iteration is likelier to happen, and will hopefully provide a
better approximation of the Right Thing.
Cheers,
-- Nikodemus
·········@random-state.net writes:
> While the tradition doing things right is good thing, it should not be a
> cause for inaction. If the general solution is either unnecessary for the
> given task or impossible given the time constraints, it's OK to hack a
> half-arsed semi-solution -- as long as you know it's that and label it as
> such.
>
> Once _a_ solution exists and is available to the lisp-using world,
> a second iteration is likelier to happen, and will hopefully provide a
> better approximation of the Right Thing.
I agree with all you say. I would add that In my mind, a partial
solution can be The Right Way. It is just incomplete.
While it seems like a disadvantage in the short term, the way
libraries are shapping up in Lisp may be a good thing. Java's
threading model has some shortcommings. Or at least that is what
I've heard. What it does do though is provide the same API for
Posix, Win32, and whatever else a JVM might get ported to.
To clarify, there is often more than one way to do something.
Hopefully enough people will try to do something in different ways
and the community will ultimately vote on the best way.
Another challenge for libraries is making them portable across CL
implimentations. I've got CLISP, CMUCL, OpenMCL, and SBCL installed
on my machines. For compiling C code, I just have GCC. Even a
language such as C has standard APIs in it like printf(). I would
suggest that is some level of abstraction. I think a Lisp threading
library, just as an example, can have its best change of acceptance
by conforming to some API and having that as an abstraction layer for
working on the different Lisp systems people are interested in
supporting.
Admittedly I am still very much in the early stages of learning
Lisp. So far, it is just another programming language. I'm sure
that opinion will change as I learn to use the more advanced features
productively.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
From: ·········@random-state.net
Subject: Re: What would you do with 10 Man Years?
Newsgroups: comp.lang.lisp
References: <···············@ID-197644.news.uni-berlin.de> <··············@david-steuber.com> <··············@midnight.cs.hut.fi> <··············@david-steuber.com>
Organization:
David Steuber <·············@verizon.net> wrote:
> Another challenge for libraries is making them portable across CL
> implimentations. I've got CLISP, CMUCL, OpenMCL, and SBCL installed
I disagree strongly.
[I'm reading your meaning here as "libraries should be portable
or they're worthless" -- that may have not been what you ment,
but I won't let that stand in between me and rant.]
"It's got to be portable" is just another paralyzing factor. Most
library authors are not writing their stuff from the goodness of
their heart, but because they want it for themselves. From their
POV clamoring for portability is a message that "nah, it's no
use publishing this as it works only on <implementation-x>".
Add to this that more often than not portability issues fall into
one of the following categories:
* Implementation shortcomings. Eg. bugs in esoteric features,
or incomplete MOP.
* Implementation specific extensions. Most commonly sockets
and FFI.
If library X doesn't work on your implementation because of
either of these, then in the first case I'd be moderately
surprised if the implementors of your lisp weren't happy to hear
about the first case -- and even fix it, given code in the wild
that actually uses it. In the second case given an implementation
with "normal" support for sockets and FFI it's not generally too
hard to either patch the library to support UFFI or write an
abstraction layer over the used functionality with a backend
per supported implementation.
It's somewhat silly to assume that the original author would do
all this, especially when he is primarily writing code for his/her
own use. Sometimes, some people, the extra mile is taken, but even
suggesting that there is some sort of moral imperative for library
authors to do that is questionable at best.
A rarer case is having an implementation specific extension (like
foreign callbacks or good xref) that isn't yet widely supported --
in which case a portable implementation would originally have
required ugly workarounds or have been impossible. But if you want
to port it, and your implementation doesn't support this
newfangled feature you can/should:
* Given a commercial implementation talk to your vendor about
the extension.
* Given an open source implementation either add the extension
yourself and submit the patch, hire a developer to do it
for you, or raise the subject on the right mailing list
and hope that someone does it for you.
The one single this that has a really bad track record of
achieving anything is whining on cll. ;-)
Cheers,
-- Nikodemus
·········@random-state.net writes:
> David Steuber <·············@verizon.net> wrote:
>
> > Another challenge for libraries is making them portable across CL
> > implimentations. I've got CLISP, CMUCL, OpenMCL, and SBCL installed
>
> I disagree strongly.
>
> [I'm reading your meaning here as "libraries should be portable
> or they're worthless" -- that may have not been what you ment,
> but I won't let that stand in between me and rant.]
>
> "It's got to be portable" is just another paralyzing factor. Most
> library authors are not writing their stuff from the goodness of
> their heart, but because they want it for themselves. From their
> POV clamoring for portability is a message that "nah, it's no
> use publishing this as it works only on <implementation-x>".
I must admit you have a good point. Here is a scenario where I might
release a library for the "general good of Lisp".
I am writing an application under FooCL. FooCL supports the main
features I need in a Lisp which is why I chose it in the first
place. In the course of developing MyAPP, I find that a portion of
it that is not necessarily MyAPP specific and probably useful for
MyOtherAPP and MyYAAAP. So this code I factor out into MyLip-CL.
I'm kind of happy with MyLib-CL. It is "good enough" for now, but it
could be better. Maybe performance can be improved. Maybe other
features would be useful that fit within MyLib-CL. I don't have the
resources to twiddle MyLib-CL indefinitely, so I decide that it would
be in my best interest to get others to also use MyLib-CL. I release
it under some sort of open source license that encourages others who
want MyLib-CL's functionality to use it and submit patches back to me.
Other FooCL users can use it out of the box. They start to use
MyLib-CL and submit patches that improve the features and
performance. Sadly, BarCL and BazCL users find it won't compile.
However, a BarCL user finds a way to make MyLib-CL compile under
BarCL without breaking it or harming it under FooCL. This leads to a
portability patch. Unfortunately the case is not so simple for BazCL
users. It turns out that IMPLEMENTATION-FEATURE-X is broken or
missing. The only fix is to deal with IMPLEMENTATION-FEATURE-X.
BazCL users have several options now. They can fix BazCL to have
IMPLEMENTATION-FEATURE-X. They can fork MyLib-CL so that it works
with BazCL but their changes do not port back to FooCL or BarCL.
They can live without MyLib-CL altogether.
I think this addresses/covers the points you made.
It is of course possible that MyLib-CL is only ever interesting to me
and the general community never picks up on it. Still, putting
MyLib-CL out there has provided a chance for improving the
availability of libraries for Lisp.
If I'm not mistaken, this kind of follows the "worse is better"
approach. It has worked well for Unix. Windows had been a success.
I guess this would be a good model for improving the state of Lisp.
I don't think there are any real secrets here. Just the obviouse.
* Write popular apps in Lisp that can be delivered faster and
maintained more easily than with other languages.
* Write popular libraries in Lisp that can be found in a common
location like CPAN, CTAN, et al. Better search facilities would
also be nice.
* Good documentation for the libraries.
* Create better development tools for Lisp that reflect and improve
upon the state of the art for other language development
environments.
If Lisp makes everyone's jobs easier, they will come.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
Will Hartung asked:
> Simply put if you had 10 man years at your disposal, how
> would you allocate it to advance Common Lisp?
I few days a go I jotted down a manifesto for the use of
computers in schools. It would take a big wodge of cash to
develop course materials and advance the manifesto to the
point at which governments might take at interest, but if
you want to stretch you imagination, here it is:
(title "A manifesto for the use of computers in schools")
(section "In two sentences"
"We try to teach 11 to 16 year olds to speak French.
We should make a similar attempt to teach 11 to 16 year olds
to program computers using ANSI Common Lisp")
(section "Why?"
"School subjects can be hard in two different ways."
"They might be laborious. If you wish to learn a foreign
language, such as French or German, there is much vocabulary
to learn, and this requires persistent application over a
period of years. "
"They might be abstract. Algebra is a welcome relief to some
children, sparing them the labours of arithmetic, and yet it
is a nightmare to others, because they do not \"get it\". As
for calculus, no-one can deny that it is very hard, and yet
there is not much to it. All the hard work is in cultivating
the intellect so that it can ascend to the higher level of
abstraction."
"Computer programming lies somewhere in between. One calls
them computer programming languages with good
reason. Learning one is a little like learning a natural
language. There is vocabulary and grammar to learn. On the
other hand, programming computers is similar to
mathematics. One defines functions using variables. Yet it
is not as abstract as mathematics. One is concerned with
constructive techniques that produce answers directly. There
is no equivalent to a mathematician's existence proof that
shows something must exist without constructing it."
"The attraction of computer programming as a school subject
is that it cultivates the intellect, providing a ladder that
one can climb towards mastering higher levels of
abstraction. At the moment, a child who doesn't \"get\"
algebra is just stuck. Perhaps it will click later. With
computer programming on the curriculum, they are in a
limited sense doing algebra anyway, and since the computer
fills in the numbers for them, it is less abstract, and
hence more approachable."
"Much that we consider difficult, both as children and as
adults, lies in topics that are hard to visualise. In
statistics, it is hard to visualise variability. It is easy
enough to visualise ten coins, six showing head, and four
showing tails. It is hard to visualise all 1024
possibilities. How many of them show 6 heads and 4 tails?
One learns to calculate 10!/(6!4!) = 210. It is at this
point that one misses the educational significance of
computers. The mistake is to consider the computer as a tool
for doing arithmetic. One defines a function to compute
factorial:"
(code
"(defun fac(n)
(case n
(0 1)
(t (* n (fac (- n 1))))))")
"and uses it to perform the arithmetic efficiently"
(code
"(/ (fac 10)(fac 6)(fac 4)) => 210")
"The significance for education is that one could more easily
program the computer to go through all 1024 and count up
those with 6 heads."
(code
"(loop for i below 1024
count (= (logcount i) 6))
=> 210")
"Perhaps that is too slick to make the point.
Consider instead"
(code
"(let ((running-total 0))
(dolist (coin1 '(h t))
(dolist (coin2 '(h t))
(dolist (coin3 '(h t))
(dolist (coin4 '(h t))
(dolist (coin5 '(h t))
(dolist (coin6 '(h t))
(dolist (coin7 '(h t))
(dolist (coin8 '(h t))
(dolist (coin9 '(h t))
(dolist (coin10 '(h t))
(when (= 6
(count 'h
(list coin1 coin2 coin3 coin4 coin5
coin6 coin7 coin8 coin9 coin10)))
(incf running-total))))))))))))
running-total) => 210")
"In school a computer is a tool for making the abstract
concrete. If children can write their own programs, they
come into possession of an educational toy that has the
potential to let them explore and eventually understand
abstract material that traditionally eludes most adults.")
(section "Two connected issues"
(paragraph "I advance a compound proposition,
proposing to teach 11 to 16 year old to program computers,
and also suggesting a specific language.
These two propositions are not as separable as one might
at first suppose. The notion of teaching 11 to 16 year olds
to program computers is actually several distinct ideas with
starkly contrasting merits. We break the notion into three
pieces, teaching a toy language, teaching the language that
daddy uses at work, and teaching an advanced language.")
(section "Teach a toy language"
"We subdivide. A \"toy language\" could mean a language
designed to fit within the limitations of computer hardware
cheap enough to be given to children. So the language itself
might not be targeted towards children, indeed it might be
that the language itself was so simple that it was hard to
use. BASIC (the Beginners All-purpose
Symbolic Instruction Code) can be seen in this light. Not a
nice language to program in, but it ran on cheap
micro-computers that youngsters could actually afford. Since
computer hardware is now much cheaper, there is no merit in
teaching a language that is a toy language in this sense."
"Alternatively, a toy language could mean a language
specifically designed for children or for education. Various
examples come to mind, such as Pascal, Scheme, or Logo. We
consider Scheme separately, as an advanced language. We
distinguish between Pascal and Logo."
"Pascal is an arm-chair theorists idea of a language for
education. It is restrictive, fussy, and boring. Beginners
are put off because there is syntax to learn, but it is not
powerful, so one is not rewarded for ones effort."
"I have read good reports of Logo. There is no doubt that
much is learned by playing with Logo; it is an educational
toy, not just a toy. Also children enjoy playing with
it. That is surprising for an educational toy. So I find no
fault with Logo, for younger children, although this essay
advocates something else."
"The drawback with toy languages for older children comes
from the wide variety of talents in any school. Some of the
children will have a special aptitude and move on to real
computer programming languages, either because the
curriculum specifies it, or, more damagingly, through
independent study, perhaps aided by a parent in the computer
industry. Once the other children realise that the language
they are studying is not the real thing they will lose
interest."
"One sees the same problem with attempts to teach Irish
Gaelic in schools in Eire. Once the children realise that
no-one speaks the language, and they are merely the victims
of adult inanity, they stop trying. One would have better luck
teaching Chinese. At least the children would be able to
believe in the project of learning a language with a
thousand million native speakers.")
(section "Teach the language that Daddy uses at work"
"Again two distinct ideas masquerade as one."
"The first incarnation is simply to use C++ because it is
widely used in industry. They problem with this is that C++
is a disaster. It is complicated without being powerful. It
is so complicated that it is unlearnable and
unteachable. Programmers pick it up in the course of a long
apprenticeship. A technical issue is that C++ does not have
what computer industry jargon calls a \"garbage
collector\". Non-technical readers will want to know if they
can rely on the emotional resonances of this technical term
without understanding what it actually means. They can; lack
of a "garbage collector" does indeed make C++ stink like a
Bombay slum.
There is nothing here suitable for schools."
"The industry has discovered that when students go to
University at 18, and start to learn programming, they
struggle, and cannot master C++ in the 3 years
available. The move is to cleaner language designs, that are
easier to learn. Sun Micro-systems has produced Java, and
Microsoft now has a rival, called C#. Easier to learn sounds
like an advantage for schools, but these languages have two
drawbacks."
"The first drawback is that they are targeted at motivated
adults. They are boring language languages. You have quite a
lot to learn, just to get started. They are not very
powerful. You have quite a lot of code to organise to write
a program that does anything clever."
"The second drawback it that they are based on a particular
vision of the computing industry. Would be Programmers start
learning from scratch at 18, and must find work at 21. So
one needs languages that are simplified to fit this
vision. But it is a vision of programmers who are less
skilled than one would like because they started too
late. If one is to teach programming in schools why pay the
cost in lost productivity of simplified, crash course,
languages?")
(section "Teach an advanced language"
"The goal is to bring on a new generation of scientists and
engineers. The focus is to stimulate the children with a
view to them mastering algebra and calculus. Learning to
program is a means to an end."
"Given a function, a student can differentiate analytically
using pencil and paper. Has he got it wrong? He can program
his computer to differentiate the function numerically, and
also to evaluate the result he obtained by pencil and
paper. If they disagree, there is a mistake some-where."
"He can also try programming his computer to differentiate
symbolically. Does these involve his teacher in checking
diabolical differentiation routines written by his
students? No. The student can make the same comparisons as
before, evaluating the derivative by evaluating the result
of his differentiation program, and also by numerically
differentiating the function he started with. Can the
student get the answers to agree. I see no way to shield the
student from the problem of numerical differentiation
suffering badly from cancellation error, with the
consequence that the answers will not agree exactly, but
that is an important lesson in itself."
"This is an enormously illuminating exercise. It is also a
very demanding one. Perhaps it will forever be university
level work. My point is to advocate teaching computer
programming early. Then, at the appropriate time, writing
computer programs can bring tangibility to problems that are
otherwise too abstract for all but a narrow elite."
"A controversial feature of both Common Lisp and Scheme is
the use of S-expression notation. Instead of 2+2 one write
(+ 2 2). A quadratic equation looks like
(+ (* 3 x x)
(* 4 x)
7)
The point is that formulae are everywhere represented as
lists. In the example, a list of four items, the first is
the addition symbol, the last is the number 7, and the
middle two are both lists, in each case starting with a
symbol to denote multiplication. When it comes to writing
programs to differentiate this symbolically and
numerically, and compare the answers, using this list
representation is a huge advantage. A vast pile of busy
work, that is exhausting without being in any way
illuminating, is eliminated."
"Scheme is already important in university education so it
might seem natural to try to move it down the age range and
into schools. This misunderstands Schemes role in
education. Professors praise Scheme for its simplicity. They
mean something quite specific. The specification for Scheme
has been kept very lean. So at top universities, Computer
Science students can write their own implementations of this
computer language. This is wonderful for teaching elite
Computer Scientists how to implement computer languages. But
there is a price to pay. The language really has been kept
very lean; features one would love to have, if one could be
sure that somebody else had the burden of implementing them,
have been omitted. It makes Scheme less useful than Common
Lisp when ones goal is to take computer language
implementation for granted and use the computer as a tool to
assist in learning other subjects."))
From: Cesar Rabak
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <4065C3CC.4090904@acm.org>
Jan Rychter escreveu:
>>>>>>"Will" == Will Hartung <·····@msoft.com>:
> Will> Here's more of a strategic platform question. Simply put if you
> Will> had 10 man years at your disposal, how would you allocate it to
> Will> advance Common Lisp?
>
[8 nice ideas snipped]
I would put a 5A step:
Popularize offering short courses (and other forms of training) and all
the exposure of Lisp for non-lispers, including 'demos', freeware, etc.
in cover CDs and download repositories.
Otherwise we'll end up with all the (10 man-years) investment going only
for the same community and lisp vegetative population growth is very
small ;-)
--
Cesar Rabak
Will Hartung wrote:
> Here's more of a strategic platform question.
>
> Simply put if you had 10 man years at your disposal, how would you
> allocate it to advance Common Lisp?
I would spend the time bringing some critically needed system-level features
the the current crop of free compilers and packaging a kick-ass
open-source/freeware programming environment centered around CL.
Specifically, I would
0. Start with CMUCL or SBCL. Rationale: they are free and produce good
quality, high-speed code. Yes, there are other free systems out there
(CLISP), but you want programmers to appreciate your platform and anything
that says "interpreted bytecode" just turns people off immediately, no
matter whether CLISP is actually fast or not. Note that I'm not slamming
CLISP here, just talking about newbie impressions. "Interpreted bytecode" =
slow in the minds of many, particularly after the industry has watched what
Java went through.
1. Take either CMUCL or SBCL and enhance them with great threading support.
Rationale: threads are just a must nowdays. Gotta have them.
2. Port this beyond the Unix-like platforms (Windows, specifically).
Rationale: Windows still rules most developer desktops out there. While I
love Linux, you can't expect a programmer to install a complete OS just to
test out a programming language.
3. Bundle this together with a set of defacto-standard libraries supporting
network development (good, complete(!) sockets support), web development (a
high-performance web server, app server, etc.), markup langauges (XML,
HTML, etc.), OS support (beyond basic filesystem), and GUI development
(GTK+ bindings, Win32 bindings, etc.). Rationale: get some high-quality
libraries that make a programmer productive immediately for non-trivial
programs.
4. Create a basic IDE that isn't centered on Emacs but may in fact work much
the same way. Rationale: emacs is great, but comes with its own set of
infrastructure. On Linux this is manageable, but on Windows it's a killer.
5. Make the installation of this bundle as simple as possible (one binary
RPM on Linux, an InstallShield wizard on Windows, etc.). Rationale:
anything that makes me install 5+ separate packages reduces my chances of
actually getting it right and getting to the end.
6. Write a whole lot of documentation for the system, from basic
system-level stuff like how the debugger works, to API documentation for
the libraries. Rationale: we can't expect users to read the source code all
the time to figure out how something works. The Hyperspec is not a good
document for most people to learn anything from. I'm consistently baffled
by it.
The main goal here is to make Lisp accessible, give newbies a
low-barrier-to-entry system, and make them productive as soon as possible.
Right now, Lisp is a great language, but you gotta *want it bad* to really
make use of it. You either have to assemble everything yourself (download
SBCL, download SLIME, figure out ASDF, install some packages via ASDF,
install some other packages by hand, figure out the package APIs by reading
the code since nothing is documented; or you pay big bucks to the
commercial guys (or you get one of the crippled commercial versions, which
doesn't really work for writing real programs). If you're somebody wanting
to try out this great language, the barrier is steep, either in time/skill
or cash.
Note that I don't begrudge the commercial guys their profit; they have a
business to run. The problem is that newbies are confronted with no good,
low-investment (time or cash) options that allow them to try out the
language and see what it can do.
Yes, it's fairly easy to download CLISP and write FACTORIAL at the repl, but
that's a far cry from writing anything "interesting" in a modern commercial
sense. To go beyond that requires a lot more infrastructure which today is
difficult to acquire.
-- Dave
--
Dave Roberts
·············@re-move.droberts.com
From: Cesar Rabak
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <40671754.50404@acm.org>
Dave Roberts escreveu:
> Will Hartung wrote:
>
>
>>Here's more of a strategic platform question.
>>
>>Simply put if you had 10 man years at your disposal, how would you
>>allocate it to advance Common Lisp?
>
>
> I would spend the time bringing some critically needed system-level features
> the the current crop of free compilers and packaging a kick-ass
> open-source/freeware programming environment centered around CL.
>
> Specifically, I would
[snipped]
> 4. Create a basic IDE that isn't centered on Emacs but may in fact work much
> the same way. Rationale: emacs is great, but comes with its own set of
> infrastructure. On Linux this is manageable, but on Windows it's a killer.
I would like to suggest then we change from "Create a basic IDE" to
"create a plug in for an already established IDE" like Eclipse.
Rationale: A 'basic' will always bring detractors and a rough
programming environment will make people feel the environmaent 'imature'.
Additionally, joining with Dave's '6.' write a thorough tutorial based
on this environment which can make people comfortable on doing non
trivial programms as fast as other programming languages/environments.
just my .019999...
--
Cesar Rabak
Cesar Rabak wrote:
> Dave Roberts escreveu:
(I love that: "escreveu"... words are so fun).
> I would like to suggest then we change from "Create a basic IDE" to
> "create a plug in for an already established IDE" like Eclipse.
> Rationale: A 'basic' will always bring detractors and a rough
> programming environment will make people feel the environmaent 'imature'.
I agree with that. Creation has many forms. Why recreate the wheel if there
is already something there to build off of. What isn't clear to me is how
Java and CL would do at coexisting in the same IDE. This isn't to say that
they can't, only it might be a technical challenge.
> Additionally, joining with Dave's '6.' write a thorough tutorial based
> on this environment which can make people comfortable on doing non
> trivial programms as fast as other programming languages/environments.
Right. Make it easy and doc it. That's the recipie.
> just my .019999...
You need to use an accounting system with rationals and bignums... ;-)
--
Dave Roberts
·············@re-move.droberts.com
From: Cesar Rabak
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <40682C30.1040100@acm.org>
Dave Roberts escreveu:
> Cesar Rabak wrote:
>
>
>>Dave Roberts escreveu:
>
>
> (I love that: "escreveu"... words are so fun).
Yep!
>
>
>>I would like to suggest then we change from "Create a basic IDE" to
>>"create a plug in for an already established IDE" like Eclipse.
>>Rationale: A 'basic' will always bring detractors and a rough
>>programming environment will make people feel the environmaent 'imature'.
>
>
> I agree with that. Creation has many forms. Why recreate the wheel if there
> is already something there to build off of. What isn't clear to me is how
> Java and CL would do at coexisting in the same IDE. This isn't to say that
> they can't, only it might be a technical challenge.
>
Eclipse is technically an IDE written in Java but supposed to support
more than just Java. It has plug-ins for a lot of other languages like
C/C++, C#, COBOL, etc. Just for an example (IMHO interesting) Amzi chose
this IDE for its new version of their Prolog.
I agree that for going on this path we would need: or the expertise of
Java people to make the plug-in(s) for the CL environment(s) we would
like to have ported, or have a Lisp which can compile to Java bytecodes.
Probably the first is easiest and more likely to pursue. Secondly, a CL
which is available for at least Linux and Windows should selected.
As a third thought, a comment done in another thread in this NG is also
pertinent: the CL systems must be installable in the platform's native
way, i.e., RPM or Debian packages in Linux and some form of installer
("SETUP.EXE" or "CL-something.msi") in Windows.
>
>>Additionally, joining with Dave's '6.' write a thorough tutorial based
>>on this environment which can make people comfortable on doing non
>>trivial programms as fast as other programming languages/environments.
>
>
> Right. Make it easy and doc it. That's the recipie.
>
>
>>just my .019999...
>
>
> You need to use an accounting system with rationals and bignums... ;-)
>
Yes! why do you think I always canvass to use Lisp in the teams I join
in? ;-)
Cheers,
--
Cesar Rabak
Cesar Rabak wrote:
> Dave Roberts escreveu:
> Eclipse is technically an IDE written in Java but supposed to support
> more than just Java. It has plug-ins for a lot of other languages like
> C/C++, C#, COBOL, etc. Just for an example (IMHO interesting) Amzi chose
> this IDE for its new version of their Prolog.
Interesting. I knew they had a plugin for C/C++, but not for the others. I
love Eclipse for my Java work, so no issues there. I think it's the best
IDE, hands down.
> I agree that for going on this path we would need: or the expertise of
> Java people to make the plug-in(s) for the CL environment(s) we would
> like to have ported, or have a Lisp which can compile to Java bytecodes.
>
> Probably the first is easiest and more likely to pursue. Secondly, a CL
> which is available for at least Linux and Windows should selected.
Agreed.
> As a third thought, a comment done in another thread in this NG is also
> pertinent: the CL systems must be installable in the platform's native
> way, i.e., RPM or Debian packages in Linux and some form of installer
> ("SETUP.EXE" or "CL-something.msi") in Windows.
Yes, I mentioned that exact thing in my OP. This is all about packaging a
competitive, free environment to make it very easy to install, try, and
then remove if the user isn't interested. Trying out Lisp should be a
2-hour activity, not a 2-week activity with all sorts of downloads and
installs. Java actually does this pretty well, but Eclipse still isn't
packaged with the JDK. That's 2 installs there, but it could be even
better.
--
Dave Roberts
·············@re-move.droberts.com
From: Joe Marshall
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <ad1zr8ld.fsf@ccs.neu.edu>
"Will Hartung" <·····@msoft.com> writes:
> Here's more of a strategic platform question.
>
> Simply put if you had 10 man years at your disposal, how would you allocate
> it to advance Common Lisp?
Give me 20. I'll give you a lisp machine that runs on pc hardware and
supports linux and microsoft applications.
From: Ray Dillinger
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <406A00A6.501DD059@sonic.net>
Joe Marshall wrote:
>
> "Will Hartung" <·····@msoft.com> writes:
>
> > Here's more of a strategic platform question.
> >
> > Simply put if you had 10 man years at your disposal, how would you allocate
> > it to advance Common Lisp?
>
> Give me 20. I'll give you a lisp machine that runs on pc hardware and
> supports linux and microsoft applications.
I'm in for at least part of it. Give me a list of calls you want
implemented and success criteria for them and I'll start tomorrow.
Bear
From: Julian Stecklina
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <86brmd3kt2.fsf@web.de>
Ray Dillinger <····@sonic.net> writes:
> Joe Marshall wrote:
>>
>> "Will Hartung" <·····@msoft.com> writes:
>>
>> > Here's more of a strategic platform question.
>> >
>> > Simply put if you had 10 man years at your disposal, how would you allocate
>> > it to advance Common Lisp?
>>
>> Give me 20. I'll give you a lisp machine that runs on pc hardware and
>> supports linux and microsoft applications.
>
> I'm in for at least part of it. Give me a list of calls you want
> implemented and success criteria for them and I'll start tomorrow.
I am in, too. I am willing to code everything from which a Lisp OS
could benefit. (This is only half-serious, but the offer stands, if
someone has an idea/plan.)
Regards,
--
Julian Stecklina
Signed and encrypted mail welcome.
Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
Any sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
- Greenspun's Tenth Rule of Programming
Julian Stecklina <··········@web.de> writes:
> >> Give me 20. I'll give you a lisp machine that runs on pc hardware and
> >> supports linux and microsoft applications.
>
> I am in, too. I am willing to code everything from which a Lisp OS
> could benefit. (This is only half-serious, but the offer stands, if
> someone has an idea/plan.)
Likewise. If there is a serious request for participants, I would love
to be part of this.
--
vsync
http://quadium.net/
Banking on my hopes that whoever grades this will just look at the
pictures, I drew an exponential through my noise. I believe the
apparent legitimacy is enhanced by the fact that I used a complicated
computer program to make the fit.
-- http://www.cs.wisc.edu/~kovar/hall.html
Julian Stecklina <··········@web.de> writes:
>> I am in, too. I am willing to code everything from which a Lisp OS
>> could benefit. (This is only half-serious, but the offer stands, if
>> someone has an idea/plan.)
vsync <·····@quadium.net> writes:
> Likewise. If there is a serious request for participants, I would
> love to be part of this.
You are both, together with everybody else, invited to join in and
write some code for/with Movitz. It just recently got some minimal GC
support, btw.
<URL:http://www.common-lisp.net/project/movitz/>
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> You are both, together with everybody else, invited to join in and
> write some code for/with Movitz. It just recently got some minimal GC
> support, btw.
I find this interesting, and will have to look into it further.
However, my primary interest was in the idea of a Lisp OS that supports
Linux (and to a lesser extent) Windows binaries. Systems don't exist in
a vacuum, and an OS that could run only CL code would be of limited
usefulness to me (and I suspect many others) and would remain merely an
interest for quite some time, while an application base was being
developed.
Is there room in Movitz to elegantly allow for compatibility APIs/ABIs?
Does it, or will it, have a documented and stable FFI for C code?
--
vsync
http://quadium.net/
Banking on my hopes that whoever grades this will just look at the
pictures, I drew an exponential through my noise. I believe the
apparent legitimacy is enhanced by the fact that I used a complicated
computer program to make the fit.
-- http://www.cs.wisc.edu/~kovar/hall.html
vsync <·····@quadium.net> writes:
> Is there room in Movitz to elegantly allow for compatibility
> APIs/ABIs? Does it, or will it, have a documented and stable FFI
> for C code?
There is no FFI in Movitz now. This is of little interest to me
personally, but if someone else wants to look into it that'd be fine
by me.
I have thought a little bit about the possibility of having some sort
of binary compatibility layer for linux etc. binaries. I think this
would be possible, but a lot of work, and you'd end up with something
mostly inferior to the real thing without any obvious benefit that I
can see. In my view, the exact same things that make the idea of a
lisp OS interesting, to a large extent precludes linux/windows/etc
compatibility.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> In my view, the exact same things that make the idea of a lisp OS
> interesting, to a large extent precludes linux/windows/etc
> compatibility.
Ivory-towered academic!
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Julian Stecklina
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <86wu5079tl.fsf@web.de>
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> You are both, together with everybody else, invited to join in and
> write some code for/with Movitz. It just recently got some minimal GC
> support, btw.
>
> <URL:http://www.common-lisp.net/project/movitz/>
I'll try to get this working on my laptop using box and report back.
Regards,
--
Julian Stecklina
Signed and encrypted mail welcome.
Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
Any sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
- Greenspun's Tenth Rule of Programming
From: Joe Marshall
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <fzbngym0.fsf@ccs.neu.edu>
vsync <·····@quadium.net> writes:
> Julian Stecklina <··········@web.de> writes:
>
>> >> Give me 20. I'll give you a lisp machine that runs on pc hardware and
>> >> supports linux and microsoft applications.
>>
>> I am in, too. I am willing to code everything from which a Lisp OS
>> could benefit. (This is only half-serious, but the offer stands, if
>> someone has an idea/plan.)
>
> Likewise. If there is a serious request for participants, I would love
> to be part of this.
Frode Vatvedt Fjeld has something going. My ideas are in still in the
proof-of-concept stage.
From: Cesar Rabak
Subject: Re: What would you do with 10 Man Years?
Date:
Message-ID: <40682FBA.6050708@acm.org>
Geoff escreveu:
> "Will Hartung" <·····@msoft.com> writes:
>
>
>>Here's more of a strategic platform question.
>>
>>Simply put if you had 10 man years at your disposal, how would you allocate
>>it to advance Common Lisp?
>>
[snipped]
> .NET CL compiler:
> * This would be really useful to me right now, but writing a CL
> compiler seems to take quite a while (estimates?).
Talking about this possibility: has anyone tried RoboWiz NetLisp?
--
Cesar Rabak
I would spend two-thirds of the money on improving extra-standard
features of a free CL implementation, and one third on the
implementation of library code.
By extra-standard features, I mean things like
* improved platform integration: real-time GC, a flexible memory
management scheme that facilitates cooperation with foreign code,
ability to generate ELF executables
* improved network support: IPv6, support for TLS/SSL with
certificate handling, scalable event handling (like SERVE-EVENT in
CMUCL)
* sophisticated streams support: make it easy to write a servlet over
HTTPS that retrieves chunked base64-encoded data by composing an
SSL stream with an HTTP/1.1 stream with a base64-decoding stream.
I would support this work on a single high-quality free CL environment
such as SBCL, because this would obtain the most return on investment
by guaranteeing the the results are freely redistributable. I
anticipate that desirable features would be added to other
implementations over time.
Concerning library support, I would focus on network-oriented
facilities such as an IMAP server, an SMTP server, an NNTP server, a
DNS server, an LDAP server, protocols like ZeroConf service discovery.
Again, this choice is motivated by my opinion that server-side
applications are the most promising area for promoting Common Lisp's
strengths.
The overall aim would be to make it possible to implement the
core of an application like Zo� by plugging together a number
of high-quality libraries.
<URL:http://zoe.nu/>
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>