ANNOUNCE: Lisp Without Parentheses Project (Lispin) Site Open
Bill Birch
The project's goal is to provide Lisp and Scheme languages with an
indented syntax similar to SRFI 49 and
other poposals. e.g.
define (fac x)
if (= x 0) 1
* x
fac (- x 1
The site at http://www.lispin.org/ provides a wiki for collaboration
and on-line indentation pre-processor. The site itself is implemented
in an indented Lisp.
Regards,
Bill Birch
Espen Vestre
> define (fac x)
> if (= x 0) 1
> * x
> fac (- x 1
Ouch, those naked Sexps look so poor and vulnerable!
Especially the last one ;-)
--
(espen)
Bill Atkins
> define (fac x)
> if (= x 0) 1
> * x
> fac (- x 1
Who are you? Some kind of comedian?
Timofei Shatrov
everyone with this message:
>The Lispin project web site has been launched.
I love how it says "Lisp without parentheses" yet the example contains several
of these damned things :) Nice post, btw: I laughed after just reading the
title.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Frank Buss
> I love how it says "Lisp without parentheses" yet the example contains several
> of these damned things :) Nice post, btw: I laughed after just reading the
> title.
And even the title of the posting has 2 parantheses.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Ken Tilton
A parenthesis, a bracket, and a brace walk into a bar...
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Alex Mizrahi
(you :wrote :on '(27 Nov 2006 04:44:45 -0800))
(
BB> The project's goal is to provide Lisp and Scheme languages with an
BB> indented syntax similar to SRFI 49 and
BB> other poposals. e.g.
as i understand, the goal is to improve readability.
without the editor support, this things have very few sense.
but if you'll implement this in the editor, ti won't be a syntax -- but
merely a form of visualization. the editor will be able to remove
parentheses during process of visualization, and will bring them back when
it will render file for compiler.
thus, if you really want to do something, try to implement next-generation
code editor -- that will not be a text editor with some processing attached,
but yet special thing, that will understand the semantics of code you're
editing, and will visualize it in proper way, and will allow you to edit it
in proper way -- thus, it would be impossible to have malformed indentation.
i don't think it's possible to create such editor on old proportional-text
base, so you'd better make full graphical display, and visualize code as
trees (so one can visually see connections between lists, you can check how
folding is done in modern editors), and display some placeholders -- so if
guy enters "if", it should create a structure with three placeholders.
that way it will be useful, as mere syntax preprocessor it's a complete
bullshit -- it increases readability 5% decreasing realiability and
convenience 50%. you can keep reliability and convenience same only when
you'll have a custom editor that will maintain this syntax!
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Jens Axel Søgaard
>
>
> Bill Atkins wrote:
>> "Bill Birch" <bir...@tpg.com.au> writes:
>>
>>
>>> define (fac x)
>>> if (= x 0) 1
>>> * x
>>> fac (- x 1
>>
>>
>> Who are you? Some kind of comedian?
>
> A parenthesis, a bracket, and a brace walk into a bar...
1. The bartender says, "We are closed."
2. The bartender says, "What is this? A joke?"
3. The bartender says, "Left your better halfs at home?"
--
Jens Axel Søgaard
Meyer
No need to develop yet another Lisp implementation. What you need is an
editor that allows you to visualize and edit trees in any way you want.
That would make everybody happy:
- the old farts who don't seem to understand the difference between
presentation and storage/exchange
- the newbies trying to bit off more than they can chew
Problem solved.
André Thieme
The funny thing about this is that Lisp has no parentheses. With a tree
editor you could code without using a single paren. They are the visual
tool for the programmer to create a tree.
On the other hand: your language has parens.
So you could announce your project as "LWP - Lisp with Parentheses".
André
--
Ken Tilton
Jens Axel Søgaard wrote:
> Ken Tilton skrev:
>
>>
>>
>> Bill Atkins wrote:
>>
>>> "Bill Birch" <bir...@tpg.com.au> writes:
>>>
>>>
>>>> define (fac x)
>>>> if (= x 0) 1
>>>> * x
>>>> fac (- x 1
>>>
>>>
>>>
>>> Who are you? Some kind of comedian?
>>
>>
>> A parenthesis, a bracket, and a brace walk into a bar...
>
>
> 1. The bartender says, "We are closed."
There's a winner there somewhere.
Anton van Straaten
There's a "we don't take kindly to your type around here" joke in here
somewhere.
It might involve the bartender pointing to a sign reading "This is an
indentation-sensitive establishment".
Anton
Neo
> They are the visual tool for the programmer to create a tree.
I am wondering what a simple program looks like in a tree. Could you
show one? Thx.
Lars Rune Nøstdal
Pascal Bourguignon
Yes. Just read more cll :-)
http://groups.google.com/group/comp.lang.lisp/msg/3050088218d355e5
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
Joe Marshall
Ken Tilton wrote:
>
> A parenthesis, a bracket, and a brace walk into a bar...
Would that be a vertical bar or a foo bar?
Ken Tilton
I don't know, but there is a semicolon sitting at the end who comments...
JShr...@gmail.com
A Beginners' Meta FAQ for comp.lang.lisp:
http://nostoc.stanford.edu/jeff/llisp/cllfaq.html
The purpose of this page is to help those new to Lisp (aka. "newbies")
gain some background before they enter the fray of comp.lang.lisp
(c.l.l). This is not a complete Lisp FAQ! Once you have a sense of Lisp
and of how c.l.l operates you should have no trouble finding all the
additional information you need, either by your own search efforts or
by asking the community. If you have issues with any of the below
please do not send me email. Rather, post on c.l.l in the weekly thread
where this is announced (heading: "*** C.L.L README/FAQ ***").
MarkHa...@gmail.com
Yes, we already went through this with "sweet expressions". These guys
should be writing some elisp code (or their own editor), so that you
can just toggle back and forth between the two.
Kaz Kylheku
> The Lispin project web site has been launched.
>
> The project's goal is to provide Lisp and Scheme languages with an
> indented syntax similar to SRFI 49 and
> other poposals. e.g.
>
> define (fac x)
> if (= x 0) 1
> * x
> fac (- x 1
This is a counterproductive waste of time. Why? Because it's not
targetted at any real issues. After you install this kind of reader
into your Lisp system, you can do exactly the same set of things that
you could do before, at exactly the same level of abstraction, only
with a slightly different notation. Nothing new and interesting is
made possible.
Also, there is no significant codebase written in this notation, so a
front end which handles it doesn't solve any portability issues.
Writing new code which requires the notation only adds bloat to a
project, because that project will have to carry the implementation of
that notation with it forever.
All in all, this project has less value than a single useful Lisp macro.
Bill Birch
Ha ha :-) You made me laugh! Especially this statement:
"(This comes up a lot!)"
Thankyou, thankyou.
Bill
Shiro Kawai
Editor)
I think it aims at education, though.
Download, screenshot, etc:
http://www-ui.is.s.u-tokyo.ac.jp/~hara2001/dist/ (Japanese)
Paper:
http://www-ui.is.s.u-tokyo.ac.jp/~hara2001/research/gtedit/gtedit.pdf
(English)
--shiro
Pascal Costanza
I disagree about the homework bit. Posters should just make this
explicit when they post homework questions, and say what they already
tried and how far they got. Then they typically get useful feedback.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Ralf Mattes
> FYI, There is a tree editor for Scheme: GTEdit (Gesture Based Tree
> Editor)
> I think it aims at education, though.
>
> Download, screenshot, etc:
> http://www-ui.is.s.u-tokyo.ac.jp/~hara2001/dist/ (Japanese)
> Paper:
> http://www-ui.is.s.u-tokyo.ac.jp/~hara2001/research/gtedit/gtedit.pdf
> (English)
>
> --shiro
Nice idea, I' not convinced I'd use such a tool (instead of Emacs/SLIME
with paredit which attempts to be a structured editor) but it might be a
good teaching device.
BTW, i had to tweak your startup script (running on GNU/Linux Ubuntu 5.10):
yours> java -classpath ./lib/ui.jar;./lib/util.jar ui.gtedit.GTMain --configdir ./.gtedit $@
mine> java -classpath ./lib/ui.jar:./lib/util.jar ui.gtedit.GTMain --configdir ./.gtedit $@
(note the classpath separator)
Cheers, Ralf Mattes
m_l...@yahoo.com
"""
> The Lispin project web site has been launched.
>
> The project's goal is to provide Lisp and Scheme languages with an
> indented syntax similar to SRFI 49 and
> other poposals. e.g.
>
> define (fac x)
> if (= x 0) 1
> * x
> fac (- x 1
>
As I understand, newline stands for a opening paren
(define (fac x)
(if (= x 0) 1
(* x
(fac (- x 1
) )) ) )
The idea to have this sort of transformation in an editor is a good
one.
As to usefulness of this project, well, evolution of programming
languages is all about notation.
But.... I work with C code edited in different editors on different
platforms. One typical thing is that some editors define a Tab to mean
n*4 while others define it to mean x*8. At the same time, some editors
compress spaces to tabs while other compress tabs to spaces, and each
one uses its own understanding of tabs. The result is that misindented
code fragments happen very often.
MORAL: do not fill indents with whitespace.
For example,
define (fac x)
_ if (= x 0) 1
_ _ * x
_ _ _ fac (- x 1
Joachim Durchholz
> MORAL: do not fill indents with whitespace.
>
> For example,
>
> define (fac x)
> _ if (= x 0) 1
> _ _ * x
> _ _ _ fac (- x 1
That seems worse than the disease to me.
BETTER MORAL: report tabs with a compiler error.
People will quickly learn to save their files with tabs expanded ;)
Regards,
Jo
JShr...@gmail.com
> I disagree about the homework bit. Posters should just make this
> explicit when they post homework questions, and say what they already
> tried and how far they got. Then they typically get useful feedback.
Fair enough. I've fixed this.
Alex Mizrahi
(you :wrote :on '(Tue, 28 Nov 2006 04:05:12 +0100))
(
JD> That seems worse than the disease to me.
JD> BETTER MORAL: report tabs with a compiler error.
JD> People will quickly learn to save their files with tabs expanded ;)
people will quickly abandon this crap!
Joachim Durchholz
> JD> BETTER MORAL: report tabs with a compiler error.
> JD> People will quickly learn to save their files with tabs expanded ;)
>
> people will quickly abandon this crap!
Go tell the Haskellers.
Or the Pythonistas.
And try to give some informed resoning why you consider it "crap",
otherwise you'll just be laughed off.
Regards,
Jo
Alex Mizrahi
(you :wrote :on '(Tue, 28 Nov 2006 13:58:08 +0100))
(
JD>>> BETTER MORAL: report tabs with a compiler error.
JD>>> People will quickly learn to save their files with tabs expanded ;)
??>> people will quickly abandon this crap!
JD> Go tell the Haskellers.
JD> Or the Pythonistas.
JD> And try to give some informed resoning why you consider it "crap",
JD> otherwise you'll just be laughed off.
1. python does not prohibit tabs. for myself, i've prohibited using spaces
for indentation in python, and i think there will be less problems with it
if language spec allowed only tabs being used for indentation. that way it
can be made more straightforward -- one tab, one indent, not some clumsy
rules (some people can use two spaces for indentation, some people can use 8
spaces, others can use 3).
also, there would be less problems with different habbits -- some people
prefer 8-space tabs, other prefer 2-space tabs, and if code contains only
tabs, they will get what they want, since conversion will be done only for
visualization.
2. too complex syntax is one of reasons i'm not programming in Haskell, but
programming in Lisp -- lanuage with simpliest syntax possible.
maybe i'd prefer to have static typization and other Haskell goodies, if not
that odd syntax.
i admit that some people find that ok, but i'm not of their number.
jayessay
fubar ...
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Joachim Durchholz
> (message (Hello 'Joachim)
> (you :wrote :on '(Tue, 28 Nov 2006 13:58:08 +0100))
> (
>
> JD>>> BETTER MORAL: report tabs with a compiler error.
> JD>>> People will quickly learn to save their files with tabs expanded ;)
> ??>> people will quickly abandon this crap!
>
> JD> Go tell the Haskellers.
> JD> Or the Pythonistas.
>
> JD> And try to give some informed resoning why you consider it "crap",
> JD> otherwise you'll just be laughed off.
>
> 1. python does not prohibit tabs.
Neither does Haskell.
AFAIK it's considered a mistake in both camps today.
> for myself, i've prohibited using spaces
> for indentation in python, and i think there will be less problems with it
> if language spec allowed only tabs being used for indentation. that way it
> can be made more straightforward -- one tab, one indent, not some clumsy
> rules (some people can use two spaces for indentation, some people can use 8
> spaces, others can use 3).
That's not a problem. It's easy to define indentation as "has more
indent than the previous line". That way, everybody can indent as much
as he likes.
> also, there would be less problems with different habbits -- some people
> prefer 8-space tabs, other prefer 2-space tabs, and if code contains only
> tabs, they will get what they want, since conversion will be done only for
> visualization.
I agree with that. Tabs do have advantages in this respect.
Unfortunately, there's a long tradition of using tabs as a weak
compression device, by replacing eight spaces with a tab. Files written
with settings like that have an unholy mixture of spaces and tabs that
will display with different indentation structure, depending on what the
tab setting of the reader is.
Of course, that's mainly an argument against mixing spaces and tabs;
sticking just with tabs and disallowing spaces at the start of a line
would be an option.
Unfortunately, there are environments that don't have tab characters.
/370 compatible "big iron" machines are the most common variant.
Insisting on tabs simply Won't Work for these - and they are still in
quite widespread use.
> 2. too complex syntax is one of reasons i'm not programming in Haskell, but
> programming in Lisp -- lanuage with simpliest syntax possible.
Haskell's syntax is almost as simple as you can get and not have Lisp.
IOW you're firmly locked into Lisp.
BTW I don't think that Lisp's syntax is really simpler than that of
Haskell. Sure, I don't have to learn keyword syntax, but the macros
impose rules "if you want to have feature X, then you must use keyword
BLAH and BLUB in these-and-those places", which is syntax.
Haskell's structure isn't *that* different; it's defined in terms of
macros that map to a core language, which is syntactically simple (not
as simple as Lisp but close, I'd say). So if you pretend to be
programming in a language with a set of predefined macros, that uses
indentation instead of parentheses, you might find Haskell acceptable.
Then again, you might not ;-)
Regards,
Jo
Bill Birch
I have tried Tabs with this syntax, I find them truly evil.
No two representations (especially browsers, printers or editors) can
agree.
So Lispin gives a syntax error if it finds any tabs.
Philippa Cowderoy
> Alex Mizrahi schrieb:
> > also, there would be less problems with different habbits -- some people
> > prefer 8-space tabs, other prefer 2-space tabs, and if code contains only
> > tabs, they will get what they want, since conversion will be done only for
> > visualization.
>
> I agree with that. Tabs do have advantages in this respect.
>
However, they're a dead loss for some styles - for a haskell-based
example, while I tend to write cases with a simple indent after the
discriminant like so:
case foo of
Bar -> baz
I write do blocks like so:
do this
result <- that
other
return result
and let statements thusly:
let foo = bar
baz = quux
in wibble
(note that the single space there is intended to associate the in with the
let while being sufficiently dedented)
Similarly, I end up writing multi-line lists and tupled like this:
[foo,
bar,
baz]
or if there's enough nesting to warrant it, like this:
(foo,
bar,
baz
)
And n-ary function applications that won't fit in one line like this:
func foo
bar
baz
If surrounding parens're required, the same approach as for lists and
tuples applies.
I find significant amounts of white space cause a mental pause in my
reading, which is great for separating definitions at top-level but rather
disconcerting when it occurs horizontally in the middle of a function.
Performance anxiety leads to premature optimisation
Alex Mizrahi
(you :wrote :on '(Wed, 29 Nov 2006 14:15:15 +0000))
(
PC> I find significant amounts of white space cause a mental pause in my
PC> reading, which is great for separating definitions at top-level but
PC> rather disconcerting when it occurs horizontally in the middle of a
PC> function.
i think that specialized editor will help you more than some conventions --
if the conventions will be handled by the editor, you'll have less mental
pauses anyway.
goo...@gingerbread.plus.com
> Yes. Just read more cll :-)
>
> http://groups.google.com/group/comp.lang.lisp/msg/3050088218d355e5
This is not directed at you, Pascal, but your comment in that post,
"There's no parenthesis in lisp. Parentheses are but editor commands,
to move along the syntactic tree.", is in stark contrast to posts 2-16
in this thread.
It may be that it is possible to write Lisp without parentheses; it may
be that CodeIsData and DataIsCode; it may be that macros can be used to
transform Lisp into any Little Language that you like, but when
somebody like Bill dares to suggest that they would actually like to do
such a thing, they are opened to ridicule and derision.
That's what's so great about Lisp and Scheme, you see: the friendly
community. /sarcasm
Alex Mizrahi
(you :wrote :on '(29 Nov 2006 07:12:58 -0800))
(
g> That's what's so great about Lisp and Scheme, you see: the friendly
g> community. /sarcasm
the friendly community prevents Bill from doing stupid things, spending his
time on a bullshit. if he wants a better readability, he'd better write an
editor.
Philippa Cowderoy
> i think that specialized editor will help you more than some conventions --
> if the conventions will be handled by the editor, you'll have less mental
> pauses anyway.
>
Sure. Got one spare?
Society does not owe people jobs.
Society owes it to itself to find people jobs.
Alex Mizrahi
(you :wrote :on '(Wed, 29 Nov 2006 16:20:15 +0000))
(
??>> i think that specialized editor will help you more than some
??>> conventions -- if the conventions will be handled by the editor,
??>> you'll have less mental pauses anyway.
PC> Sure. Got one spare?
no, and i don't see anybody doing it :(, even Bill Birch ain't interested..
if i was younger, i'd start it immidiately -- i was making 3D user interface
stuff [1], like 3D file manager, 3D calc; thus an editor with some very
custom look and feel (i don't think that modification of something
traditional -- like emacs or eclipse -- would do a thing) would be very
interesting. but now i'm not much older, but not as fast to make that kind
of things :).
[1] http://indirect3d.sourceforge.net/
Fred Gilham
goo...@gingerbread.plus.com writes:
>
> This is not directed at you, Pascal, but your comment in that post,
> "There's no parenthesis in lisp. Parentheses are but editor commands,
> to move along the syntactic tree.", is in stark contrast to posts 2-16
> in this thread.
>
> It may be that it is possible to write Lisp without parentheses; it may
> be that CodeIsData and DataIsCode; it may be that macros can be used to
> transform Lisp into any Little Language that you like, but when
> somebody like Bill dares to suggest that they would actually like to do
> such a thing, they are opened to ridicule and derision.
>
> That's what's so great about Lisp and Scheme, you see: the friendly
> community. /sarcasm
>
But parentheses are beautiful editor commands, soft, rounded, not at
all jagged (like XML) or squiggly (like C or other languages) or
lurking invisibly waiting to trap you.
They gently massage your code into smoothly meandering shapes
reminiscent of streams flowing through high-country meadows. They
calmly disambiguate even the most complex mathematical expressions.
They humbly point away from themselves, toiling in nameless obscurity,
emphasizing the code and data that they structure and support so
nobly.
Yes, they seem intimidating at first, like a lovely woman. But when
you get to know her, I mean them, their sweet, gentle nature becomes
manifest, and they become your fast friends and constant helps in time
of need.
Do away with parentheses? Do away with high-school sweethearts, with
the girl next door, with your dear long-suffering mother.
--
Fred Gilham gil...@csl.sri.com
I can see you're going to do just *fine* here in comp.lang.lisp. I'm
rather looking forward to the ritual disembowelling, in particular,
although the bit where we chop your arms and legs off and feed them to
crocodiles is also good. --- Tim Bradshaw
Robert Maas, see http://tinyurl.com/uh3t
> I am wondering what a simple program looks like in a tree. Could
> you show one?
Don't you have any imagination? If you read any Lisp tutorial,
showing the linked-pairs internal representation of nested lists,
and also showing how the first element of each list is usually a
tag saying what to do with that sub-tree (call a function, run a
special operator to process the data in some other way), it should
be obvious how the tree would be constructed, and then you can
imagine how it might be presented. For example, there's a way on
Windows and Linux for displaying files in a hierarchy of directories
in a tree format. You could use that format for Lisp source.
A similar format is used for cladograms. Something like this:
defun
|--fact
|--<parameterList>
| `--N
`--if
|-->
| |--N
| |--1
|--*
| |--N
| `--fact
| `--+ (the "+" is bold so you can distinguish it from the --line)
| |---1 (the "-1" is bold so you can distinguish it from the --line)
| `--N
`--1
As with the Windows/Linux directory browser, you should be able to
collapse any sub-tree to a single stub, and expand any stub back
out to a sub-tree (with inner stubs kept stubbed as before).
One bonus of using cladogram notation, with back-apostrophe on last
branch, is that you can see whether there's any more branching
after the last line visible in the window (if you see |--) or not
(if you see `--), so you don't have to waste time scrolling just to
get that info.
One feature the editor should have, which isn't in the directory
browser, is to detach sub-trees and stand them alone, then move
them back into the main tree later. Of course you could pull a
sub-expression out of one function definition and later move it
into some *other* function definition. IMO, the pain of making
changes to a program would be awful without that feature.
A single-stepper could traverse that visual representation, putting
results of evaluation alongside the relevant sub-tree. If such
returned value is itself a tree, it could likewise be
expanded/stubbed as needed to inspect it visually.
Lars Rune Nøstdal
> Pascal Bourguignon wrote:
>> Yes. Just read more cll :-)
>>
>> http://groups.google.com/group/comp.lang.lisp/msg/3050088218d355e5
>
> This is not directed at you, Pascal, but your comment in that post,
> "There's no parenthesis in lisp. Parentheses are but editor commands,
> to move along the syntactic tree.", is in stark contrast to posts 2-16
> in this thread.
>
> It may be that it is possible to write Lisp without parentheses; it may
> be that CodeIsData and DataIsCode; it may be that macros can be used to
> transform Lisp into any Little Language that you like, but when
> somebody like Bill dares to suggest that they would actually like to do
> such a thing, they are opened to ridicule and derision.
Maybe it's something like this. I like sawing:
http://www.cartoonstock.com/lowres/phr0034l.jpg
Unfortunately I fall down and the branch breaks both my arms; now I cannot
saw. If sawing isn't ridiculus, then what is? .. heh :}
..just ramblin' here..
--
Lars Rune Nøstdal
http://nostdal.org/
goo...@gingerbread.plus.com
Ah, but the *brace* is the ogee, admired in the Arabesque, Gothic and
Art Nouveau; the shape of a champagne goblet; the symbol that denotes
music. You are missing out on the Lycee, the Conservatoire and the
Moulin Rouge, on the Seraglio and the Cathedral.
But I have three replies and they all ignore the point I was making.
Here are two schools of thought: one that says that, because the parse
trees being represented are the same, it is still Lisp; one that says
that it is only Lisp if the true representation is in S-Expressions.
This is old hat (decades old). The main difference between the camps is
nothing to do with parentheses, however, but in their ability to be
polite (and not condescending).
John Thingstad
In a world that embraces XSL and XSLT why do Lisp parens seem bad?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Mallor
Robert Maas, see http://tinyurl.com/uh3t wrote:
> > From: "Neo" <neo55...@hotmail.com>
> > I am wondering what a simple program looks like in a tree. Could
> > you show one?
>
> Don't you have any imagination?
No, none.
>, it should be obvious
Any time you use the word "obvious," you should become very, very
concerned about what you're taking for granted.
Cheers,
Brandon Van Every
Mallor
>
> as i understand, the goal is to improve readability.
> without the editor support, this things have very few sense.
>
> but if you'll implement this in the editor, ti won't be a syntax -- but
> merely a form of visualization. the editor will be able to remove
> parentheses during process of visualization, and will bring them back when
> it will render file for compiler.
>
> thus, if you really want to do something, try to implement next-generation
> code editor -- that will not be a text editor with some processing attached,
> but yet special thing, that will understand the semantics of code you're
> editing, and will visualize it in proper way, and will allow you to edit it
> in proper way -- thus, it would be impossible to have malformed indentation.
And you will have tied your project to the sucess / failure of 1
particular editor, until other people get around to writing more such
editors. Which, as you can see, nobody is doing even for Common Lisp.
Because it's a lot of work. Saying, "You should do tons more work to
address the problem, than you really need to do to get started," makes
no sense. Not in the real world at any rate. There are all sorts of
things we'd like to have in theory, but there's this bugaboo called
productivity.
I wonder whether Lisp syntax is actually a problem to anybody though.
People *say* it's a problem, but what really stops Lisp from competing
in the mainstream, with the likes of C / C++ / Java / C# ? I'm more
inclined to point the finger at absence of killer apps, lack of
standardized FFIs for code migration, and lack of a $$$$$$$$ corporate
backer. Keep your eyes peeled for how Python does with Google.
The reality may be that Lisp is just a language, most coding problems
don't require customized languages, and the Big Win was garbage
collection.
Cheers,
Brandon Van Every
fredas...@yahoo.com
ONE OF HIS POSTS
1. He has never designed any game, nor contributed to the design of
any game, which has ever seen the light of day, despite referring
to himself as a "game designer." (In rebuttal, he pointed out his
"one complete game" from "1983" on the "Atari 800" which he showed
to his "8th grade math teacher.")
2. He has never been employed in the game industry, in any way,
shape, manner or form. Despite this, for some reason he managed
to get named as an Independent Games Festival judge; a curious
turn of events, since their stated intent is to appoint
"professionals in the game industry" (their quote, not his).
3. In fact, the only programming job he had listed on his resume was
for only "2 years" ending in "1998," working in C and assembly on
a graphics driver, as a "Sr. Software Engineer" -- a curious
title, since this was his first (and only) job in the software
industry. There is no evidence he has used C++, nor any other
language, professionally. (And the company in question is
defunct, anyway, so there is no way to verify his claim.)
4. The other jobs he has mentioned having after this one and only
item on his resume are: "yard maintenance work," "painting
apartments," "scrubbing floors," "sub minimum wage signature
gathering," and working for "$5/hour at a Vietnamese restaurant."
5. The only personal project he actually wrote code for and released
in some fashion was Free3d, a software 3D rendering engine.
Stating that its goals were to be "100% efficient, 100% portable"
and to release it in a "one year time frame," he started in "1993"
and abandoned it in "1996," admitting that it "barely drew even a
single polygon" and "did hardly anything in the 3D department."
6. Almost every Internet community (Usenet newsgroup, mailing list,
etc.) he has ever introduced himself to has resulted in him
repeating the same pattern: asking leading questions, demanding
people do things his way, becoming hostile, annoying the other
participants, alienating them, and finally leaving in disgust.
7. The project he has intermittently claimed to be working on, Ocean
Mars, is vaporware -- and is one of his admitted "failures." He
allegedly sunk "1.5 man years" and about "$60K" into it with only
a "spherical hexified icosahedron" display to show for it, and has
stated that he's "unlikely to use any of it." Ultimately he filed
for a "Chapter 7" "bankruptcy of $82K," since he was "completely
destitute" and "had no earning power to ever pay the money back."
8. Since his embarassing frustration with his Ocean Mars project, he
has decided that C and C++ aren't "worth anything as a resume
skill anymore," and embarked on a quest in 2003 to find a
high-level language that will suit his needs. After more than a
year, at least ten languages, and not having even "written a line
of code" in any of them, he still has yet to find a language that
will suit him.
9. Finally, despite vehemently insisting that he is not a troll, many
people quite understandingly have great difficulty distinguishing
his public behavior from that of a troll.
Joachim Durchholz
> I wonder whether Lisp syntax is actually a problem to anybody though.
> People *say* it's a problem, but what really stops Lisp from competing
> in the mainstream, with the likes of C / C++ / Java / C# ?
Simple. The syntax isn't attractive for newcomers.
In other words, while I'll take your word that parentheses aren't a
problem in practice, people who haven't tried that will think they are.
> I'm more inclined to point the finger at absence of killer apps,
Actually that's irrelevant. Python thrives despite the absence of a
killer app.
> lack of standardized FFIs for code migration,
That's a serious problem, yes.
> and lack of a $$$$$$$$ corporate backer.
Corporate backing is a plus, but neither required (Perl doesn't have it)
nor sufficient (Microsoft has been pushing Basic with little success).
> The reality may be that Lisp is just a language, most coding problems
> don't require customized languages, and the Big Win was garbage
> collection.
There's more to that.
One of Lisp's strengths was and still is higher-order functions: that's
an abstraction facilities that few mainstream languages can match.
Together with reasonable efficiency, this used to be a USP for several
decades, but other languages with HOFs have been available, too, and
they at least caught up efficiency-wise in the last decade or two, so
Lisp lost that USP.
Lisp's other strength is the ability to write macros at the drop of a
hat. Personally, I'm actually sceptical that this is really a strength -
it's certainly a powerful mechanism, but it gives little guarantees (any
code might do anything, since macros could change almost every aspect of
the semantics of a piece of code).
So, my personal prediction is that Lisp will be superseded by some
future Haskell dialect... but that's just me, and predictions are
usually wrong anyway :)
Regards,
Jo
Jamesl
I applaud your drive to produce something new for the community and to
put it out there.
Offering new perspectives, features or anything that could make it
easier for people to
become LISP users is good for the community. I wish more people used
LISP and have
often wondered how to get people interested.
Maybe LISP without parentheses could do it.
Well done. I have bookmarked the site and will visit regularly to see
the progress.
I hope it becomes all you hope it to be.
Rgs, James.
ito...@gmail.com
> The Lispin project web site has been launched.
>
> The project's goal is to provide Lisp and Scheme languages with an
> indented syntax similar to SRFI 49 and
> other poposals. e.g.
>
> define (fac x)
> fac (- x 1
>
> and on-line indentation pre-processor. The site itself is implemented
> in an indented Lisp.
>
TwinLisp is a language with C/Java - like syntax, but with internals
and abilities of a Common Lisp (it is a twin of a lisp internally).
TwinLisp is implemented as a translator from its own syntax to lisp
code, which can be executed by any CL implementation.
You can download it from here: http://twinlisp.nongnu.org/download.html
Ken Tilton
Dear General Custer,
I applaud your drive. I regret I will be unable to join you today (our
regiment is washing our horses), but I have asked my aides to provide
regular summaries of your dispatches from the front.
All the best,
James
ps. "Little Big Horn"? Is that a typo? j
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Paul Rubin
> TwinLisp is a language with C/Java - like syntax, but with internals
> and abilities of a Common Lisp (it is a twin of a lisp internally).
> TwinLisp is implemented as a translator from its own syntax to lisp
> code, which can be executed by any CL implementation.
Sounds like Dylan?
Ken Tilton
ROFL. I can hear it now, this growing crescendo, sounds like dylan,
sounds like ruby, sounds like groovy, sounds like python, faster and
faster, louder and louder, the circle tightens, the falcon hears the
falconer... sounds like... sounds like... BAM! supernova! sounds like...
[left as an exercise].
kzo
Alex Mizrahi
(you :wrote :on '(1 Dec 2006 17:27:10 -0800))
(
M> And you will have tied your project to the sucess / failure of 1
M> particular editor, until other people get around to writing more such
M> editors.
who will be tied?
the editor will produce a valid lisp code, so it can be abandonned at any
time -- switched to Emacs or whatever.
M> Which, as you can see, nobody is doing even for Common Lisp. Because
M> it's a lot of work.
i won't estimate it as a lot of work -- someone having right tools and
knowing them will produce a prototype in a week, and somewhat useable
version in a month or so. certainly it won't be as featureful as Emacs, but
i'm anyway using some 0.1% of Emacs features..
personally, i think that if switching from pure text editor, it should be
totally new look&feel, but not some variation of an old theme. e.g. totally
graphical rendering using OpenGL, animation, zoom.. i'm not sure if 3d trees
are applicable, but who knows :).
this field is very interesting to me -- i'm interested both in 'better
editor', and in revolutional look&feel (i've done some 3d user interface
stuff, including 3d file manager) -- so i could make it in that way, but i
have more high-priority tasks now. but if someone is willing to sponsor
creation of a prototype, i could start right now :)
M> I wonder whether Lisp syntax is actually a problem to anybody though.
well, no.
but it doesn't mean things should not be improved.
Lisp currently is not such a big winner -- currently there are programming
languages having GC and high-order function, so it's no more a great
advantage. the only real advantage is the Syntax that enables Right Macros.
a neat editor might add it a popularity points -- at first sight, it will
look very modern and cool, so people thinking that Lisp is something ancient
will not think so. than, it can provide more effective learning for newbies.
more deeply, there is an Intentional Programming thing. it actually means
something like programming languages deeply integrated with IDEs [1]. so new
editor could enable this Intentional Programming thing. without it, once
Microsoft implement it in their Visual Studio, chances of lisp becoming
popular will decrease even more. (i suspect that Lisp is a best host for
Intentional Programming thing).
i can also point you to the efforts to make non-text editor for Visual
Studio: http://www.officialsourceexplorer.com/about.aspx
this thingie represents code (C#, XML, SQL) as trees and allow easier
refactoring.
so, Visual Studio guys are improving their editors, why Lisp guys
shouldn't? :)
M> The reality may be that Lisp is just a language, most coding problems
M> don't require customized languages, and the Big Win was garbage
M> collection.
it's up to you to think so, but why people are now doing data queries in SQL
and do output with HTML, struggling with strings (oh, how many security
holes are SQL-injections, that are merely because of semantic is trimmed
when value is coerced to string, thus you cannot distinguish datatypes)?
with Lisp, i was able to create a wrapper for SPARQL (RDF) queries, where i
can do queries just like i do usual variable bindings, and wrappers
automatically convert types. then i can embed values being fetched directly
into HTML using LML2, so all code is in s-expressions:
(rdf:do-query
((?user :name ?uname)
(?uname :first-name ?fname)
(?uname :last-name ?lname)
(?user :salary ?salary))
(html (:tr
(:td (:princ ?fname))
(:td (:princ ?lname))
(:td (:princ ?salary)))))
what other language can do that, and how much longer and error-prone would
it be?
OTOH, afaiu Microsoft is going to add 'macros' to their editor to cover
usual needs, and boring programming job does not require custom macros..
[1] http://en.wikipedia.org/wiki/Intentional_programming
In computer programming, intentional programming is a collection of
concepts which enable software source code to reflect the precise
information, called intention, which programmers had in mind when conceiving
their work. By closely matching the level of abstraction at which the
programmer was thinking, browsing and maintaining computer programs becomes
easier.
Alex Mizrahi
(you :wrote :to '(Mallor) :on '(Sun, 3 Dec 2006 12:53:00 +0200))
(
AM> it's up to you to think so, but why people are now doing data queries
AM> in SQL and do output with HTML, struggling with strings (oh, how many
AM> security holes are SQL-injections, that are merely because of semantic
AM> is trimmed when value is coerced to string, thus you cannot distinguish
AM> datatypes)?
and btw i can show an example of 'web-framework' that appears to be
absolutely the best for prototyping:
(defun factorial-page ()
(make-page "factorial"
(:body
(:h1 "factorial")
(:p (action-form
(((:input :name "number"))
(form-submit "calculate"))
(with-form-fields
((number integer))
(make-page "factorial-results"
(:body
(:h1 "factorial results")
(:p "factorial of " (:princ number) "is" (:princ
(factorial number))
(action-link "calculate another"
(factorial-page)))))))))))))))
well, it's not a best example, but it shows that this 'framework' collects
everything together -- presentation (HTML code/template), the web form and
code that handles that form, so factorial-calculator can be done as a single
defun. i bet no other language can provide that!
and with prev. example, i can do RDF query, format it's results, create
controlling form and code that handles form action in just a single
s-expression!
Pascal Costanza
> Mallor schrieb:
>> I wonder whether Lisp syntax is actually a problem to anybody though.
>> People *say* it's a problem, but what really stops Lisp from competing
>> in the mainstream, with the likes of C / C++ / Java / C# ?
>
> Simple. The syntax isn't attractive for newcomers.
> In other words, while I'll take your word that parentheses aren't a
> problem in practice, people who haven't tried that will think they are.
It seems that this depends a lot on how new the newcomers really are. I
have heard quite a few times that newcomers who have never seen any
programming language, and thus don't have any preconceptions, have a
much easier time to get used to Lisp syntax. Only those who have already
seen language with more accidental syntax seem to have caught the meme
that syntax somehow matters...
> One of Lisp's strengths was and still is higher-order functions: that's
> an abstraction facilities that few mainstream languages can match.
> Together with reasonable efficiency, this used to be a USP for several
> decades, but other languages with HOFs have been available, too, and
> they at least caught up efficiency-wise in the last decade or two, so
> Lisp lost that USP.
This is actually incorrect. For most of Lisp's history, Lisp dialects
didn't get higher-order functions right, due to a lack of support for
proper lexical closures. Only Scheme and Common Lisp got this really
right for the first time, followed by other subsequent Lisp dialects.
No, Lisp's major strength still are its facilities for metaprogramming
at various levels. (Higher-order functions can be understood as a subset
of metaprogramming, so it's no surprise that Lisp had this strength as
one of the first languages.) Lisp syntax plays a crucial role in this
regard.
> Lisp's other strength is the ability to write macros at the drop of a
> hat. Personally, I'm actually sceptical that this is really a strength -
> it's certainly a powerful mechanism, but it gives little guarantees (any
> code might do anything, since macros could change almost every aspect of
> the semantics of a piece of code).
This statement is too easy to misunderstand because it gives the
impression that macros allow you to really change arbitrary parts of a
system - and that's an impression about Lisp that uninformed readers
might indeed get. However, the effect of a macro invocation is always
restricted to the enclosed code and cannot touch other parts of a
system. That's an important (and useful) restriction. (I am not saying
that you said otherwise.)
I don't see why there is a serious problem here, though. The only
guarantee a function gives you is that its arguments are evaluated (and
in languages with lazy evaluation even that's not the case). Apart from
that, they can also do whatever they want. So I don't see how macros are
any more dangerous than functions here.
I guess you have the stronger restrictions in mind that strong static
typing and lack of side effects imply - but that's unrelated and in fact
orthogonal to whether you have macros in a language or not.
> So, my personal prediction is that Lisp will be superseded by some
> future Haskell dialect... but that's just me, and predictions are
> usually wrong anyway :)
It is true that Lisp gives you in general a lot more freedom than other
languages do, including the freedom to shoot yourself in the foot. For
someone who wants to experiment with new ideas, try out new programming
styles and explore domains that are not well understood, this kind of
freedom is invaluable. The fact that you don't have to fight the,
sometimes implicit, assumptions inherent in the restrictions placed on
programmers in other languages can be a great time saver and enabler.
Whether Lisp is going to survive in the very long run or not is hard to
predict, as is the case for any language. However, it's probably the
case that there will be people who will want to use languages with many
degrees of freedom.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Joachim Durchholz
> I don't see why there is a serious problem here, though. The only
> guarantee a function gives you is that its arguments are evaluated (and
> in languages with lazy evaluation even that's not the case).
Macros can interact with their arguments in ways that functions cannot
(otherwise there wouldn't be macros).
This makes it more difficult to understand the semantics of a macro.
> Apart from
> that, they can also do whatever they want. So I don't see how macros are
> any more dangerous than functions here.
>
> I guess you have the stronger restrictions in mind that strong static
> typing and lack of side effects imply - but that's unrelated and in fact
> orthogonal to whether you have macros in a language or not.
Agreed.
Actually lack of static typing and purity guarantees are what deter me most.
The second problem is lack of technical integration with the external
world. Lack of a standardized FFI support was just mentioned; that's a
serious barrier when one wants to work with OS facilities or standard
libraries.
The third problem is that Lisp is a separate world, tool-wise. Lisp
comes with its own set of tools, which may be great but have their own
ergonomic paradigms, with their own mindset (and, of course, vice versa:
non-Lisp tools usually won't work well for Lisp work). Great if all you
ever do is Lisp, but horrible if you have to switch between worlds. (I
think parentheses are just the most visible aspect of this.)
> It is true that Lisp gives you in general a lot more freedom than other
> languages do, including the freedom to shoot yourself in the foot. For
> someone who wants to experiment with new ideas, try out new programming
> styles and explore domains that are not well understood, this kind of
> freedom is invaluable. The fact that you don't have to fight the,
> sometimes implicit, assumptions inherent in the restrictions placed on
> programmers in other languages can be a great time saver and enabler.
Well, I already got my share of flamage for stating that Lisp is best
used as a language mechanism testbed and not so good for other things,
so I'll leave it at that ;-)
However, current FPLs have been starting incursions on that territory,
too. Parser combinators seem to have made it easy to set up a toy
language, and I see it done at the drop of a hat.
I think Lisp has serious competition even in that area.
Regards,
Jo
Joachim Durchholz
> more deeply, there is an Intentional Programming thing. it actually means
> something like programming languages deeply integrated with IDEs [1].
This interpretation of IP is just Microsoft's attempt at tying
programmers into a proprietary binary format and IDE.
Integrating programming with an IDE also creates just the problems that
Lisp and Smalltalk have: difficulties when interoperating with languages
that don't use the same IDE.
I think that's a dead end.
Regards,
Jo
Pascal Costanza
> Pascal Costanza schrieb:
>> I don't see why there is a serious problem here, though. The only
>> guarantee a function gives you is that its arguments are evaluated
>> (and in languages with lazy evaluation even that's not the case).
>
> Macros can interact with their arguments in ways that functions cannot
> (otherwise there wouldn't be macros).
> This makes it more difficult to understand the semantics of a macro.
Maybe. But this is again not a principle issue of macro systems, just a
potential issue with how macro systems work in many Lisp dialects. There
are more "controlled" (and thus less powerful) macro systems available
for Scheme and Dylan, for example.
>> It is true that Lisp gives you in general a lot more freedom than
>> other languages do, including the freedom to shoot yourself in the
>> foot. For someone who wants to experiment with new ideas, try out new
>> programming styles and explore domains that are not well understood,
>> this kind of freedom is invaluable. The fact that you don't have to
>> fight the, sometimes implicit, assumptions inherent in the
>> restrictions placed on programmers in other languages can be a great
>> time saver and enabler.
>
> Well, I already got my share of flamage for stating that Lisp is best
> used as a language mechanism testbed and not so good for other things,
> so I'll leave it at that ;-)
;)
> However, current FPLs have been starting incursions on that territory,
> too. Parser combinators seem to have made it easy to set up a toy
> language, and I see it done at the drop of a hat.
> I think Lisp has serious competition even in that area.
I think you are comparing apples and oranges here. First, parser
combinators allow you to solve a problem (i.e. parsing) that Lispers
simply avoid in the first place by relying on the generality of
s-expressions. The more interesting aspect of "toy languages" (embedded
languages, domain-specific languages, whatever you want to call them) is
the specification of their semantics. Parsing is only interesting if you
consider syntax interesting.
Second, the exploration of unknown domains is not only a matter of being
able to express domain-specific languages. It's also a matter of already
having quite a number of language constructs at hand that you can use as
building blocks, without an imposed judgment of which constructs are
"good" or "bad" for whatever reasons, plus good support for interactive
development which especially includes the ability to change definitions
on the fly without the need to interrupt your preferred style of
working. This includes, for example, the ability to change and/or fix
definitions while a program using them is running.
Alex Mizrahi
(you :wrote :on '(Sun, 03 Dec 2006 13:53:24 +0100))
(
JD> This interpretation of IP is just Microsoft's attempt at tying
JD> programmers into a proprietary binary format and IDE.
IP is not a Microsoft initiative. Microsoft silently improves their IDEs
without calling that IP.
and as for binary format, i think they can dump everything into XML (lol).
JD> Integrating programming with an IDE also creates just the problems that
JD> Lisp and Smalltalk have: difficulties when interoperating with
languages
JD> that don't use the same IDE.
but all new things create "some problems"!
they are not insolvable: if IP would be done on top of .NET, there is a ECMA
standard for intermediate language.
i've once made a compiler from lisp-like-syntax language into ILasm in some
5-6 hours. so i think there's no much problem with this.
Gabriel Dos Reis
[...]
| > lack of standardized FFIs for code migration,
|
| That's a serious problem, yes.
Indeed.
| > and lack of a $$$$$$$$ corporate backer.
|
| Corporate backing is a plus, but neither required (Perl doesn't have
| it) nor sufficient (Microsoft has been pushing Basic with little
| success).
C++ did not have a marketing department.
|
| > The reality may be that Lisp is just a language, most coding problems
| > don't require customized languages, and the Big Win was garbage
| > collection.
|
| There's more to that.
| One of Lisp's strengths was and still is higher-order functions:
| that's an abstraction facilities that few mainstream languages can
| match. Together with reasonable efficiency, this used to be a USP for
| several decades, but other languages with HOFs have been available,
| too, and they at least caught up efficiency-wise in the last decade or
| two, so Lisp lost that USP.
Lisp's main strengh is its syntax that permit equivalence of data and
function.
| Lisp's other strength is the ability to write macros at the drop of a
| hat. Personally, I'm actually sceptical that this is really a strength
| -
| it's certainly a powerful mechanism, but it gives little guarantees
| (any code might do anything, since macros could change almost every
| aspect of the semantics of a piece of code).
| So, my personal prediction is that Lisp will be superseded by some
| future Haskell dialect... but that's just me, and predictions are
| usually wrong anyway :)
Well, the Axiom computer algebra system
http://www.axiom-developer.org/
(started at the beginning of the 70') uses Lisp as its underlying
platform. A large part of it is written in dialects of Lisp -- there
were many of them, all sharing the name Boot. Boot is a
parenthesis-less syntactic sugar over Lisp, with many things in common
with core Haskell (before Haskell was invented). Because of the tortuous
path of the project, Axiom did not grow as fast as one would like.
SPAD, the programming language used to implement Axiom libraries, can
be seen as a typed version of Boot. It has "categories", "domains", and
"packages" that give you type classes (and modules) -- before type
classes where invented. More information is available on the Axiom website.
-- Gaby
Gabriel Dos Reis
[...]
| Actually lack of static typing and purity guarantees are what deter me most.
| The second problem is lack of technical integration with the external
| world. Lack of a standardized FFI support was just mentioned; that's a
| serious barrier when one wants to work with OS facilities or standard
| libraries.
I fully agree. Having been working recently on the 30 years old Axiom
computer algebra system, I find that the lack of standardized FFI is a
real problem for porting from systems to systems, and across Lisp
implementations.
| The third problem is that Lisp is a separate world, tool-wise.
Or many Lispers would like to make it so. But, I don't see the real
payoff of building a ghetto around Lisp.
| Lisp
| comes with its own set of tools, which may be great but have their own
| ergonomic paradigms, with their own mindset (and, of course, vice
| versa: non-Lisp tools usually won't work well for Lisp work). Great if
| all you ever do is Lisp, but horrible if you have to switch between
| worlds.
Indeed.
| (I think parentheses are just the most visible aspect of this.)
In fact, I'm not bothered much by the parenthesis, though I
recognize that they can be visual distraction. As I said, in Axiom we
use mostly Boot which is a parenthesis-less syntactic sugar over
Lisp. It uses layout -- called pile -- (just like Python or Haskell)
for block of expressions.
[...]
| However, current FPLs have been starting incursions on that territory,
| too. Parser combinators seem to have made it easy to set up a toy
| language, and I see it done at the drop of a hat.
| I think Lisp has serious competition even in that area.
I can't find a reliable source on the invention of parser combinators
but, but Boot used them long before the mid 90s that googling would
report. I would appreciate a reference that goes before 90'.
-- Gaby
Rainer Joswig
<g...@integrable-solutions.net> in
m38xhp8...@zeus.integrable-solutions.net:
> Joachim Durchholz <j...@durchholz.org> writes:
>
> [...]
>
> | Actually lack of static typing and purity guarantees are what deter me most.
> | The second problem is lack of technical integration with the external
> | world. Lack of a standardized FFI support was just mentioned; that's a
> | serious barrier when one wants to work with OS facilities or standard
> | libraries.
>
> I fully agree. Having been working recently on the 30 years old Axiom
> computer algebra system, I find that the lack of standardized FFI is a
> real problem for porting from systems to systems, and across Lisp
> implementations.
>
> | The third problem is that Lisp is a separate world, tool-wise.
>
> Or many Lispers would like to make it so. But, I don't see the real
> payoff of building a ghetto around Lisp.
Lisp has a specific world view which makes it less compatible with the
current outside world.
Let me list a few.
* Lisp usually needs garbage collection. There are almost no standards
for garbage collection systems.
* Lisp programs often have a high cons-rate. Thus Lisp usually needs
a very efficient garbage collector to be competitive.
* Lisp has the idea of high dynamisn in the runtime. You can redefine
a function and user code will immediately use the new one. You
can change a class and existing objects will be changed. You
can change an object from one class to another. All this
induces additional redirections.
* Lisp in its standard data types does not care that much about data layout.
This can be inefficient. Various Lisp dialects have special
purpose data structures.
* Lisp has typed objects with identity. Objects carry around their
types (often using low-level tags). This again makes Lisp objects
in their data layout incompatible with most other systems.
* Lisp prefers heap consistency. Usual operations should not
corrupt the heap in the presence of dynamic typing.
This makes it necessary to check operations
before they are applied to objects. Untagged objects are
cannot be checked without knowing their types from somewhere else.
* In the presence of large virtual memory systems, you immediately
need special infrastructure to reduce paging when you deal
with a pointer chasing language like Lisp applied to a
application domain with GBs of memory.
* Lisp has a different surface syntax.
* Support for Functional Programming (Closures, ...) and Object-oriented
Programming is still unusual in the operating systems we use.
Standards are rare (CORBA, .net, ...) and limited.
* CLOS supports meta-level programming, multi-dispatch,
extension of classes, little data hiding - making it mostly
incompatible even in the basic paradigm with most
Object-oriented Languages which are mostly following
some kind of message-sending paradigm.
* No current OS uses Lisp's infrastructure as a model
of organizing memory and/or data. There is no support from
other communities for the Lisp infrastructure.
(Exceptions are systems like Maxima, ...).
* There is little culture of static checks on the code level
(by the compiler etc, ...). So you need to load software into
a Lisp to inspect it or check it.
There is more to mention, but this should be sufficient to list.
The consequences are:
* most OS-level development tools cannot easily or usefully applied
to Lisp code.
* the Lisp ideas about data layout are completely incompatible with OS-level
ideas of data-layout. Lisp has its own ideas about data
and thus needs to implement its own memory and data management.
Almost none of the existing systems bought into that
and tried to use Lisp's infrastructure.
* if Lisp wants to talk to the OS, it needs to use the OS datastructures
or convert those into its own datastructures.
Lisp is not on its own with these 'problems'. Smalltalk, Prolog, Java, ...
also have similar 'problems'.
The combination of these things automatically makes Lisp a very
different infrastructure on any currently used system.
In the 'Lisp World' one should follow a few rules to be successful
with software design:
* the best chance to survive have extensions that follow the spirit
of Lisp (syntax, semantics, ...)
* See the basic Lisp as some kind of abstract machine and build on top.
* when in doubt design software to be dynamic (changeable at any time).
* when in doubt design software to be introspective
* when in doubt design software to be reflective
These rules are very different from what you see in many other software
systems. There, for example, the compiler
will compile it to static, non-reflective, non-evolvable machine code.
It is true that this different nature makes Lisp automatically
a second class citizen on any current OS. But since Lisp is
sufficiently different, its feature set also guarantees its
survival. There are few comparable Languages/systems in
the same niche (with some overlap from Smalltalk and Prolog).
Gabriel Dos Reis
[...]
| > | The third problem is that Lisp is a separate world, tool-wise.
| >
| > Or many Lispers would like to make it so. But, I don't see the real
| > payoff of building a ghetto around Lisp.
|
| Lisp has a specific world view which makes it less compatible with the
| current outside world.
|
| Let me list a few.
|
| * Lisp usually needs garbage collection. There are almost no standards
| for garbage collection systems.
indeed, there is no standard for garbage collection systems, but Lisp is
not the only language using garbage collection.
| * Lisp programs often have a high cons-rate. Thus Lisp usually needs
| a very efficient garbage collector to be competitive.
Lisp is not alone in that respect.
| * Lisp has the idea of high dynamisn in the runtime. You can redefine
| a function and user code will immediately use the new one.
Again, lisp is not alone in that respect.
[...]
| * Lisp in its standard data types does not care that much about data layout.
| This can be inefficient.
I don't see how this implies the needs for a ghetto.
| * Lisp has typed objects with identity. Objects carry around their
| types (often using low-level tags).
Lisp is not alone in that respect.
| * Lisp prefers heap consistency.
That is the theory -- I said theory because in practice I see
something else. But, again, Lisp is not alone in that respect.
[...]
| * In the presence of large virtual memory systems, you immediately
| need special infrastructure to reduce paging when you deal
| with a pointer chasing language like Lisp applied to a
| application domain with GBs of memory.
Lisp is not alone in that aspect.
| * Lisp has a different surface syntax.
*surface* syntax, yes.
| * Support for Functional Programming (Closures, ...) and Object-oriented
| Programming is still unusual in the operating systems we use.
not that unusual, most of the functional programming I use support
object orientation in one form or another abd have been ported to many
operating systems. Again, Lisp is not alone in that respect.
[... and so on...]
As I said, Or many Lispers would like to make Lisp insulated from the
rest of the world.
[...]
| Lisp is not on its own with these 'problems'. Smalltalk, Prolog, Java, ...
| also have similar 'problems'.
Ah!
-- Gaby
Pascal Costanza
It is true that for almost each and every aspect of Lisp, you can find
other languages / systems that have this aspect as well. Lisp is unique
in that it combines all these aspects. As Rainer said, Smalltalk and
Prolog are quite close, but they also don't provide everything...
Rainer Joswig
<g...@integrable-solutions.net> in
m3k619r...@zeus.integrable-solutions.net:
> Rainer Joswig <jos...@lisp.de> writes:
>
> [...]
>
> | > | The third problem is that Lisp is a separate world, tool-wise.
> | >
> | > Or many Lispers would like to make it so. But, I don't see the real
> | > payoff of building a ghetto around Lisp.
> |
> | Lisp has a specific world view which makes it less compatible with the
> | current outside world.
> |
> | Let me list a few.
> |
> | * Lisp usually needs garbage collection. There are almost no standards
> | for garbage collection systems.
>
> indeed, there is no standard for garbage collection systems, but Lisp is
> not the only language using garbage collection.
Actually there are not THAT many languages that are using similar
sophisticated garbage collectors. Many systems are using
reference counting (with some GC tacked on to it to
clean up cyclic data structures) or conservative GCs.
Those are less used in the Lisp world.
> | * Lisp programs often have a high cons-rate. Thus Lisp usually needs
> | a very efficient garbage collector to be competitive.
>
> Lisp is not alone in that respect.
Sure not, but Lisp is on the extreme side.
> | * Lisp has the idea of high dynamisn in the runtime. You can redefine
> | a function and user code will immediately use the new one.
>
> Again, lisp is not alone in that respect.
I have not argued that Lisp is alone in that respect.
>
> [...]
>
> | * Lisp in its standard data types does not care that much about data layout.
> | This can be inefficient.
>
> I don't see how this implies the needs for a ghetto.
'ghetto' is your word not mine.
OS-level data structures usually look very different.
> | * Lisp has typed objects with identity. Objects carry around their
> | types (often using low-level tags).
>
> Lisp is not alone in that respect.
I have not argued that Lisp is alone in that respect.
But C, C++ and other languages used for OS-level
development are not tagged. If they use tags,
they are mostly not compatible with Lisp systems.
> | * Lisp prefers heap consistency.
>
> That is the theory -- I said theory because in practice I see
> something else.
That's why I say 'prefer'. Most inconsistency btw.
comes from the use of foreign data structures.
> But, again, Lisp is not alone in that respect.
I have not argued that Lisp is alone in that respect.
But C definitely does not care about heap consistency.
If you want to write bits to some memory location,
there is nothing that hinders you.
>
> [...]
>
> | * In the presence of large virtual memory systems, you immediately
> | need special infrastructure to reduce paging when you deal
> | with a pointer chasing language like Lisp applied to a
> | application domain with GBs of memory.
>
> Lisp is not alone in that aspect.
I have not argued that Lisp is alone in that respect.
But with languages where you tend to allocate static
blocks with less pointer levels you don't have that
problem.
In C you allocate some bits memory and you have
you data inlined in the memory.
In Lisp if you create a CLOS object,
there is already one indirection for the CLOS
object, then you have a vector for the slots
and each slot is a pointer to some other data
structure.
> | * Lisp has a different surface syntax.
>
> *surface* syntax, yes.
Okay.
> | * Support for Functional Programming (Closures, ...) and Object-oriented
> | Programming is still unusual in the operating systems we use.
>
> not that unusual, most of the functional programming I use support
> object orientation in one form or another abd have been ported to many
> operating systems. Again, Lisp is not alone in that respect.
Read the paragraph again.
Which popular operating systems uses higher-order functional programming?
Which popular operating systems are written in an object-oriented language?
Which of them is atleast somehow similar to Lisp?
None of the most used operating systems (Linux, Windows, Mac OS X, C++, ...)
is mostly written in a dynamic language.
>
> [... and so on...]
>
> As I said, Or many Lispers would like to make Lisp insulated from the
> rest of the world.
I have argued that Lisp consists of a COMBINATION (!) of design choices
that automatically make it widely incompatible to native
OS data structures and many OS level development tools.
Lispers don't make Lisp 'insulated'. There are some design choices
in current Lisp languages & implementations and in
current operating systems that tend to make them
structurally incompatible. These design choices are not
arbitrary. Lisp is at the core a dynamic language
and this leads to a couple of these design choices.
Clearly you can design a Lisp that is not or less dynamic (Dylan,
EuLisp, Stella, ... ML, ...). But then you have something different.
You can also design a language with some Lisp features that
are mostly static (C# (has closures), F# (
http://research.microsoft.com/fsharp/fsharp.aspx ), Java, ...).
Again, Lisp's philosophy is based on a combination of several
features.
>
> [...]
>
> | Lisp is not on its own with these 'problems'. Smalltalk, Prolog, Java, ...
> | also have similar 'problems'.
>
> Ah!
What 'Ah!'? Do you see Smalltalk and Prolog widely used? Java is its
own infrastructure as well.
There are some people which would like to design a Lisp system that
is more compatible with atleast some class of systems.
* Guile. Lisp-based scripting and glue language. Not the big success as once
hoped.
* scsh. Nice, but still not widely used.
* Arc. Nothing much to see yet.
Gabriel Dos Reis
[...]
| It is true that for almost each and every aspect of Lisp, you can find
| other languages / systems that have this aspect as well. Lisp is
| unique in that it combines all these aspects. As Rainer said,
| Smalltalk and Prolog are quite close, but they also don't provide
| everything...
I'm not saying there is no reason why those choices were made. Any
combination of Rainer's enumeration (including its totality) does not seem,
to me, to justify the insulation. The insulation must come from
deeper desire, one that does not appear on the (mostly) technical
reasons he gave.
But, hey, Lisp has survived almost half a century that way, insulated
from the world; it may very well succeed being in that situation for
another half a century.
-- Gaby
Pascal Costanza
> Pascal Costanza <p...@p-cos.net> writes:
>
> [...]
>
> | It is true that for almost each and every aspect of Lisp, you can find
> | other languages / systems that have this aspect as well. Lisp is
> | unique in that it combines all these aspects. As Rainer said,
> | Smalltalk and Prolog are quite close, but they also don't provide
> | everything...
>
> I'm not saying there is no reason why those choices were made. Any
> combination of Rainer's enumeration (including its totality) does not seem,
> to me, to justify the insulation. The insulation must come from
> deeper desire, one that does not appear on the (mostly) technical
> reasons he gave.
That's speculation. I think the actual reasons are more profane. At some
stage, when the approach you choose is sufficiently different from that
of the rest of the world, it simply becomes economically more viable to
build tools from scratch than to reuse existing ones, because the
integration of the existing tools is more complex than building the new
ones. Or at least, so it may seem.
I agree that the cost/benefit trade off may be based on misjudgment -
but at some stage, that's hard to tell anyway.
I also agree that languages like Lisp, Smalltalk and Prolog are probably
especially attractive for people who can imagine wholly different
approaches from what to others appears to be god-given. And there may
indeed be a desire involved to explore such alternatives even further. I
think that's a positive trait.
> But, hey, Lisp has survived almost half a century that way, insulated
> from the world; it may very well succeed being in that situation for
> another half a century.
;)
Rainer Joswig
<g...@integrable-solutions.net> in
m364cs9...@zeus.integrable-solutions.net:
> Pascal Costanza <p...@p-cos.net> writes:
>
> [...]
>
> | It is true that for almost each and every aspect of Lisp, you can find
> | other languages / systems that have this aspect as well. Lisp is
> | unique in that it combines all these aspects. As Rainer said,
> | Smalltalk and Prolog are quite close, but they also don't provide
> | everything...
>
> I'm not saying there is no reason why those choices were made. Any
> combination of Rainer's enumeration (including its totality) does not seem,
> to me, to justify the insulation. The insulation must come from
> deeper desire, one that does not appear on the (mostly) technical
> reasons he gave.
The 'desire' of the Lisp community is/was to design dynamic evolvable
and complex systems. That shaped Lisp as a language.
So you find/found users of Lisp in research
and within companies with complex 'non-standard' problems. Some of
the users move on, once their domain basics were explored.
Lisp came out of AI research, a complex domain which is not very
good understood. The outcome of that research (if there was some)
then was applied to similar complex domains (natural language
translation, oil exploration, parametric CAD, optimization,
lots of scheduling domains, ...). Users were in government research
and military.
Most software developers are not in these complex domains. They
design web pages, writing CRUD (create, read, update and delete)
applications, ... Still COBOL is widely used. Where not, Java
is the new COBOL. Most new users have only a very shallow
knowledge of CS research. Much knowledge is buried in some
reports in University libraries - hard to find and hard
to reproduce. It seems easier to reinvent, than to build on
existing designs. If a programming language has a few old
identifiers, most new developers aren't able to understand why
they are still there, even if they don't have to use them.
Many developers prefer simpler, more specialized and more static designs.
One also may say that 'companies' prefer developers to use simpler, more
specialized and static designs.
Fortunately, in the last years one could see a younger generation,
that was landing at the shores of this almost forgotten
continent Lisp and which are starting to explore it.
Gabriel Dos Reis
[...]
| I also agree that languages like Lisp, Smalltalk and Prolog are
| probably especially attractive for people who can imagine wholly
| different approaches from what to others appears to be god-given. And
| there may indeed be a desire involved to explore such alternatives
| even further. I think that's a positive trait.
Indeed, that is a positive trait.
Many languages deriving heavily from Lisp have made to wider exposure
to the programming world (sometimes changing the way some people think
about programs) by building standardized links (FFI) to the
traditional "conventional" approaches.
That is the point in Joachim's message that I was expanding on.
I'm skeptical that that missing standardized link from Lisp to the
world of the world can be compensated by any amount of history recitation.
Not that history count -- history is important.
-- Gaby
Bill Atkins
> Many languages deriving heavily from Lisp have made to wider exposure
> to the programming world (sometimes changing the way some people think
> about programs) by building standardized links (FFI) to the
> traditional "conventional" approaches.
> That is the point in Joachim's message that I was expanding on.
What is the problem with CFFI?
Wolfram Fenske
[...]
> The third problem is that Lisp is a separate world, tool-wise. Lisp
> comes with its own set of tools, which may be great but have their own
> ergonomic paradigms, with their own mindset (and, of course, vice
> versa: non-Lisp tools usually won't work well for Lisp work).
Which tools are you referring to? IDEs, Debuggers, something else?
This is not a trick question, I really want to know.
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Gabriel Dos Reis
I don't see anything wrong with it.
In fact, I've been awaiting for something like that for quite a long
time. I'm very delighted to see that effort going on, and I hope it
will be more common. Unfortunately, it does not work yet with the
implementation of Lisp I have to work with. It comes almost half a
century after Lisp has existed; e.g. it will come tomorrow when I
needed it yesterday.
CFFI started by acknowledging the importance of FFI, and the lack of
standard FFIs. Nothing in that disagrees with what I said, nor did I
imply a marginalization of CFFI. I wish it all the best -- so that
communication between Lisp and the rest of the world is no more quagmire.
-- Gaby
Pascal Costanza
Most importantly, history is not over.
Pascal Costanza
> Bill Atkins <atk...@rpi.edu> writes:
>
> | Gabriel Dos Reis <g...@integrable-solutions.net> writes:
> |
> | > Many languages deriving heavily from Lisp have made to wider exposure
> | > to the programming world (sometimes changing the way some people think
> | > about programs) by building standardized links (FFI) to the
> | > traditional "conventional" approaches.
> | > That is the point in Joachim's message that I was expanding on.
> |
> | What is the problem with CFFI?
>
> I don't see anything wrong with it.
>
> In fact, I've been awaiting for something like that for quite a long
> time. I'm very delighted to see that effort going on, and I hope it
> will be more common. Unfortunately, it does not work yet with the
> implementation of Lisp I have to work with. It comes almost half a
> century after Lisp has existed; e.g. it will come tomorrow when I
> needed it yesterday.
Half a century ago, Unix/C didn't exist.
Aidan Kehoe
Ar an triú lá de mí na Nollaig, scríobh Gabriel Dos Reis:
> | Corporate backing is a plus, but neither required (Perl doesn't have
> | it) nor sufficient (Microsoft has been pushing Basic with little
> | success).
>
> C++ did not have a marketing department.
AT&T does qualify as corporate backing, however.
--
Santa Maradona, priez pour moi!
Aidan Kehoe
Ar an triú lá de mí na Nollaig, scríobh Gabriel Dos Reis:
> [..] But, hey, Lisp has survived almost half a century that way, insulated
> from the world;
Bullshit; Lisp is as old as stack-based programming, and Lisp’s death (or
zombification, if you prefer) has been the failure of its programming
community to implement stack-based programming in easily-avaiable
applications and non-portable constructs. Imagine an Emacs Lisp with access
to the POSIX API in 1989, something that was then eminently possible; what
reason would there have been then for Perl?
> it may very well succeed being in that situation for
> another half a century.
--
Gabriel Dos Reis
| Ar an triú lá de mí na Nollaig, scríobh Gabriel Dos Reis:
|
| > | Corporate backing is a plus, but neither required (Perl doesn't have
| > | it) nor sufficient (Microsoft has been pushing Basic with little
| > | success).
| >
| > C++ did not have a marketing department.
|
| AT&T does qualify as corporate backing, however.
Really? How much do you think they spent on marketing C++?
-- Gaby
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > Bill Atkins <atk...@rpi.edu> writes:
| > | Gabriel Dos Reis <g...@integrable-solutions.net> writes:
| > | | > Many languages deriving heavily from Lisp have made to wider
| > exposure
| > | > to the programming world (sometimes changing the way some people think
| > | > about programs) by building standardized links (FFI) to the
| > | > traditional "conventional" approaches. | > That is the point
| > in Joachim's message that I was expanding on.
| > | | What is the problem with CFFI?
| > I don't see anything wrong with it. In fact, I've been awaiting for
| > something like that for quite a long
| > time. I'm very delighted to see that effort going on, and I hope it
| > will be more common. Unfortunately, it does not work yet with the
| > implementation of Lisp I have to work with. It comes almost half a
| > century after Lisp has existed; e.g. it will come tomorrow when I
| > needed it yesterday.
|
| Half a century ago, Unix/C didn't exist.
they came to life only 30 years ago :-)
-- Gaby
Robert Strandh
> Joachim Durchholz <j...@durchholz.org> writes:
>
> > The third problem is that Lisp is a separate world, tool-wise. Lisp
> > comes with its own set of tools, which may be great but have their own
> > ergonomic paradigms, with their own mindset (and, of course, vice
> > versa: non-Lisp tools usually won't work well for Lisp work).
>
> Which tools are you referring to? IDEs, Debuggers, something else?
> This is not a trick question, I really want to know.
I don't know what Joachim is referring to, but I can give you one very
concrete example of such a situation, namely CLIM (the Common Lisp
Interface Manager). Many people come to CLIM with some experience
with other non-Lisp GUI toolkits, and they expect CLIM to work the
same way (attach event handlers to gadgets and do event-driven
programming).
CLIM, however, is completely different from any traditional GUI
library, and one can argue that something like CLIM could not even be
written in/for any traditional language.
--
Robert Strandh
Ray Dillinger
> Alex Mizrahi schrieb:
>
>> more deeply, there is an Intentional Programming thing. it actually
>> means something like programming languages deeply integrated with IDEs
>> [1].
>
>
> This interpretation of IP is just Microsoft's attempt at tying
> programmers into a proprietary binary format and IDE.
In my experience, IDE's are like training wheels. Beginners
depend on them. But people with some experience coding generally
don't need them, and there eventually comes a time when they just
get in the way.
Bear
Joachim Durchholz
> Joachim Durchholz wrote:
>>
>> Well, I already got my share of flamage for stating that Lisp is best
>> used as a language mechanism testbed and not so good for other things,
>> so I'll leave it at that ;-)
>
> ;)
>
>> However, current FPLs have been starting incursions on that territory,
>> too. Parser combinators seem to have made it easy to set up a toy
>> language, and I see it done at the drop of a hat.
>> I think Lisp has serious competition even in that area.
>
> I think you are comparing apples and oranges here. First, parser
> combinators allow you to solve a problem (i.e. parsing) that Lispers
> simply avoid in the first place by relying on the generality of
> s-expressions. The more interesting aspect of "toy languages" (embedded
> languages, domain-specific languages, whatever you want to call them) is
> the specification of their semantics. Parsing is only interesting if you
> consider syntax interesting.
Sure. It's just that before parser combinators, you had to learn Yacc's
crufty syntax and semantics even to dabble with language design. That's
out of the way now.
> Second, the exploration of unknown domains is not only a matter of being
> able to express domain-specific languages. It's also a matter of already
> having quite a number of language constructs at hand that you can use as
> building blocks, without an imposed judgment of which constructs are
> "good" or "bad" for whatever reasons, plus good support for interactive
> development which especially includes the ability to change definitions
> on the fly without the need to interrupt your preferred style of
> working. This includes, for example, the ability to change and/or fix
> definitions while a program using them is running.
I think you're overgeneralizing the specifics of Lisp environments for
general language design.
While I agree that they are useful for that task, I'm not convinced that
this particular combination of features is essential.
When looking at FPL development, I actually see that quite a lot is
happening outside the Lisp area, too.
Lisp seems to be good at doing language design that for additional
features (there are lots and lots), but quite bad at doing language
design that enables additional guarantees (I haven't seen any, apart
from inference toolsets which are - unsurprisingly - limited and
hindered by Lisp's very own flexibility).
Regards,
Jo
Pascal Costanza
>> Second, the exploration of unknown domains is not only a matter of
>> being able to express domain-specific languages. It's also a matter of
>> already having quite a number of language constructs at hand that you
>> can use as building blocks, without an imposed judgment of which
>> constructs are "good" or "bad" for whatever reasons, plus good support
>> for interactive development which especially includes the ability to
>> change definitions on the fly without the need to interrupt your
>> preferred style of working. This includes, for example, the ability to
>> change and/or fix definitions while a program using them is running.
>
> I think you're overgeneralizing the specifics of Lisp environments for
> general language design.
> While I agree that they are useful for that task, I'm not convinced that
> this particular combination of features is essential.
OK, I see your point. However, I still think that Lisp's neutral
position wrt value judgments about language constructs is essential.
To quote Sussman and Steele: "No amount of language design can force a
programmer to write clear programs. [...] The emphasis should not be on
eliminating 'bad' language constructs, but on discovering and inventing
helpful ones."
Of course, that's a conjecture that cannot be proven. But I am convinced
that shutting out language concepts narrows your field of vision.
> When looking at FPL development, I actually see that quite a lot is
> happening outside the Lisp area, too.
>
> Lisp seems to be good at doing language design that for additional
> features (there are lots and lots), but quite bad at doing language
> design that enables additional guarantees (I haven't seen any, apart
> from inference toolsets which are - unsurprisingly - limited and
> hindered by Lisp's very own flexibility).
Check out Qi at http://www.lambdassociates.org/ and especially the very
impressive ACL2 at http://www.cs.utexas.edu/users/moore/acl2/ as two
currently active examples. There are more...
Joachim Durchholz
> Most software developers are not in these complex domains. They
> design web pages, writing CRUD (create, read, update and delete)
> applications, ... Still COBOL is widely used.
Actually, nobody seems to be starting new projects in Cobol anymore, so
it is (finally!) starting to phase out.
Regards,
Jo
Andreas Rossberg
>
> I can't find a reliable source on the invention of parser combinators
> but, but Boot used them long before the mid 90s that googling would
> report. I would appreciate a reference that goes before 90'.
The canonical reference always is this well-known paper:
Philip Wadler, How to replace failure by a list of successes. In
Functional Programming Languages and Computer Architecture (LNCS 201),
Springer 1985
Maybe also relevant:
W.H. Burge, Parsing. In Recursive Programming Techniques, Addison-Wesley
1975
--
Andreas Rossberg, ross...@ps.uni-sb.de
Joachim Durchholz
> Am 03.12.2006 17:42 Uhr schrieb "Gabriel Dos Reis":
>> Rainer Joswig <jos...@lisp.de> writes:
>> | * Lisp usually needs garbage collection. There are almost no standards
>> | for garbage collection systems.
>>
>> indeed, there is no standard for garbage collection systems, but Lisp is
>> not the only language using garbage collection.
>
> Actually there are not THAT many languages that are using similar
> sophisticated garbage collectors. Many systems are using
> reference counting (with some GC tacked on to it to
> clean up cyclic data structures) or conservative GCs.
> Those are less used in the Lisp world.
Only if you restrict yourself to C, C++, and "scripting languages"
(Perl, PHP).
Java doesn't use reference counting. Nor do any of the FPLs that are
commonly discussed in comp.lang.functional.
(Mostly agreeing with the rest.)
> I have argued that Lisp consists of a COMBINATION (!) of design choices
> that automatically make it widely incompatible to native
> OS data structures and many OS level development tools.
I have to chime in here.
Rainer's point is not that Lisp has unique features. His point is that
Lisp has so many nonstandard features that interoperability is so much
more of a challenge than for other languages that it's exceedingly
difficult to do.
Regards,
Jo
Joachim Durchholz
> Joachim Durchholz <j...@durchholz.org> writes:
>
>> The third problem is that Lisp is a separate world, tool-wise. Lisp
>> comes with its own set of tools, which may be great but have their own
>> ergonomic paradigms, with their own mindset (and, of course, vice
>> versa: non-Lisp tools usually won't work well for Lisp work).
>
> Which tools are you referring to? IDEs, Debuggers, something else?
IDEs and Debuggers, yes.
GUIs also tend to follow their own conventions. Not only when
programming them, but also when using them.
In earlier times, Lisp systems used to have their own hypertext markup
system; I'm not sure to what degree that has been replaced with HTML.
Regards,
Jo
Joachim Durchholz
> Joachim Durchholz <j...@durchholz.org> writes:
> | One of Lisp's strengths was and still is higher-order functions:
> | that's an abstraction facilities that few mainstream languages can
> | match. Together with reasonable efficiency, this used to be a USP for
> | several decades, but other languages with HOFs have been available,
> | too, and they at least caught up efficiency-wise in the last decade or
> | two, so Lisp lost that USP.
>
> Lisp's main strengh is its syntax that permit equivalence of data and
> function.
Ah, right, I overlooked that aspect.
Probably because Lisp actually doesn't carry that equivalence as far as
other languages.
E.g. in Haskell, there is no such thing as data; everything is a
function, data is just functions that happen to have no parameters.
Regards,
Jo
Joachim Durchholz
> OK, I see your point. However, I still think that Lisp's neutral
> position wrt value judgments about language constructs is essential.
>
> To quote Sussman and Steele: "No amount of language design can force a
> programmer to write clear programs. [...] The emphasis should not be on
> eliminating 'bad' language constructs, but on discovering and inventing
> helpful ones."
>
> Of course, that's a conjecture that cannot be proven. But I am convinced
> that shutting out language concepts narrows your field of vision.
Sure.
The downside is that you can't design the "guarantee part" of the
language that way.
E.g. in Haskell, certain constructs are forbidden. You can't update
anything in place; there's no way to do shallow binding, all parameter
passing is done lazily, etc. etc. etc.
That's massively restricted when compared to Lisp.
However, on the plus side, these restrictions come with similarly
massive guarantees.
Not having in-place updates means: you can copy anything, and be sure
that (a) it's doing what you expect (no shared data structures that may
be altered by library code that you don't want to analyze right now),
(b) it's just a pointer copy.
No shallow binding means you don't have to worry about names invading
your name space. Or, vice versa, not having to worry that the names
you're setting up may inadvertently alter the behaviour of a routine
that you call.
Always having lazy evaluation means no worrying about what quote
mechanism is the right one to use in a particular situation.
Making a language easy to extend makes it difficult to give guarantees.
It also narrows your field of vision, because you don't get the kind of
guarantees that can ease programming anyway. I suspect that Lispers work
in the direction of ever more expressive power, so while you don't get
more guarantees, the top-level code can be shorter and easier to check
for the guarantees that you need. This approach works well, until the
library code that you call to gain this power is unreliable (if only for
its sheer size).
>> When looking at FPL development, I actually see that quite a lot is
>> happening outside the Lisp area, too.
>>
>> Lisp seems to be good at doing language design that for additional
>> features (there are lots and lots), but quite bad at doing language
>> design that enables additional guarantees (I haven't seen any, apart
>> from inference toolsets which are - unsurprisingly - limited and
>> hindered by Lisp's very own flexibility).
>
> Check out Qi at http://www.lambdassociates.org/
That doesn't say much about Lisp itself, I'd say. Qi seems to be
implemented on top of Lisp, just as Haskell etc. are implemented on top
of C or machine language - the qualities of the target language don't
correlate with those of the source language, I'd say.
... hmm, well, it says you can "mix Qi and Lisp freely". Now if people
are programming in too much Lisp, the guarantees of Qi won't hold up
enough to be useful in practice.
Of course, that depends a lot on how programming is done in practice.
> and especially the very
> impressive ACL2 at http://www.cs.utexas.edu/users/moore/acl2/ as two
> currently active examples.
Again, the interesting properties of that project come from
*restricting* Lisp ("applicative Common Lisp" was the term that caught
my eye in the ACL2 docs).
> There are more...
I suspect that those that try to give guarantees all restrict the use
the raw Lisp in some way.
It would be hard to imagine otherwise, at least for me ;)
Regards,
Jo
Gabriel Dos Reis
[...]
| W.H. Burge, Parsing. In Recursive Programming Techniques,
| Addison-Wesley 1975
OK, now I got it. Because the Boot language I was talking about was
invented by Bill Burge. Thanks!
-- Gaby
Pascal Costanza
> Pascal Costanza schrieb:
>> OK, I see your point. However, I still think that Lisp's neutral
>> position wrt value judgments about language constructs is essential.
>>
>> To quote Sussman and Steele: "No amount of language design can force a
>> programmer to write clear programs. [...] The emphasis should not be
>> on eliminating 'bad' language constructs, but on discovering and
>> inventing helpful ones."
>>
>> Of course, that's a conjecture that cannot be proven. But I am
>> convinced that shutting out language concepts narrows your field of
>> vision.
>
> Sure.
>
> The downside is that you can't design the "guarantee part" of the
> language that way.
Yes, you can. See below.
>>> Lisp seems to be good at doing language design that for additional
>>> features (there are lots and lots), but quite bad at doing language
>>> design that enables additional guarantees (I haven't seen any, apart
>>> from inference toolsets which are - unsurprisingly - limited and
>>> hindered by Lisp's very own flexibility).
>>
>> Check out Qi at http://www.lambdassociates.org/
>
> That doesn't say much about Lisp itself, I'd say. Qi seems to be
> implemented on top of Lisp, just as Haskell etc. are implemented on top
> of C or machine language - the qualities of the target language don't
> correlate with those of the source language, I'd say.
>
> ... hmm, well, it says you can "mix Qi and Lisp freely". Now if people
> are programming in too much Lisp, the guarantees of Qi won't hold up
> enough to be useful in practice.
> Of course, that depends a lot on how programming is done in practice.
Exactly.
> > and especially the very
>> impressive ACL2 at http://www.cs.utexas.edu/users/moore/acl2/ as two
>> currently active examples.
>
> Again, the interesting properties of that project come from
> *restricting* Lisp ("applicative Common Lisp" was the term that caught
> my eye in the ACL2 docs).
Right.
> > There are more...
>
> I suspect that those that try to give guarantees all restrict the use
> the raw Lisp in some way.
Yes.
> It would be hard to imagine otherwise, at least for me ;)
The point is: It's easier to remove features that you have than to add
features that you don't have. In the simplest case, removing features
can be as straightforward as just not using them.
If you're looking for more guarantees, you can easily build new
namespaces / packages / "worlds" in which different rules apply than in
the base Common Lisp language. Qi deviates more from Common Lisp in this
respect, being actually somewhat closer to Scheme, but ACL2 is actually
such a kind of embedded dialect where as much of built-in Common Lisp is
used as possible. ACL2 actually gives very strong guarantees about code,
but also offers ways to (explicitly) relax rules. This again stresses
the Lisp philosophy to always give you a way around restrictions that
possibly stay in your way.
The only feature Lisp doesn't give you is a guarantee that all
developers using Lisp have to abide to exactly the same set of restrictions.
Joachim Durchholz
> The point is: It's easier to remove features that you have than to add
> features that you don't have. In the simplest case, removing features
> can be as straightforward as just not using them.
Well, that's the weakest form of guaranteeing something.
The problem is that this doesn't transfer to third-party libraries. I'd
have trouble to even verify such a promise.
> If you're looking for more guarantees,
Actually I'm looking for better guarantees.
I'm not after enforcing these guarantees, but I'm after reliably
determine whether some property of the code in question holds.
*Particularly* third-party library code.
> you can easily build new namespaces / packages / "worlds" in which
> different rules apply than in the base Common Lisp language.
What kinds of rules?
Some of the guarantees that Haskell gives are quite subtle, and not easy
to state, let alone verify.
Regards,
Jo
Pascal Costanza
> Pascal Costanza schrieb:
>> The point is: It's easier to remove features that you have than to add
>> features that you don't have. In the simplest case, removing features
>> can be as straightforward as just not using them.
>
> Well, that's the weakest form of guaranteeing something.
Of course.
> The problem is that this doesn't transfer to third-party libraries. I'd
> have trouble to even verify such a promise.
Verification is the strongest form of guaranteeing something. There is
space in between. For example, testing seems to work quite well in many
settings.
>> If you're looking for more guarantees,
>
> Actually I'm looking for better guarantees.
> I'm not after enforcing these guarantees, but I'm after reliably
> determine whether some property of the code in question holds.
> *Particularly* third-party library code.
This is a matter of requiring third-party libraries being written in a
specific variant of Lisp. For example, you could require third-party
libraries to be written in ACL2 and then you get all the guarantees that
are proved to be correct for those libraries.
>> you can easily build new namespaces / packages / "worlds" in which
>> different rules apply than in the base Common Lisp language.
>
> What kinds of rules?
> Some of the guarantees that Haskell gives are quite subtle, and not easy
> to state, let alone verify.
You should really give ACL2 a try. The restrictions on that subset of
Common Lisp are pretty severe - only functions that are guaranteed to
terminate are accepted. This enables pretty strong reasoning about your
code. Yet it can be executed in regular Common Lisp. And this is not a
toy language: ACL2 is used in industrial-scale settings...
Mallor
fredas...@yahoo.com wrote:
> THINGS YOU SHOULD KNOW ABOUT BRANDON J. VAN EVERY BEFORE REPLYING TO
> ONE OF HIS POSTS
> 2. He has never been employed in the game industry, in any way,
> shape, manner or form.
Libels never cease. I actually got paid to test games recently. Chump
change... but I did punch a clock, it was a real job. I did what I had
to do to survive. It was a good experience to witness the bottom rung
of the game industry firsthand, but I have no plan to repeat it. It
certainly made me think about the endgame of industrial production, and
how *not* to design software! But hey, if you have $$$$$$$$ and you
can pay people dirt to monkey around with UIs, it's a business model.
I wish I had the time and money to take legal action against you. But,
as usual, I don't. And by the time I do, you won't be relevant
anymore. Not that you're that relevant now... nor am I. That's the
irony. In the small, miserable little world of unemployed open source
that I live in, mowing those lawns and such, where I've actually
contributed a substantive public work to
http://www.call-with-current-continuation.org at extraordinary personal
expense, I have to put up with this. How many demons can dance on the
head of a pin?
Well, there is a positive aspect to this. It reminds me, much like
watching a Holocaust film, or the evening news about Iraq, that there
are people *FAR* more miserable than myself out there. I can't imagine
any other reason you post this stuff. You are addicted to trying to
get a rise out of me. Do you realize how sad you are, picking on
someone as sad as I am, who despite his sadness has nevertheless done
extremely positive things for the open source universe?
But I wasn't a different person before I shipped the Chicken CMake
build. Usenet just has its pathological types.
I'm reading a book right now called, "Crazy Dogs, Crazy People." It
deals with dog and human behavior as one and the same thing; useful for
training my dog. Apparently there's a jailhouse vernacular for
responding to a guy like Fred Aster. It's called, "getting hooked."
Inmates "hook" to get attention, they do it because of what they didn't
get in their childhood. Any emotional rise, over any trivial thing, is
a way of psychologically controlling their jailers. So you can infer
from this that being a jailer is a real PITA, heh!
I should stop kidding myself about asking you to stop it. You won't
stop it. Any response on my part, is the "hook" you're looking for.
Because you're a sad, broken human being. In the book, juveniles like
that could be corrected, if kept under very carefully controlled
institutional conditions. Unfortunately, once placed back in their
shitty "real world" home environments, most regress. I presume your
life is shitty, your environment is shitty, you aren't likely to change
it, probably don't have the life skills to change it, probably don't
have anyone who will ever intervene on your behalf. Best you'll ever
get, is someone like me telling you like it is.
Ok, back to the job hunting grind. Dog sitting, hanging flyers on
doorknobs? Learn Maya SDK stuff? Learn C#, bend over and take it deep
in the ass from Microsoft? Who knows.
Cheers,
Brandon Van Every
Mallor
Joachim Durchholz wrote:
> Mallor schrieb:
> > I wonder whether Lisp syntax is actually a problem to anybody though.
> > People *say* it's a problem, but what really stops Lisp from competing
> > in the mainstream, with the likes of C / C++ / Java / C# ?
>
> Simple. The syntax isn't attractive for newcomers.
> In other words, while I'll take your word that parentheses aren't a
> problem in practice, people who haven't tried that will think they are.
>
> > I'm more inclined to point the finger at absence of killer apps,
>
> Actually that's irrelevant. Python thrives despite the absence of a
> killer app.
These points need to be taken together. My contention is, people whine
about little things when they aren't being given positive signals about
big things.
Python thrived on the web, same as Ruby, Perl, and PHP. The world only
needs so many web / sysadmin scripting languages though.
>
> > lack of standardized FFIs for code migration,
>
> That's a serious problem, yes.
The web and sysadmin stuff didn't have any code to migrate. Systems
languages, on the other hand, are definitely impeded when FFIs are
lacking.
> > and lack of a $$$$$$$$ corporate backer.
>
> Corporate backing is a plus, but neither required (Perl doesn't have it)
Perl, Python, Ruby, and PHP all rode the web.
> nor sufficient (Microsoft has been pushing Basic with little success).
MS was plenty successful with VB until they decided to kill Java with
C#.
> > The reality may be that Lisp is just a language, most coding problems
> > don't require customized languages, and the Big Win was garbage
> > collection.
>
> There's more to that.
> One of Lisp's strengths was and still is higher-order functions: that's
> an abstraction facilities that few mainstream languages can match.
> Together with reasonable efficiency, this used to be a USP for several
> decades, but other languages with HOFs have been available, too, and
> they at least caught up efficiency-wise in the last decade or two, so
> Lisp lost that USP.
Yeah; in other words, the world marches on.
> Lisp's other strength is the ability to write macros at the drop of a
> hat. Personally, I'm actually sceptical that this is really a strength -
> it's certainly a powerful mechanism, but it gives little guarantees (any
> code might do anything, since macros could change almost every aspect of
> the semantics of a piece of code).
Might need beefed up AI to take advantage of that. Java / C# fit the
"restrain the programmers" corporate ethos.
> So, my personal prediction is that Lisp will be superseded by some
> future Haskell dialect... but that's just me, and predictions are
> usually wrong anyway :)
Maybe by that time, programming languages as we practice them will be
passe. Maybe the future is neural nets.
Cheers,
Brandon Van Every
Mallor
Alex Mizrahi wrote:
> (message (Hello 'Mallor)
> (you :wrote :on '(1 Dec 2006 17:27:10 -0800))
> (
>
> M> And you will have tied your project to the sucess / failure of 1
> M> particular editor, until other people get around to writing more such
> M> editors.
>
> who will be tied?
> the editor will produce a valid lisp code, so it can be abandonned at any
> time -- switched to Emacs or whatever.
I think we're talking about 2 different paradigms. I'm talking about
mission critical development in the newfangled language only. You're
talking about mission critical development where the newfangled
language is considered a visualization nicety, and it's acceptable /
expected that programmers will drop back to "straight Lisp" as the need
arises. Even if that need is, say, 1 year of a project. Indeed, your
way can work, but doesn't strike me as practical.
My point is, the newfangled language is not Lisp, and it is valid to
industrialize a language that is not Lisp. Industrializing a language
means getting tools up and running that support that language well,
that play to its strengths, that get the maximum amount of work done,
that aren't gratuitously confusing and fragile, that increase the
mindshare of the language so that more programmers are available to
work on it, etc.
> M> Which, as you can see, nobody is doing even for Common Lisp. Because
> M> it's a lot of work.
>
> i won't estimate it as a lot of work -- someone having right tools and
> knowing them will produce a prototype in a week, and somewhat useable
> version in a month or so. certainly it won't be as featureful as Emacs, but
> i'm anyway using some 0.1% of Emacs features..
People had a prototype of the Chicken Scheme CMake build in a few days.
It took me 1 year to fully duplicate and merge the functionality of
the extant GNU Autoconf build, and it's not because I'm some kind of
bad programmer, contrary to what people might think. It's because
there's tons of shitwork involved in projects like this. I really
can't take people seriously who talk about how quick it is to
prototype, like that's all there is to the job. Actually supporting
all the corner cases is very expensive in terms of programmer time, and
the track record of open source isn't all that great at such things.
Absent the interjection of $$$$$$$$ into the open source economy, which
does happen in certain segments of the market, and is why things like
Linux, Eclipse, and MySQL actually matter.
The proof is in the pudding. It hasn't gotten done. A bazillion
people such as yourself have said, "It shouldn't be that hard." In the
real world, they've been proven wrong. We've got the editors that
people have actually been capable of producing.
Staying funded, i.e. not having to turn and defend your back from
starvation and eviction every other month, is an issue. I've been
doing exactly that and I'll tell you, frankly, nobody can keep that
sort of thing up over the long haul. Maybe I can find the right
part-time job out there, to keep my personal development habit going,
but I'm pretty beaten down about the viability of this kind of
development. I'm inclined to say, it's the kind of thing that college
kids think they can do, because they're not actually paying their
bills. Or that people say can be done, without actually doing it.
> personally, i think that if switching from pure text editor, it should be
> totally new look&feel, but not some variation of an old theme. e.g. totally
> graphical rendering using OpenGL, animation, zoom.. i'm not sure if 3d trees
> are applicable, but who knows :).
I've fantasized about OpenGL-based everything, to free myself of all
the OS dependencies. But, lately I'm not convinced that OpenGL is
healthy enough to survive. OpenGL jobs are currently eluding me in
Seattle. Maybe it's just Seattle that's the problem.
> a neat editor might add it a popularity points -- at first sight, it will
> look very modern and cool, so people thinking that Lisp is something ancient
> will not think so. than, it can provide more effective learning for newbies.
Eclipse is already a neat editor. Not 3D neat, but definitely
production values neat. I think a lot more than "neat" is needed to
make progress. The problem is, Lisp isn't demonstrating any particular
problem domain where it's got industrial advantages. Currently, in
3D-land it has no industrial advantages. I can think of lots of
advantages it *could* have *in principle*, but I have to cough up the
3D engines and 3D API support to prove those contentions. There's no
critical mass of anyone doing anything with Lisp in 3D.
Python had critical mass for web and sysadmin stuff for years, and no
FFI / code migration impediments to speak of. Only recently has it
started to become more mainstream.
> i can also point you to the efforts to make non-text editor for Visual
> Studio: http://www.officialsourceexplorer.com/about.aspx
> this thingie represents code (C#, XML, SQL) as trees and allow easier
> refactoring.
> so, Visual Studio guys are improving their editors, why Lisp guys
> shouldn't? :)
The VS guys are making money doing it. They have a business model for
their timewasters.
> M> The reality may be that Lisp is just a language, most coding problems
> M> don't require customized languages, and the Big Win was garbage
> M> collection.
>
> it's up to you to think so, but why people are now doing data queries in SQL
> and do output with HTML, struggling with strings (oh, how many security
> holes are SQL-injections, that are merely because of semantic is trimmed
> when value is coerced to string, thus you cannot distinguish datatypes)?
Why should industrial programming be based on quality? As far as I can
tell from my current job hunting, it's based on "SQL" being easy for HR
drones to utter. If things break, you hire more Chinese to fix 'em.
Or 1 local consultant to fix 'em. The computer industry is run on vast
amounts of $$$$$$$$, not quality.
> with Lisp, i was able to create a wrapper for SPARQL (RDF) queries, where i
> can do queries just like i do usual variable bindings, and wrappers
> automatically convert types. then i can embed values being fetched directly
> into HTML using LML2, so all code is in s-expressions:
>
> (rdf:do-query
> ((?user :name ?uname)
> (?uname :first-name ?fname)
> (?uname :last-name ?lname)
> (?user :salary ?salary))
> (html (:tr
> (:td (:princ ?fname))
> (:td (:princ ?lname))
> (:td (:princ ?salary)))))
>
> what other language can do that, and how much longer and error-prone would
> it be?
Fine; show me the part of the world where people are actually getting
paid to do that. Maybe I'll go there. But until this part of the
world proves that such approaches are actually Enlightened in the
$$$$$$$$$ sense of the term, it doesn't matter. My Chicken Scheme
CMake build is much better than most GNU Autoconf builds out there.
Nobody cares; my skill / knowedge / insight isn't buzzword compliant.
Cheers,
Brandon Van Every
Mallor
Rainer Joswig wrote:
>
> Lisp came out of AI research, a complex domain which is not very
> good understood. The outcome of that research (if there was some)
> then was applied to similar complex domains (natural language
> translation, oil exploration, parametric CAD, optimization,
> lots of scheduling domains, ...). Users were in government research
> and military.
>
> Most software developers are not in these complex domains. They
> design web pages, writing CRUD (create, read, update and delete)
> applications, ...
Definitely true of the job posts I see on mainstream job sites. All
web CRUD. It completely bores me, and you've helped explain why it
bores me. I still don't know where the "complex" jobs are hiding, but
I will have to keep looking. Maybe that in and of itself is part of
the problem. If people can't find the "complex" jobs, because there
just aren't that many of them anymore, or they're just not being much
advertized, then the need for "complex" programmers withers.
Cheers,
Brandon Van Every
Frank Buss
This reminds me again to http://www.imdb.com/title/tt0371724/quotes :
> I wish I had the time and money to take legal action against you. But,
> as usual, I don't. And by the time I do, you won't be relevant
> anymore. Not that you're that relevant now... nor am I. That's the
> irony.
Marvin: Not that anyone cares what I think
> Do you realize how sad you are, picking on
> someone as sad as I am, who despite his sadness has nevertheless done
> extremely positive things for the open source universe?
Marvin: I think you ought to know I'm feeling very depressed.
Marvin: Here I am, brain the size of a planet, and they ask me to take you
to the bridge. Call that job satisfaction, 'cause I don't.
I really like these writings, but maybe you should post it to
alt.fan.douglas-adams instead of cross posting it to several unrelated
groups.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Bill Atkins
> bores me. I still don't know where the "complex" jobs are hiding, but
> I will have to keep looking. Maybe that in and of itself is part of
Hint: they're not hiding on Usenet.
fredas...@yahoo.com
Mallor wrote:
> fredas...@yahoo.com wrote:
> > THINGS YOU SHOULD KNOW ABOUT BRANDON J. VAN EVERY BEFORE REPLYING TO
> > ONE OF HIS POSTS
>
>
> > 2. He has never been employed in the game industry, in any way,
> > shape, manner or form.
>
> Libels never cease. I actually got paid to test games recently. Chump
> change... but I did punch a clock, it was a real job. I did what I had
> to do to survive. It was a good experience to witness the bottom rung
> of the game industry firsthand, but I have no plan to repeat it. It
> certainly made me think about the endgame of industrial production, and
> how *not* to design software! But hey, if you have $$$$$$$$ and you
> can pay people dirt to monkey around with UIs, it's a business model.
Good for you, you actually got a job in the games industry! How's this
for a correction, then:
2. He has never been employed in the game industry as a game designer
or game developer of any sort. Despite this, for some reason he
managed to get named as an Independent Games Festival judge; a
curious turn of events, since their stated intent is to appoint
"professionals in the game industry" (their quote, not his).
I always appreciate your input, Brandon. It helps ensure that the
document is accurate and fair and also promptly dashes all your
ridiculous false claims of "libel".
Your fan,
Fred