sweet-expressions instead of s-expressions?
Neil Toronto
and standard C-like imperatives, just recently became proficient in
Python and becoming interested in Common Lisp. Why? I want the
functional goodness and the MACROS, that's why. Also, I do computer
vision and machine learning research, and my Python code is rather
slow. I'd like something that's almost as fast as C but very
expressive, and is strict but highly dynamic and dynamically-typed.
Here's what's keeping me with Python: my code reads like pseudocode,
and I love that. When I come back to Python code I haven't seen in
months, it takes me all of five seconds to grok it again.
So has anyone seen this?
http://www.dwheeler.com/readable/readable-s-expressions.html
Short version: significant whitespace (indentation can replace parens),
"func(param1 param2)" calls, infix notation (which is good for math
code), and it still parses regular s-expressions correctly. Because it
transforms "sweet-expressions" to s-expressions, macros still work.
Example:
defun factorial (n)
if (n <= 1)
1
n * factorial(n - 1)
(which even I can parse :D) is translated to:
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (- n 1)))))
(which I can still parse, but with more trouble). Or this:
(2 + mystuff(7 + x) * -(henry) - correction(a b c d) + 2 - pi() - x)
which is translated to this:
(- (+ (- (+ 2 (* (mystuff (+ 7 x)) (- henry)))
(correction a b c d)) 2) (pi) x)
He's almost got me convinced.
I understand that experienced Lispers use indentation to understand
code more than parenthesis anyway. This creates a situation (rather
like in C-like languages) where the language syntax *doesn't inherently
communicate with the coder very well*, and coder has to add redundant
formatting to make it clear. Then, like in IDEs for C-like languages,
the editors support this to make programming less painful. So why not
take the Python route and make formatting syntactically significant?
The only difference is that Python requires it, "sweet-expressions"
don't.
My main question is whether there are any downsides at all to this
approach.
And as an aside, I'd love to have Python's array (list) and dictionary
(hash table) syntax. I'd switch to Lisp and convert my entire codebase
TODAY if I had that.
vse...@gmail.com
Vladimir
Ken Tilton
Neil Toronto wrote:
> Quick background from the newb:
Lousy spelling. Should be "fom the t-r-o-l-l".
hth, kenny
--
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
Pascal Costanza
> Quick background from the newb: Programmer for 22 years with assembly
> and standard C-like imperatives, just recently became proficient in
> Python and becoming interested in Common Lisp. Why? I want the
> functional goodness and the MACROS, that's why. Also, I do computer
> vision and machine learning research, and my Python code is rather
> slow. I'd like something that's almost as fast as C but very
> expressive, and is strict but highly dynamic and dynamically-typed.
>
> Here's what's keeping me with Python: my code reads like pseudocode,
> and I love that. When I come back to Python code I haven't seen in
> months, it takes me all of five seconds to grok it again.
How long have you been learning Common Lisp?
I am asking this because it typically takes a week or two (or sometimes
a few more) until you get used to Lisp syntax. Afterwards, with more
experience, it's typically not an issue anymore. (Although it could
simply be that those for whom this is then still an issue switch to
other languages.)
> So has anyone seen this?
>
> http://www.dwheeler.com/readable/readable-s-expressions.html
>
[...]
> My main question is whether there are any downsides at all to this
> approach.
I don't think so. Adding a surface syntax to Lisp shouldn't be that much
of a problem, as long as the internal representation stays the same. It
could indeed be interesting if there were several different surface
syntaxes, for example including graphical ones, which would move Lisp
towards something like intentional programming.
On the other hand, I also think that adding one ore more surface
syntaxes doesn't solve a fundamental problem, and I don't expect that a
considerably large number of Lispers will take up this idea because of
that. After all, it's _just_ syntax. In other words, there aren't any
downsides, but there also aren't any essential upsides.
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/
Neil Toronto
> Neil Toronto wrote:
> > Quick background from the newb:
>
> Lousy spelling. Should be "fom the t-r-o-l-l".
>
> hth, kenny
Ah, I see. So not only is the syntax hostile, but so is the community.
Fascinating! I wonder if this is as well-studied as Lisp syntax
alternatives.
Pascal Costanza wrote:
> Neil Toronto wrote:
> > Here's what's keeping me with Python: my code reads like pseudocode,
> > and I love that. When I come back to Python code I haven't seen in
> > months, it takes me all of five seconds to grok it again.
>
> How long have you been learning Common Lisp?
>
> I am asking this because it typically takes a week or two (or sometimes
> a few more) until you get used to Lisp syntax. Afterwards, with more
> experience, it's typically not an issue anymore. (Although it could
> simply be that those for whom this is then still an issue switch to
> other languages.)
Not too long - I'm mostly just looking into it as a speedy alternative
to other dynamically-typed languages. I did spend a semester working in
Scheme, which I found to be a chore, and I never did get used to it. I
think your parenthetical remark is pretty much spot-on.
> > So has anyone seen this?
> >
> > http://www.dwheeler.com/readable/readable-s-expressions.html
> >
> [...]
>
> > My main question is whether there are any downsides at all to this
> > approach.
>
> I don't think so. Adding a surface syntax to Lisp shouldn't be that much
> of a problem, as long as the internal representation stays the same. It
> could indeed be interesting if there were several different surface
> syntaxes, for example including graphical ones, which would move Lisp
> towards something like intentional programming.
>
> On the other hand, I also think that adding one ore more surface
> syntaxes doesn't solve a fundamental problem, and I don't expect that a
> considerably large number of Lispers will take up this idea because of
> that. After all, it's _just_ syntax. In other words, there aren't any
> downsides, but there also aren't any essential upsides.
I wasn't thinking about Lispers, I was thinking about *me*. Lispers
are, by definition, just fine with the syntax as it is.
I disagree very much with the "just" in front of the "syntax" in your
post. Syntax is *extremely* important. We're not writing programs just
for the compiler, we're writing them for our future selves and other
people. If all programmers thought like compilers, we'd have no
problem. But the fact that even hard-core Lispers need to indent the
heck out of their code and learn to literally ignore a significant
portion of the syntax (the parens) indicates that something may be
lacking in the syntax. C programmers indent, sure, but they don't have
to learn to ignore.
Not that I intend to start a flame-war or anything. I know, I'm getting
close. If that happens, I fully expect the great Paul Graham to jump in
and defend me. :D Apparently, Arc's indentation will have syntactic
meaning.
By the way, thanks for writing your "Highly Opinionated Guide." It's
the only document I've found so far that provides a good summary of
Lisp's advantages over other dynamically-typed languages. Your summary
of macros was especially helpful.
Also, thanks for answering my question.
Neil
jos...@corporate-world.lisp.de
> I wasn't thinking about Lispers, I was thinking about *me*. Lispers
> are, by definition, just fine with the syntax as it is.
How to you become a 'Lisper'? Probably by learning and practicing Lisp.
That includes to learn the culture, the habits and the tools of Lisp
programming. You approach a different culture, but you are
not really open minded. Since Lisp requires a different mental
model of computation (and that includes not only syntax)
you need to be prepared to learn a few new things (for example
how to read/write/manipulate Lisp code). If you think that
this is too expensive (time, brain cells, ...) for you, I think you
should not waste your time with syntax experiments and just
skip over Lisp, and look for some other solution to your problem -
a solution that is more compatible with your current believes.
> I disagree very much with the "just" in front of the "syntax" in your
> post. Syntax is *extremely* important. We're not writing programs just
> for the compiler, we're writing them for our future selves and other
> people.
I'm not sure what that has to do with Lisp. Lisp's external syntax
is not for some compiler. Lisp programmers find it useful
because it makes tool building very easy. Macros are
just one of these tools.
> If all programmers thought like compilers,
How does a compiler think?
> we'd have no
> problem. But the fact that even hard-core Lispers need to indent the
> heck out of their code
I almost never indent the code by hand. The editor or the Lisp system
(pretty printing)
does it for me. I like indented code. Nicely indented, color coded
code.
Indented by the editor or the Lisp system. Good Lisp code is a real
pleasure to read.
> and learn to literally ignore a significant
> portion of the syntax (the parens) indicates that something may be
> lacking in the syntax.
Why should a Lisp programmer ignore the parentheses? That would be
stupid. Actually they are part of what makes Lisp programming fun.
Lisp programming has several different dimensions. One is
the manipulation of external (text-based) code and data. Programmers
need to write/read/manipulate code. Lisp is optimized to
allow tools to support you during working with external text-based
code.
Lisp allows the editor to query the Lisp system while you type code.
The running Lisp system knows all about your code (where it is defined,
the documentation, the arglists, the types, the contents, the callers,
...).
Lisp allows the editor to query the Lisp system while you read code.
You can jump to definitions, inspect values, try out examples, ...
Lisp also supports you manipulating your code. Every expression has
a very simple to find start and end. You can use simple structure-based
editing (see paredit), which has little mental overhead once learned
(it is a bit like learning to ride a bicycle). It allows you to
manipulate
your code based on list structure (select, transpose, group, extract,
copy, ...).
So, you have an editor/language combination which supports you
manipulating your code and you have a Lisp system which is
available during editing for various queries.
Then comes the interactive experience. You are working with an editor,
which is connected to a Lisp system (for example via SLIME if your
editor is Emacs). Alternatively you will use an editor-based Listener.
Then you can start thinking of code as data. You will
write some code/data in the editor/listener and the Lisp system
reads them and you can apply functions that manipulate that code.
A simple example is a macro expansion. Your editor buffer
has some code and you want to macro expand it. The editor
takes the code, the Lisp system reads it, generates data structures,
macro expands them, returns new code and your editor displays
it (possibly pretty printed).
You can also write some sketch of some code, read it
into the Lisp system and use the Lisp
system to manipulate it until it has the form you like.
Pretty print the result and place it in your editor buffer.
The whole tool chain is highly optimized around Lisp syntax,
Lisp datastructures and the various tools to read/write/manipulate
these datastructures.
More advanced systems can also parse Lisp data directly from
editor buffers (like you want to display a class graph, the
editor prompts you for a class and all class names in your
editor buffers are mouse sensitive). Or tools like McCLIM
allow you to have mouse sensitive Lisp read-eval-print-loops.
Back to your question. What is the cost of ignoring the Lisp culture
around the syntax? You will have difficulty to use the tool chain.
But then, the syntax is just the first hurdle. Be prepared for more
hurdles. Probably higher ones.
> C programmers indent, sure, but they don't have
> to learn to ignore.
Forget the 'ignore' thing.
> Not that I intend to start a flame-war or anything. I know, I'm getting
> close. If that happens, I fully expect the great Paul Graham to jump in
> and defend me. :D Apparently, Arc's indentation will have syntactic
> meaning.
Maybe you should switch to Arc. As soon as it does what you want.
2010? 2015? 2020? Who knows.
> By the way, thanks for writing your "Highly Opinionated Guide." It's
> the only document I've found so far that provides a good summary of
> Lisp's advantages over other dynamically-typed languages. Your summary
> of macros was especially helpful.
>
> Also, thanks for answering my question.
My final advice? If you really want to use Lisp (because it may solve
your
initial problem of finding a dynamic language with useful performance),
then you should invest the time to learn the whole culture. Most
beginners find that after some time (maybe a month) they can read
Lisp code just fine. Some are then very enthusiastic about the
excellent
readability of their Lisp code, because they suddenly can write very
high-level
problem-specific code.
>
> Neil
Ari Johnson
> defun factorial (n)
> if (n <= 1)
> 1
> n * factorial(n - 1)
>
> (which even I can parse :D) is translated to:
>
> (defun factorial (n)
> (if (<= n 1)
> 1
> (* n (factorial (- n 1)))))
> ...
> I understand that experienced Lispers use indentation to understand
> code more than parenthesis anyway. This creates a situation (rather
> like in C-like languages) where the language syntax *doesn't inherently
> communicate with the coder very well*, and coder has to add redundant
> formatting to make it clear.
Let's test the implicit hypothesis that s-expression syntax does not
inherently communicate with the programmer very well in the absence of
redundant (actually, "superfluous" is a more precise term) formatting
and that Algol syntax does:
defun factorial (n)
if (n <= 1)
1
n * factorial(n - 1)
Not any better than:
(defun factorial (x)
(if (<= n 1)
1
(* n (factorial (1- n)))))
The main difference is that it is borderline trivial to auto-indent
the second one with your editor.
Let's try another test:
defun factorial (x) if (n <= 1) 1 n * factorial(n - 1)
This is hard to read and also shows another weakness: explicit
grouping, and therefore no precedence rules to remember. If you take
out the parentheses, you have to memorize precedence rules.
Precedence rules are one of the chief things that make it easy to
write unreadable C and Perl.
By contrast:
(defun factorial (x) (if (<= n 1) 1 (* n (factorial (1- n)))))
This is more readable and, in the event you have trouble reading it,
can still be auto-indented.
> And as an aside, I'd love to have Python's array (list) and dictionary
> (hash table) syntax. I'd switch to Lisp and convert my entire codebase
> TODAY if I had that.
I don't know Python, but Common Lisp makes it easy to add syntax.
Reader macros are normally all it takes to get the kind of syntax you
are likely after.
Pascal Bourguignon
> Ken Tilton wrote:
>> Neil Toronto wrote:
>> > Quick background from the newb:
>>
>> Lousy spelling. Should be "fom the t-r-o-l-l".
>>
>> hth, kenny
>
> Ah, I see. So not only is the syntax hostile, but so is the community.
> Fascinating! I wonder if this is as well-studied as Lisp syntax
> alternatives.
Yes, indeed, it's a well studied subject too.
> I disagree very much with the "just" in front of the "syntax" in your
> post. Syntax is *extremely* important.
Not in Lisp. Not *that* syntax.
> We're not writing programs just
> for the compiler, we're writing them for our future selves and other
> people. If all programmers thought like compilers, we'd have no
> problem. But the fact that even hard-core Lispers need to indent the
> heck out of their code and learn to literally ignore a significant
> portion of the syntax (the parens) indicates that something may be
> lacking in the syntax. C programmers indent, sure, but they don't have
> to learn to ignore.
It's not "ignore" literally either. There are serveral level of
reading. For example, at the lexical level, it hurts the eyes when
you can't write "newbie" correctly, or whey Kenny can't spell "from".
All levels are important, and you can be sure that no parenthesis is
overlooked or added gratuituously in Lisp. It's just that at the
level that matters for programming sophisticated software, parentheses
are not a problem but part of the solution, even if a small part. If
S-expressions were a problem, it IS ALREADY solved, as LISP was
defined in terms of M-expressions, FIFTY YEARS AGO!
So you'll have to perdon us, if after FIFTY YEARS people keep looking
half a hour at lisp and keep suggesting to modify the syntax:
- we've got better things to do,
- we've solved the problem once for all with reader macros and macros
that allow you to modify the syntax in your program.
I'd just add that IMO, this question should be solved at the editor
level: everytime you load a source file in an editor, the editor
should apply any syntax, indenting and colorizing the programmer
prefers. (And therefore the source files should keep a consistent
form: S-expressions, and the use of reader macros should be avoided).
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
Stephen Compall
> Here's what's keeping me with Python: my code reads like pseudocode,
> and I love that.
Have you considered the possibility that it is your pseudocode that
reads like Python?
--
Stephen Compall
http://scompall.nocandysw.com/blog
Pascal Bourguignon
> Quick background from the newb: Programmer for 22 years with assembly
> and standard C-like imperatives, just recently became proficient in
> Python and becoming interested in Common Lisp. Why? I want the
> functional goodness and the MACROS, that's why. Also, I do computer
> vision and machine learning research, and my Python code is rather
> slow. I'd like something that's almost as fast as C but very
> expressive, and is strict but highly dynamic and dynamically-typed.
>
> Here's what's keeping me with Python: my code reads like pseudocode,
> and I love that. When I come back to Python code I haven't seen in
> months, it takes me all of five seconds to grok it again.
Here is how you write pseudo code in lisp, and have it running:
http://groups.google.com/group/comp.lang.lisp/msg/a827235ce7466a92
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You question the worthiness of my code? I should kill you where you
stand!"
Lars Rune Nøstdal
> Quick background from the newb: Programmer for 22 years with assembly and
> standard C-like imperatives, just recently became proficient in Python and
> becoming interested in Common Lisp. Why? I want the functional goodness
> and the MACROS, that's why. Also, I do computer vision and machine
> learning research, and my Python code is rather slow. I'd like something
> that's almost as fast as C but very expressive, and is strict but highly
> dynamic and dynamically-typed.
>
> Here's what's keeping me with Python: my code reads like pseudocode, and I
> love that. When I come back to Python code I haven't seen in months, it
> takes me all of five seconds to grok it again.
>
> So has anyone seen this?
>
> http://www.dwheeler.com/readable/readable-s-expressions.html
>
> Short version: significant whitespace (indentation can replace parens),
> "func(param1 param2)" calls, infix notation (which is good for math code),
> and it still parses regular s-expressions correctly. Because it transforms
> "sweet-expressions" to s-expressions, macros still work.
Haha - you've just stepped right into the same "trap" almost every
newbie (I did too!) falls into. But don't worry about the elite flamers;
they can't really hurt you - you'll just resurrect anyway and try again
after you have gained some more experience. (yay; I play too much WoW ..
lol)
If you panic and try to struggle it'll get much worse; just go along with
the main ride or bail out until you're ready.
Yep; get over it as quick as possible and hold on for the rest of ride
because there will be some crazy changes. This is just the first one of
many bumps so you've better brace yourself!
Good luck and have fun .. :)
--
Lars Rune Nøstdal
http://lars.nostdal.org/
Rob Warnock
+---------------
| Neil Toronto wrote:
| > http://www.dwheeler.com/readable/readable-s-expressions.html
| > My main question is whether there are any downsides at all to this
| > approach.
|
| I don't think so. Adding a surface syntax to Lisp shouldn't be that
| much of a problem, as long as the internal representation stays the
| same. It could indeed be interesting if there were several different
| surface syntaxes, for example including graphical ones, which would
| move Lisp towards something like intentional programming.
As in ProGraph (q.v.), perhaps? ;-}
+---------------
| On the other hand, I also think that adding one ore more surface
| syntaxes doesn't solve a fundamental problem, and I don't expect
| that a considerably large number of Lispers will take up this idea
| because of that. After all, it's _just_ syntax. In other words, there
| aren't any downsides, but there also aren't any essential upsides.
+---------------
Actually, I would say that, based on my experience with alternative
surface syntaxes for Scheme/Lisp [Google for my name and "P'Lite"
or "OPFR"], there *are* downsides for "Lispers", especially for
writing sizeable programs. I myself have abandoned each of the
surface syntaxes I've come up with for *programming*, because
they (1) got in the way, and (2) were *not* as readable when I
came back to the code weeks, months, or years later. Normal Lisp
[or Scheme] code, on the other hand, is "timeless". IMHO.
That said, I continue to advocate the use of a "mild" parentheses-
light surface syntax [OPFR] for *interactive* (command-line style
or REPL-like) use, especially for non-Lisper users, for a variety
of more-or-less dedicated "tool" programs.
The "hwtool" pattern that I seem to keep re-implementing[1] over
and over at each new job is a prime case in point. It seems to be
something of a sweet spot in design/use space, with the following
salient features:
1. When run from the shell without arguments, you get a command-line
prompt with a REPL; given arguments, the rest of the line is taken
as a single input command-line, then it exits.
2. The input [either REPL or shell command] is parsed by "OPFR",
an "Outer-Parentheses-Free Repl" (q.v.). That is, to a first
approximation [ignoring details like continuation lines],
OPFR:OPFR-READ takes an input line string, wraps "(" & ")"
around it, and calls READ-FROM-STRING, then does the usual EVAL,
print [including multiple values], and loop.
3. To make life easier for Lisp-aware users [including me],
any input that begins with "(" is assumed to be a CL s-expr,
and normal CL:READ is called to read it.
4. For hardware debugging [its main use], the usual panoply
of PEEK, POKE, DUMP, etc., utility functions is provided.
5. To make life easier for non-Lisper users [and for hardware
debugging], a "0x" readmacro is enabled, and a "~/0x/" FORMAT
function is provided to ease the writing of register dumps.
6. A large majority of things a user needs to do with the tool
are pre-defined as functions, which therefore appear to the
naive user as "commands" in the REPL.
7. The program sets a fairly large number of global lexical[1]
convenience variables with values precomputed from the run-time
environment, so that most of the time all of the "command"
arguments a user needs are either one of the precomputed
convenience variables or literal constants. This sharply
lessens the need for typing actual Lisp arithmetic expressions
as input.
A very small example:
$ hwtool
Hardware debug tool (CMUCL version)
Warning: Non-root can't mmap "/dev/mem"
hwtool> loop for i below 10 collect i
(0 1 2 3 4 5 6 7 8 9)
hwtool> deflex vec (vector 1 2 3 4 5)
VEC
hwtool> d32 vec
0x48a0b908: 0x00000032 0x00000014 0x00000004 0x00000008
0x48a0b918: 0x0000000c 0x00000010 0x00000014 0x00000000
0x48a0b928: 0x48a08b3f 0x48a0b933 0x28f0000b 0x28f0000b
0x48a0b938: 0x0000008c 0x28f0000b 0x48a0b93b 0x48a08d2b
hwtool>
Since I don't have any poke-able hardware registers handy at
the moment, let's reach in and mess with the internals of VEC.
[Don't try this at home unless you and your GC are best of friends!]
hwtool> w32 0x48a0b918 0x28 ; Decimal 10, as a CMUCL fixnum
hwtool> d32 vec
0x48a0b908: 0x00000032 0x00000014 0x00000004 0x00000008
0x48a0b918: 0x00000028 0x00000010 0x00000014 0x00000000
0x48a0b928: 0x48a08b3f 0x48a0b933 0x28f0000b 0x28f0000b
0x48a0b938: 0x0000008c 0x28f0000b 0x48a0b93b 0x48a08d2b
hwtool> vec
#(1 2 10 4 5)
hwtool> w32 0x48a0b920 (lisp-obj #\A) ; Chars are immeds.
hwtool> d32 vec
0x48a0b908: 0x00000032 0x00000014 0x00000004 0x00000008
0x48a0b918: 0x00000028 0x00000010 0x000041a6 0x00000041
0x48a0b928: 0x48a08b3f 0x48a0b933 0x28f0000b 0x28f0000b
0x48a0b938: 0x0000008c 0x28f0000b 0x48a0b93b 0x48a08d2b
hwtool> vec
#(1 2 10 4 #\A)
hwtool>
As I have written before, this appears to be just enough masking
of the "Lispiness" to make such programs be quite acceptable to
general technical users (e.g., hardware engineers, C programmers).
-Rob
[1] Re-inventing, to avoid IP contamination from the PPoE.
[2] Using the now-common DEFINE-SYMBOL-MACRO hack.
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
MarkHa...@gmail.com
> Ken Tilton wrote:
> > Neil Toronto wrote:
> > > Quick background from the newb:
> >
> > Lousy spelling. Should be "fom the t-r-o-l-l".
> >
> > hth, kenny
>
> Ah, I see. So not only is the syntax hostile, but so is the community.
> Fascinating! I wonder if this is as well-studied as Lisp syntax
> alternatives.
>
Yes it has. It's called smug lisp weenieness. Don't worry though,
they live in the bubble and like it that way. As someone else
mentioned, you might want to take a look at Dylan. The only problem
with Dylan is that it's even more dead than Lisp. S-expressions aren't
that bad, but if the editor support is in there for "sweet expressions"
and you can toggle it back and forth, why not.
jayessay
> Ah, I see. So not only is the syntax hostile, but so is the
> community. Fascinating! I wonder if this is as well-studied as Lisp
> syntax alternatives.
How ironic. Someone from Python land talking about "hostile syntax"
and "hostile communities".
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Pascal Costanza
> Pascal Costanza wrote:
>> Neil Toronto wrote:
>>> Here's what's keeping me with Python: my code reads like pseudocode,
>>> and I love that. When I come back to Python code I haven't seen in
>>> months, it takes me all of five seconds to grok it again.
>> How long have you been learning Common Lisp?
>>
>> I am asking this because it typically takes a week or two (or sometimes
>> a few more) until you get used to Lisp syntax. Afterwards, with more
>> experience, it's typically not an issue anymore. (Although it could
>> simply be that those for whom this is then still an issue switch to
>> other languages.)
>
> Not too long - I'm mostly just looking into it as a speedy alternative
> to other dynamically-typed languages. I did spend a semester working in
> Scheme, which I found to be a chore, and I never did get used to it. I
> think your parenthetical remark is pretty much spot-on.
...but don't interpret too much into this remark. Different people have
different preferences, and may simply think differently. The fact that
some people don't seem to get used to Lisp syntax doesn't mean that this
is an inherent problem of Lisp syntax. It also doesn't mean that this is
an inherent problem of those people. It just means that Lisp is just not
a good match for those people.
However, the fact that there is a considerable number of people who
prefer Lisp syntax, even strongly so, shows that it has its merits.
>> On the other hand, I also think that adding one ore more surface
>> syntaxes doesn't solve a fundamental problem, and I don't expect that a
>> considerably large number of Lispers will take up this idea because of
>> that. After all, it's _just_ syntax. In other words, there aren't any
>> downsides, but there also aren't any essential upsides.
>
> I wasn't thinking about Lispers, I was thinking about *me*. Lispers
> are, by definition, just fine with the syntax as it is.
>
> I disagree very much with the "just" in front of the "syntax" in your
> post. Syntax is *extremely* important. We're not writing programs just
> for the compiler, we're writing them for our future selves and other
> people. If all programmers thought like compilers, we'd have no
> problem. But the fact that even hard-core Lispers need to indent the
> heck out of their code and learn to literally ignore a significant
> portion of the syntax (the parens) indicates that something may be
> lacking in the syntax. C programmers indent, sure, but they don't have
> to learn to ignore.
Yes, they do. Or do you really think that experienced C programmers
carefully investigate the meaning of each single semicolon? ;)
The problem with additional syntax is that by definition, you lose the
regularity of the syntax. The more you add, the worse it gets. And this
impedes with syntactic extensibility. The more syntax there already is,
the harder it is to add new syntax that fits well with the rest of a
language.
So what you get in syntactically richer languages is maybe a slight
advantage in the learning phase because of some level of familiarity of
the syntax, but a strong disadvantage in the malleability of the code
representation. In Lisp, you can make the code look like related
concepts from a given problem domain. You can't do that (so well) in
other languages. So either the languages already fit your problem
domain, or they don't in which case you have a discrepancy between the
problem and they way you have to express a solution.
You may want to take a deeper look at Dylan, which was an attempt at a
compromise. The syntax is somewhat richer than Lisp syntax, but still
relatively regular. You might want to take a look at Jonathan Bachrach's
work on "Dylan Procedural Macros" and the "Java Syntactic Extender" in
this context - see http://people.csail.mit.edu/jrb/
> By the way, thanks for writing your "Highly Opinionated Guide." It's
> the only document I've found so far that provides a good summary of
> Lisp's advantages over other dynamically-typed languages. Your summary
> of macros was especially helpful.
>
> Also, thanks for answering my question.
You're welcome.
JShr...@gmail.com
personally; everyone new to lisp does, which is why this conversation
happens over and over and over again.) Let me repeat your own words to
you:
"[I am] becoming interested in Common Lisp. Why? I want the functional
goodness and the MACROS, that's why."
The whole point of Lisp -- the thing that makes Lisp Lisp and not any
other language -- is the amazing discovery that both the programmer and
the computer can in fact read and write THE SAME CODE!
If we did what you propose -- if we gave Lisp some sort of random
surface syntax. (Python is an especially random example of this --
using, of all things, whitespace and lineturns (!!) as syntax) which
was read differently by the programmer and the computer, then all the
magic of Lisp, esp. Macros, which you claim to be the thing that
brought you to Lisp, would suddenly vanish in a puff of syntax.
You don't understand this yet, but you will if you keep at it, and esp.
when you get to macros.
Now, closely related to this, your second point:
"And as an aside, I'd love to have Python's array (list) and dictionary
(hash table) syntax. I'd switch to Lisp and convert my entire codebase
TODAY if I had that."
You do have that; They are called hash tables and the only differences
are that you have to declare them before using them, and they have a
slightly more long-winded syntax than python's. Here's a challenge for
your first experiment in macros: You want python-style dictionaries. By
the magic of Lisp syntax and macros, you can in fact, have them!
Remember in thinking through this: Don't fight the syntax! If you try
to have both python dicts AND python syntax, you'll lose, and you'll
lose macros and you might as well go back to Python. But you'll know
that you've learned to think in Lisp when you can see that this, and
anything else you want, you can have; the only limitation is your
imagination! A small price to pay, I'd say, for having to say (+ 1 2)
instead of 1+2....
'Jeff
Pascal Bourguignon
> Now, closely related to this, your second point:
>
> "And as an aside, I'd love to have Python's array (list) and dictionary
> (hash table) syntax. I'd switch to Lisp and convert my entire codebase
> TODAY if I had that."
>
> You do have that; They are called hash tables and the only differences
> are that you have to declare them before using them, and they have a
> slightly more long-winded syntax than python's. Here's a challenge for
> your first experiment in macros: You want python-style dictionaries. By
> the magic of Lisp syntax and macros, you can in fact, have them!
(defun literal-hash-table (key-value-others)
(loop
:with table = (make-hash-table :test (function equal))
:for (key value) :on key-value-others :by (function cddr)
:do (setf (gethash key table) value)
:finally (return table)))
(defun python-dictionary-reader-macro (stream brace)
(declare (ignore brace))
(literal-hash-table (read-delimited-list #\} stream t )))
(set-macro-character #\{ (function python-dictionary-reader-macro))
(gethash "to" { "for" "four" "to" "two" })
--> "two" ;
T
You could work harder to allow : and , inside {}, but it's not worth
it, they're just noise.
> Remember in thinking through this: Don't fight the syntax! If you try
> to have both python dicts AND python syntax, you'll lose, and you'll
> lose macros and you might as well go back to Python. But you'll know
> that you've learned to think in Lisp when you can see that this, and
> anything else you want, you can have; the only limitation is your
> imagination! A small price to pay, I'd say, for having to say (+ 1 2)
> instead of 1+2....
>
> 'Jeff
>
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
Ari Johnson
With the example of reader macros I gave at
http://devpit.org/wiki/Lisp you can do:
#[key1 "value1" key2 "value2"] to construct,
#100[key1 "value1"] to construct with a specified hash table size, and
[hashtab key1] to retrieve (this is setf-able)
And it's this simple:
(set-dispatch-macro-character #\# #\[
#'(lambda (stream subchar arg)
(declare (ignore subchar))
(let ((list (read-delimited-list #\] stream t))
(keys '())
(values '())
(hashtab (gensym)))
(do ((key list (cddr key))
(value (cdr list) (cddr value)))
((null key))
(when (not (symbolp (car key)))
(error "Keys must be symbols"))
(push (car key) keys)
(push (car value) values))
(setf keys (nreverse keys))
(setf values (nreverse values))
`(let ((,hashtab ,(if arg
`(make-hash-table :test #'equalp :size ,arg)
'(make-hash-table :test #'equalp))))
,@(mapcar #'(lambda (key value)
`(setf (gethash ',key ,hashtab) ,value))
keys
values)
,hashtab))))
(set-macro-character #\[
#'(lambda (stream char)
(declare (ignore char))
(let ((list (read-delimited-list #\] stream t)))
(when (/= (length list) 2)
(error "Invalid number of arguments to []"))
(when (not (symbolp (cadr list)))
(error "Key must be a symbol"))
`(gethash ',(cadr list) ,(car list)))))
(set-macro-character #\] (get-macro-character #\)))
Javier
Neil Toronto ha escrito:
> Ken Tilton wrote:
> > Neil Toronto wrote:
> > > Quick background from the newb:
> >
> > Lousy spelling. Should be "fom the t-r-o-l-l".
> >
> > hth, kenny
>
> Ah, I see. So not only is the syntax hostile, but so is the community.
> Fascinating! I wonder if this is as well-studied as Lisp syntax
> alternatives.
Don't worry too much about Ken hostilities, or you'll learn in the hard
way that it is a waste of time. Just ignore him.
My answer to your question (which might be wrong) is that Lisp syntax
is the way it is because of macros. Try to learn and use macros and
you'll discover that for having a powerfull use of them an infix syntax
is a must, otherwise you are limited to the more simplistic ones of C.
JShr...@gmail.com
aren't excellent but somewhat tangential to what I had in mind. Mark my
words: "Remember in thinking through this: Don't fight the syntax! If
you try to have both python dicts AND python syntax, you'll lose, and
you'll lose macros and you might as well go back to Python."
What you (both) have demonstrated is the power or reader macros in
defining new syntax, but I don't think that new syntax (in the sense of
reader macros) is either necessary nor particularly appropriate in the
context of the present discussion. I had mind mind something at the
same time hack-wise simpler, yet coneptually more complex: Not just
letter one type: {for bar baz frob} -- forget the braces etc. Rather,
what I had in mind (Neil puzzling through himself) was what the central
concept(s) is(are) of dictionaries and how, using standard Lisp macros,
one could get the >concepts<, not just the baces and brackets. Of
course, the concepts are almost already there (as I pointed out) in
Lisp (in the guise of hash tables, mostly), and I don't think that he
wants -- or shouldn't want -- what you have offered, which is the
syntax. Rather, he wants (or should want) hash-tables to be as
convenient as dictionaries. The only things really limiting this in
Lisp are the need to declare them, and the ability to use
comprehensions (i.e., slicing expressions aka comprehensions aka
generators) as the targets of setting operations. (Some would say that
generators are themselves a conceptual advantage of Python, but these
are trivally obtainable using, or if you like, macofying in of Lisp
generators, and there are already lisp packages that do this!)
Neither of these is a huge stumbling block (although the former:
declaration) may cause efficiency problems -- which may be why Lisp
requires this; I'm not sure). And the examples hereabove by Ari and
Pascal contain part of the story, but in reading their code, I would
say to ignore their syntactic offerings and focus on their semantic
offerings, and expand from there. Adding syntax is usually simple (as
demonstrated) but generally a bad idea (as I have previously argued)
because it breaks the model of code as data and v.v.
John Thingstad
>
> You do have that; They are called hash tables and the only differences
> are that you have to declare them before using them, and they have a
> slightly more long-winded syntax than python's. Here's a challenge for
> your first experiment in macros: You want python-style dictionaries. By
> the magic of Lisp syntax and macros, you can in fact, have them!
> Remember in thinking through this: Don't fight the syntax! If you try
> to have both python dicts AND python syntax, you'll lose, and you'll
> lose macros and you might as well go back to Python. But you'll know
> that you've learned to think in Lisp when you can see that this, and
> anything else you want, you can have; the only limitation is your
> imagination! A small price to pay, I'd say, for having to say (+ 1 2)
> instead of 1+2....
>
> 'Jeff
>
This is a library implementingg list comprehentions
not ulike python. Is this what you are missing?
http://user.it.uu.se/~svenolof/Collect/
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Andras Simon
> Here's what's keeping me with Python: my code reads like pseudocode,
> and I love that. When I come back to Python code I haven't seen in
> months, it takes me all of five seconds to grok it again.
>
> So has anyone seen this?
>
> http://www.dwheeler.com/readable/readable-s-expressions.html
>
> Short version: significant whitespace (indentation can replace parens),
> "func(param1 param2)" calls, infix notation (which is good for math
> code), and it still parses regular s-expressions correctly. Because it
> transforms "sweet-expressions" to s-expressions, macros still work.
If readability is your concern, write an s-expr->sweet-expr converter
and define a SLIME command that invokes it. Then, if you have problems
reading a complicated s-expr, you can just press M-s or whatever, and
see it as a sweet-expr.
Andras
JShr...@gmail.com
> not ulike python. Is this what you are missing?
It's not me that's missing it, it's Neil, but, yes, this is exactly
what I was refering to.
Ken Tilton
Javier wrote:
> Neil Toronto ha escrito:
>
>
>>Ken Tilton wrote:
>>
>>>Neil Toronto wrote:
>>>
>>>>Quick background from the newb:
>>>
>>>Lousy spelling. Should be "fom the t-r-o-l-l".
>>>
>>>hth, kenny
>>
>>Ah, I see. So not only is the syntax hostile, but so is the community.
>>Fascinating! I wonder if this is as well-studied as Lisp syntax
>>alternatives.
>
>
> Don't worry too much about Ken hostilities, or you'll learn in the hard
> way that it is a waste of time. Just ignore him.
>
> My answer to your question...
Sucker. :)
kt
Ken Tilton
Pascal Costanza wrote:
> Neil Toronto wrote:
>
>> Pascal Costanza wrote:
>>
>>> Neil Toronto wrote:
>>>
>>>> Here's what's keeping me with Python: my code reads like pseudocode,
>>>> and I love that. When I come back to Python code I haven't seen in
>>>> months, it takes me all of five seconds to grok it again.
>>>
...
> However, the fact that there is a considerable number of people who
> prefer Lisp syntax, even strongly so, shows that it has its merits.
God how I love watching otherwise intelligent people trying to justify a
notation with fifty years of success to a user of (were he honest) three
days.
:)
Did I say "user"? PWUAHAHHAHAHAHHAAH.... I meant self-important
dilettante. "Hey, guys! Just found Lisp! Love it! Here is how we can fix
it...your thoughts?" PWUAUUAUAUAUAHAHAHAHH... I slay myself.
Ken Tilton
Neil Toronto wrote:
> Ken Tilton wrote:
>
>>Neil Toronto wrote:
>>
>>>Quick background from the newb:
>>
>>Lousy spelling. Should be "fom the t-r-o-l-l".
>>
>>hth, kenny
>
>
> Ah, I see. So not only is the syntax hostile, but so is the community.
Sorry. Would you like an upgrade to "self-appointed fool who thinks he
can offer a useful idea to a fifty-year old language after a couple of
days study"? lemme think...
> Fascinating! I wonder if this is as well-studied as Lisp syntax
> alternatives.
Nice call! yes, it is exactly as predictable as your original offer to
fix Lisp. You dorks arrive as reliably and approximately as often and
depressingly as rent checks.
Unfortunately your jumping instantly to an attack on "the community"
indicates you are an old hand at Usenet, which means you also knew you
would be flamed for your original remarks, and this does disqualify you
from the upgrade from troll.
The good news is that Pascal won't pick up on this for a couple of
months. We look forward to your future questions about actually
programming with Lisp...
...PWUUAHAHAHAHAHHAHAHAHHAHAAAHAHAHAHAAA!!!!!!!!!!
kt
Neil Toronto
> Take a look at Dylan:
>
> http://www.opendylan.org/
>
> Vladimir
Thanks for the tip! I'll add that to my short list, which currently
only as Haskell on it. (Haskell isn't dynamically-typed, but *is* very
generic and does type inference. Some of its other features are very
nice as well.) I like Dylan's object-orientedness - and the fact that
it doesn't tie you to it - and its speed and other extensive
capabilities, but it does look a tad wordy.
Neil
Ken Tilton
> capabilities,...
Not to mention the big future for Dylan!
> but it does look a tad wordy.
Oh, you can talk them into a Perl or APL syntax.
hth, kt
Tim X
As someone still on the earlier parts of the lisp learning curve, I
have to agree with Pascal's points. While I did find lisp syntax quite
different initially, I would have to say it is the easiest syntax I've
ever learnt precisely because it is so regular and has fewer
exceptions than any other language I've learnt. I've also found that
because it is so regular, editor support for working with lisp syntax
is more reliable and consistent than any other language syntax support
I've found. When doing C/C++/Java/Perl, I never felt I could rely on
the editor syntax handling and indentation. If I got code from someone
else and needed to re-format it to suit what I was use to, I would
have to do it by hand as automatic formatting was rarely consistent or
match what I liked. With lisp code, I've rarely needed to re-format
the code, but when I have, the results are a lot more predictable and
consistent.
I also wonder if a richer syntax would result in a reduction in the
ability to treat code as data and data as code so easily. Currently,
doing so seems almost trivial in most cases, but I suspect this is
because of the consistency of the syntax and the in-built support for
processing data written in that syntax.
I found a couple of the posts in this thread quite interesting as they
closely mirrored my own experience. In particular, Rob's comments
concerning how despite adding new syntactic features, he has largely
ended up dropping them after a time as they tended to add more
barriers than remove them. It is also interesting to note that a
number of people have mentioned how easy it is to add new syntactic
structure to lisp, but despite this, there hasn't been any additions
that have gained significant appeal by the lisp community - despite
what some may think, I don't think this is because the lisp community
is unable to handle change and is insistant on maintaining the status
quo. There are enough different users in this community to have most
personality types represented, not just those with an extremely
conservative or pureist outlook that don't want change. Lars' comments
that he too found the syntax odd at first, but after a while, he has
no issue with it and has come to like it seems to be very common and
close to my own experience. I also think this is a valid point with
respect to the perceived hostility the OP recieved initially.
Suggestions and claims that lisp syntax is somehow inadequate, clunky
or out of date seem to appear on this group far too regularly and 99%
of the time, they come from new users who really don't have sufficient
experience with the language and its syntax to make an informed
judgement (though I do recognise the argument that sometimes real
innovative ideas or original perspectives can come from those who have
not been indoctrinated with the mainstream beliefs of the community).
The interesting point is that it is extremely rare to see posts from
experienced lispers concerning syntax and suggested improvements and I
doubt this is due simply to lisp dogma.
regards,
Tim
--
tcross (at) rapttech dot com dot au
Tim X
> Javier wrote:
>> Neil Toronto ha escrito:
>>
>>
>>>Ken Tilton wrote:
>>>
>>>>Neil Toronto wrote:
>>>>
>>>>>Quick background from the newb:
>>>>
>>>>Lousy spelling. Should be "fom the t-r-o-l-l".
>>>>
>>>>hth, kenny
>>>
>>>Ah, I see. So not only is the syntax hostile, but so is the community.
>>>Fascinating! I wonder if this is as well-studied as Lisp syntax
>>>alternatives.
>>
>>
>> Don't worry too much about Ken hostilities, or you'll learn in the hard
>> way that it is a waste of time. Just ignore him.
>>
>> My answer to your question...
>
> Sucker. :)
>
Hmmm. Given you have posted to this thread multiple times and have
obviously been reading it, I'm not sure if you should be so smug
regarding who is and is not a sucker! ;-)
Ken Tilton
Tim X wrote:
>>>Don't worry too much about Ken hostilities, or you'll learn in the hard
>>>way that it is a waste of time. Just ignore him.
>>>
>>>My answer to your question...
>>
>>Sucker. :)
>>
>
>
> Hmmm. Given you have posted to this thread multiple times and have
> obviously been reading it, I'm not sure if you should be so smug
> regarding who is and is not a sucker! ;-)
Nonsense! Neil wanted a flamewar and I obliged. Can you believe they
call that hostile?!
Looks like Neil is off to fix Dylan now. I wonder when he will catch up
with Ilias...last sighted deciding the savages of c.l.l were not so bad
after the reception he got trying to fix Ruby. From Matz himself. :)
kenny
John Thingstad
> Nonsense! Neil wanted a flamewar and I obliged. Can you believe they
> call that hostile?!
>
> kenny
>
As usual it is only you who wants a flame-war.
He was just sharing his impressions to see what people thought
as far as I can see.
He dislikes every library inventing it's own syntax because the
nonconformity makes it more difficult to maintain large programs etc.
Actually that is a point.
There's also weak protection from packages like in secret::password etc
which works best if all programmers know what the others are doing.
Lisp is primarily designed for medium size programs say 10 000
to 200 000 line scale. Maintained by a small group of programmes say
at most 8. Lisp is fine, but it is not everyone's cup of tea.
Depends on what you are doing. Also on how well you like the
style.
I do most of my programming in PHP these day's.
The ugly bastard of languages, but it gets the work done
with less hassle for what what I am doing. (Perl isn't much better..)
In fact I use a number of languages even C#.
I couldn't care less if someone is bad-talking a language.
In fact it seems mostly a Lisp thing. Inferiority complex perhaps :)
Stefan Arentz
...
> I couldn't care less if someone is bad-talking a language.
> In fact it seems mostly a Lisp thing. Inferiority complex perhaps :)
I'm not sure if it is an indication but I have found mostly
the old archives of this group ('90s and up) very useful to
learn about Lisp and how people use it.
Unfortunately these days this group is barely about lisp anymore and
almost completely about 'why lisp', 'why not language <x>', 'how to
make money with lisp' or any kind of other 'meta' discussion that is
not about *programming* in lisp.
It probably says a lot about how alive lisp is. Unfortunately.
S.
Stefan Arentz
Oops. Started one more of those 'meta' threads. Sorry :-(
S.
Ken Tilton
John Thingstad wrote:
> On Mon, 25 Sep 2006 13:08:17 +0200, Ken Tilton <kent...@gmail.com> wrote:
>
>> Nonsense! Neil wanted a flamewar and I obliged. Can you believe they
>> call that hostile?!
>>
>> kenny
>>
>
> As usual it is only you who wants a flame-war.
Nonsense. His OP was deliberately and knowingly provocative. His second
immediately attacked the commuity because I ragged on him. He came
looking for a fight, you are just to dim to realize it.
> He was just sharing his impressions to see what people thought
> as far as I can see.
PWUUAHAHAHAHAHAHAAAA>>>>
>
> He dislikes every library inventing it's own syntax because the
> nonconformity makes it more difficult to maintain large programs etc.
> Actually that is a point.
PWUUAHAHAHHAAAAAHAHAHA>>>
> There's also weak protection from packages like in secret::password etc
> which works best if all programmers know what the others are doing.
Stop trying to sound like you know anything.
kt
Ken Tilton
Stefan Arentz wrote:
>
> Unfortunately these days this group is barely about lisp anymore and
> almost completely about 'why lisp', 'why not language <x>', 'how to
> make money with lisp' or any kind of other 'meta' discussion that is
> not about *programming* in lisp.
>
> It probably says a lot about how alive lisp is. Unfortunately.
No, it says a lot about summer. Noobs tend to show up in the fall and
then we talk about Lisp. What you are seeing is that the only idiots
posting now are not actually writing Lisp code, they are just usenet
junkies. I am a rare case of both.
kt
Stefan Arentz
> Stefan Arentz wrote:
>
> > Unfortunately these days this group is barely about lisp anymore and
> > almost completely about 'why lisp', 'why not language <x>', 'how to
> > make money with lisp' or any kind of other 'meta' discussion that is
> > not about *programming* in lisp.
> > It probably says a lot about how alive lisp is. Unfortunately.
>
> No, it says a lot about summer. Noobs tend to show up in the fall and
> then we talk about Lisp. What you are seeing is that the only idiots
> posting now are not actually writing Lisp code, they are just usenet
> junkies. I am a rare case of both.
Dunno .. going back a couple of months in dejanews^H^H^H^H^H^H^H^Hgoogle
doesn't show much difference in the kind of discussions going on here.
S.
Ken Tilton
You mean to July 25th? What part of summer* do you not understand?
:)
kt
* yeah, yeah, yeah, I know. k
John Thingstad
>
> Stop trying to sound like you know anything.
>
> kt
>
Take a sedative!
Javier
Stefan Arentz ha escrito:
I think it is the fault of ken and his partisans. Their innate
hostilities are contagius and can easily contaminate an entire
comunity. It may seem that it is a preposterous idea, but is the
conclusion you arrive if you carefully examine what's happening
globally on cll. In the '90s there were not such a problem (or at least
not so much) because of this. I was not there, but google archives
demonstrate what you say.
Unfortunately, it seems that cll is still the center of the Lisp
comunity, and no much working is being done on moderated forums and
lists.
Ken Tilton
Try #lisp IRC. Please!
They'll love you two over there. Now scat!
Ken Tilton
Javier wrote:
> Unfortunately, it seems that cll is still the center of the Lisp
> comunity,
hahahahaohhohohahhahaha...
> and no much working is being done on moderated forums and
> lists.
PWWUWUAAUAHAHAHAHAHAHHAHAHAHHAAA>...
Be careful for what you wish. Do you think an article from a clown with
three weeks (days?) experience suggesting Lisp "fix" that nutty sexpr
syntax would be accepted on a moderated forum? Youse clowns are the only
ones I rag on. And Pascal. :)
hth, kenny
Neil Toronto
> John Thingstad wrote:
> > On Mon, 25 Sep 2006 13:08:17 +0200, Ken Tilton <kent...@gmail.com> wrote:
> >
> >> Nonsense! Neil wanted a flamewar and I obliged. Can you believe they
> >> call that hostile?!
> >>
> >> kenny
> >>
> >
> > As usual it is only you who wants a flame-war.
>
> Nonsense. His OP was deliberately and knowingly provocative. His second
> immediately attacked the commuity because I ragged on him. He came
> looking for a fight, you are just to dim to realize it.
It's only provacative if you've got some kind of superiority /
inferiority complex. I asked specifically about a reader that allows
syntactic whitespace and provides some other goodies, which seemed to
be more well-thought-out than the typical attempts to change Lisp
syntax. If you actually read the document at the link I provided,
you'll find that it was developed by a language buff with many years of
Lisp experience, who considers every issue thoroughly.
My second "attack" was an attempt to shame you into decent behavior. I
wouldn't have tried that had I known your style.
> > He was just sharing his impressions to see what people thought
> > as far as I can see.
>
> PWUUAHAHAHAHAHAHAAAA>>>>
GP is correct.
> > He dislikes every library inventing it's own syntax because the
> > nonconformity makes it more difficult to maintain large programs etc.
> > Actually that is a point.
>
> PWUUAHAHAHHAAAAAHAHAHA>>>
Again, GP is correct, though I put special emphasis on being able to
maintain my own programs sporadically over the course of a few years,
which is often what CS research entails.
Neil
Neil Toronto
> Neil Toronto wrote:
> > only as Haskell on it. (Haskell isn't dynamically-typed, but *is* very
> > generic and does type inference. Some of its other features are very
> > nice as well.) I like Dylan's object-orientedness - and the fact that
> > it doesn't tie you to it - and its speed and other extensive
> > capabilities,...
>
> Not to mention the big future for Dylan!
Almost indigestible levels of snark aside, you've got a point. I've
mostly stopped looking into it, since it seems it's not yet mature
enough to let me just *use* it without having to tinker the heck out of
it. I'd do it if I had the time, but I don't.
Neil
Ken Tilton
Neil Toronto wrote:
> Ken Tilton wrote:
>
>>John Thingstad wrote:
>>
>>>On Mon, 25 Sep 2006 13:08:17 +0200, Ken Tilton <kent...@gmail.com> wrote:
>>>
>>>
>>>>Nonsense! Neil wanted a flamewar and I obliged. Can you believe they
>>>>call that hostile?!
>>>>
>>>>kenny
>>>>
>>>
>>>As usual it is only you who wants a flame-war.
>>
>>Nonsense. His OP was deliberately and knowingly provocative. His second
>>immediately attacked the commuity because I ragged on him. He came
>>looking for a fight, you are just to dim to realize it.
>
>
> It's only provacative if you've got some kind of superiority /
> inferiority complex. I asked specifically about a reader that allows
> syntactic whitespace and provides some other goodies, which seemed to
> be more well-thought-out than the typical attempts to change Lisp
> syntax. If you actually read the document at the link I provided,
Yeah, I did. The guy looks to be a bit of a blowhard. Sound of his own
voice and all that. No wonder he sings bass, he likes to go
boomity-boom. Your kinda guy.
> you'll find that it was developed by a language buff with many years of
> Lisp experience, who considers every issue thoroughly.
No, the hand-waving about the windowwashers not being able to read his
code was pretty pathetic, tho clearly good enough to cause you to come
crashing in here as the Lisp Fixer of the Month. We /do/ get one of you
lisp-fixing, community-slamming saviors once a month, you know... oh,
you wouldn't know that, you found Lisp last week. <sigh>
>
> My second "attack" was an attempt to shame you into decent behavior.
yeah, that usually works on Usenet. Not. And you know it, so cut the crap.
So how have the Dylan people reacted to your efforts to get them to
tighten up the verbosity?
kenny
ps. exactly how many lines of Lisp have you written since stopping in to
save us? ever? ____ thx, that's what I thought. kt
pps. Go check my posts on c.l.tcl if you want to learn how to approach
a new community. It is called "groveling". k
ppps. You just reminded me of the student who tried arguing with my tai
chi teacher on his first day. "Maybe I am wrong," my teacher said. :) k
Ken Tilton
Neil Toronto wrote:
>>>He was just sharing his impressions to see what people thought
>>>as far as I can see.
>>
>>PWUUAHAHAHAHAHAHAAAA>>>>
>
>
> GP is correct.
GP is always correct, but he did not author that quote.
>
>
>>>He dislikes every library inventing it's own syntax because the
>>>nonconformity makes it more difficult to maintain large programs etc.
>>>Actually that is a point.
>>
>>PWUUAHAHAHHAAAAAHAHAHA>>>
>
>
> Again, GP is correct,
Or that one. I think you have a parenthesis mismatch somewhere.
Shouldn't you be on comp.lang.dylan?
kenny
Ken Tilton
Neil Toronto wrote:
> Ken Tilton wrote:
>
>>Neil Toronto wrote:
>>
>>>Thanks for the tip! I'll add that to my short list, which currently
>>>only as Haskell on it. (Haskell isn't dynamically-typed, but *is* very
>>>generic and does type inference. Some of its other features are very
>>>nice as well.) I like Dylan's object-orientedness - and the fact that
>>>it doesn't tie you to it - and its speed and other extensive
>>>capabilities,...
>>
>>Not to mention the big future for Dylan!
>
>
> Almost indigestible levels of snark aside, ...
Me, I am wondering when we might hear "yeah, I guess my entry was not
too shabby as bulls in china shops go" ... but, no, it's all kenny's
fault. whatever I can do to help.
> ...you've got a point. I've
> mostly stopped looking into it, since it seems it's not yet mature
> enough to let me just *use* it without having to tinker the heck out of
> it. I'd do it if I had the time, but I don't.
Mature languages with fifty years of polish are nice, right? (aw, jeez,
we're stuck with the guy.)
meanwhile I am happily over in my lisp editor gleefully cutting,
pasting, and copying semantically relevant wodges of code with
double-clicks and control clicks, possible only because of... oh, never
mind.
welcome to lisp.
kenny
Fred Gilham
Imagine a guy walks up to a bunch of acquaintances in a bar. "What
are you drinking?" he asks.
"Guinness," they reply.
"Hey bartender, gimme a Guinness. [Takes a sip] Hey, this stuff is
awful. It's so bitter. Don't you guys know this stuff is terrible?
You should try Miller Light."
One of them says, "Bartender, give this guy a Miller Light, please."
The guy says, "That's more like it. [Takes a sip] Hey, this stuff
doesn't have any taste...."
I had something like this happen to me a couple months ago (actually I
was the Guinness drinker and my friends asked me for a sip, said it
was terrible, then tried to drink their own beers. The universal
reaction was to ask where the flavor in their beers had gone.)
The relevance to Lisp should be obvious.
--
Fred Gilham gil...@csl.sri.com
Do remember you're there to fuddle him. From the way some of you
young fiends talk, anyone would suppose it was our job to teach!
-- The Screwtape Letters, C. S. Lewis
Neil Toronto
last time, then I'm out of the thread for good, so everyone please pay
attention. Ken, try not to let your prior assumptions overwhelm my
stated intentions, okay?
Ken Tilton wrote:
> Neil Toronto wrote:
> > It's only provacative if you've got some kind of superiority /
> > inferiority complex. I asked specifically about a reader that allows
> > syntactic whitespace and provides some other goodies, which seemed to
> > be more well-thought-out than the typical attempts to change Lisp
> > syntax. If you actually read the document at the link I provided,
>
> Yeah, I did. The guy looks to be a bit of a blowhard. Sound of his own
> voice and all that. No wonder he sings bass, he likes to go
> boomity-boom. Your kinda guy.
Try to judge his idea on its merits rather than as a perceived attack.
> > you'll find that it was developed by a language buff with many years of
> > Lisp experience, who considers every issue thoroughly.
>
> No, the hand-waving about the windowwashers not being able to read his
> code was pretty pathetic, tho clearly good enough to cause you to come
> crashing in here as the Lisp Fixer of the Month.
A wonderful demonstration of selection bias.
> We /do/ get one of you
> lisp-fixing, community-slamming saviors once a month, you know... oh,
> you wouldn't know that, you found Lisp last week. <sigh>
Misrepresentations.
I already clarified my intentions behind that "community slam."
I never said I wanted to change Lisp. (If you think I did, show me
where I said, "Hey, why don't all you people do this instead?") I
pointed out problems *I* have with the syntax, pointed at a possible
solution, and asked what people thought. The basic idea would be that I
would implement Wheeler's reader in some flavor of Lisp and use it to
code. I wanted to see what I'd come up against, problems I'd have,
things Wheeler didn't think of, etc.
Also, I wanted to know how well-regarded such an approach would be with
the community - you know, if I posted code using "sweet-expressions"
rather than s-expressions. Well, looks like I know, don't I? I'd get
this:
1) You're a troll.
2) Why are you using that? Just spend a month getting used to
s-expressions.
3) Why aren't you using Dylan instead? (not that I'd particularly mind
this one)
... all of which would devolve into discussing something other than
what I posted.
> So how have the Dylan people reacted to your efforts to get them to
> tighten up the verbosity?
I honestly haven't asked them, and I never would. Likewise, I haven't
asked any Haskell people about providing more conventional syntax for
defining new types, or for shortcut syntax to do certain kinds of
polymorphism.
Recall that I haven't actually asked the Lisp community to change their
language.
> [snip]
>
> ppps. You just reminded me of the student who tried arguing with my tai
> chi teacher on his first day. "Maybe I am wrong," my teacher said. :) k
Funny. You don't remind me whatsoever of that teacher.
Neil
Pascal Costanza
> Since Ken insists on misrepresenting me, I'll defend myself.
That will probably not pay off.
> I pointed out problems *I* have with the syntax, pointed at a possible
> solution, and asked what people thought. The basic idea would be that I
> would implement Wheeler's reader in some flavor of Lisp and use it to
> code. I wanted to see what I'd come up against, problems I'd have,
> things Wheeler didn't think of, etc.
>
> Also, I wanted to know how well-regarded such an approach would be with
> the community - you know, if I posted code using "sweet-expressions"
> rather than s-expressions. Well, looks like I know, don't I? I'd get
> this:
>
> 1) You're a troll.
>
> 2) Why are you using that? Just spend a month getting used to
> s-expressions.
>
> 3) Why aren't you using Dylan instead? (not that I'd particularly mind
> this one)
>
> ... all of which would devolve into discussing something other than
> what I posted.
Except for 1), that's actually not the case. It's indeed the case that
2) is probably the most valid answer.
Here's a quote from "The Evolution of Lisp" by Guy Steele and Richard
Gabriel:
"In a culture where the ability to manipulate representations of
programs is a central paradigm, a notation that distances the appearance
of a program from the appearance of its representation as data is not
likely to be warmly received (and this was, and is, one of the principal
objections to the inclusion of loop in Common Lisp).
On the other hand, precisely because Lisp makes it easy to play with
program representations, it is always easy for the novice to experiment
with alternative notations. Therefore we expect future generations of
Lisp programmers to continue to reinvent Algol-style syntax for Lisp,
over and over and over again, and we are equally confident that they
will continue, after an initial period of infatuation, to reject it.
(Perhaps this process should be regarded as a rite of passage for Lisp
hackers.)"
This paper is from 1992, and it shows that this kind of suggestion was
already regarded as a not very original one back then. So your idea is
by far not very new and has been thought of a countless number of times.
Even John McCarthy himself considered s-expression to be a temporary
solution and had a more mathematical notation in mind, but was
"overruled" by hackers who actually started to appreciate coding
directly in s-expressions.
But go ahead, and you'll see yourself.
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/
Ken Tilton
Neil Toronto wrote:
> Since Ken insists on misrepresenting me, I'll defend myself. It's my
>>ppps. You just reminded me of the student who tried arguing with my tai
>>chi teacher on his first day. "Maybe I am wrong," my teacher said. :) k
>
>
> Funny. You don't remind me whatsoever of that teacher.
Of course not, he is trying to build up enrollment so he can feed his
family. I am hoping you go away so I can keep Lisp to myself. Plus I
have been assigned to drive you away from Lisp and if I fail I have to
help noobs who modify quoted lists for the next three months.
hth, kenny
Espen Vestre
> Of course not, he is trying to build up enrollment so he can feed his
> family. I am hoping you go away so I can keep Lisp to myself. Plus I
> have been assigned to drive you away from Lisp and if I fail I have to
> help noobs who modify quoted lists for the next three months.
IMHO the latter seems much more rewarding!
--
(espen)
Ken Tilton
No, this time Demon Kenny def saved the NG from weeks of tedious parens
debate with an utter knownothing. His last remarks were:
>
> Try to judge his idea on its merits rather than as a perceived attack.
>
Even though others took him seriously and spelled it out for the dork,
he still does not realize that we knowledgably and accurately know
parens to be a feature, not a bug. He thinks we are clinging to them out
of knee-jerk defensiveness and insecurity.
Q-frickin-ED
John Thingstad
>
> Even though others took him seriously and spelled it out for the dork,
> he still does not realize that we knowledgably and accurately know
> parens to be a feature, not a bug. He thinks we are clinging to them out
> of knee-jerk defensiveness and insecurity.
>
Of cource if he reads and does the examples in On Lisp (Paul Graham)
he will figure out why the parethesis are a good idea.
It is the simplest way to express a semantic tree and makes for
the simplest syntax to manipulate.
Telling him he is a jerk or that I am ignorant achieves nothing.
Javier
> Telling him he is a jerk or that I am ignorant achieves nothing.
He achieves that we, again, fail into his trap.
He is an interesting troll. Has managed to survive for years here. From
time to time he write up some code and read up some papers (he likes
lisp after all), and uses that excuse for continuing his trolling
adventure. He is doing well his work; just look at how much
destructively and violent cll is becoming sometimes (and he is always
in the middle).
(Elsewhere we've got the power to stop this if just decide to ignore
him. Yes, I know it is very difficult not to answer him... he is so
good using sarcasm that can violent anybody.)
Thomas Lindgren
> John Thingstad ha escrito:
>
> > Telling him he is a jerk or that I am ignorant achieves nothing.
>
> He achieves that we, again, fail into his trap.
> He is an interesting troll. Has managed to survive for years here. From
> time to time he write up some code and read up some papers (he likes
> lisp after all), and uses that excuse for continuing his trolling
> adventure. He is doing well his work; just look at how much
> destructively and violent cll is becoming sometimes (and he is always
> in the middle).
Actually, I think Kenny did a great job at rallying comp.lang.lisp
when things seemed pretty dismal some years ago, and for that he
should have credit. As for "destructiveness", I'd rate him at a mere
0.1N (Naggum), which I find quite tolerable.
Just think of it as basketball court trash talk, let it wash over you,
feel the zen, move on :-)
Best,
Thomas
--
Thomas Lindgren
"Ever tried. Ever failed. No matter. Try again. Fail again. Fail better."
Javier
> Actually, I think Kenny did a great job at rallying comp.lang.lisp
> when things seemed pretty dismal some years ago, and for that he
> should have credit. As for "destructiveness", I'd rate him at a mere
> 0.1N (Naggum), which I find quite tolerable.
You say this because you are finally used to him. Not everybody has
that capacity.
You miss the point that newbies of today are the comunity of tomorrow,
and Ken is doing a skinny favor to them. But he doesn't mind. He
prefers to continue feeding his ego (as any troll pretends).
Just take the example of the OP. I don't think he would be interested
in destructively attack lispers, but instead to talk with experts about
his impressions of Lisp. The mere act of commenting those things here
demonstrate that, somewhat, he is pretending to convince himself
towards Lisp, or at least let the door open for the future. If he
recieve correct responses, he can reconsider his impressions. If he is
attacked, he would probably go away for ever.
jayessay
> Thomas Lindgren ha escrito:
>
> > Actually, I think Kenny did a great job at rallying comp.lang.lisp
> > when things seemed pretty dismal some years ago, and for that he
> > should have credit. As for "destructiveness", I'd rate him at a mere
> > 0.1N (Naggum), which I find quite tolerable.
>
> You say this because you are finally used to him.
Speaking for myself, I will say your assessment is just plain wrong.
I find KT more than "tolerable" - he's one of the few people worth
reading. Here's the thing:
* KT actually contributes real information (at least from time to
time)
* when he does, he usually knows what he's talking about
* when he doesn't, he still at least offers comic relief and good
humor.
OTOH, what are you and other "Toronto" types offering?
* You can't contribute real information because you don't know any
* From the evidence, you typically don't know what you are talking
about and yet say it in a manner that reeks arrogance
* Despite this, you feel that you and/or your views should be afforded
the same footing as, say, a KT (or maybe even a JM or KP). Why?
The appearance is that of pure narcissism.
Also, please note, that you and your type don't speak for every
"newbie" that comes through here. Basically it is only the arrogant
and ignorant that get the flamethrower treatment.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Javier
> * when he doesn't, he still at least offers comic relief and good
> humor.
You call humor to sarcasm, provocation, egocentrism, false believes...
You must be a direct descendant of Hittler of something like that...
> OTOH, what are you and other "Toronto" types offering?
I fall into the trap again. Time for EOT.
Frank Goenninger DG1SBG
> jayessay ha escrito:
>
>> * when he doesn't, he still at least offers comic relief and good
>> humor.
>
> You call humor to sarcasm, provocation, egocentrism, false believes...
> You must be a direct descendant of Hittler of something like that...
Yeah. Now you did it. Killfiled - congratulations.
Oh, btw the guy you are referring is named "Hitler". I do correct you
here so you can actually learn about him - it might help prevent you
comparing someone like Kenny to Hitler in the future.
>
>> OTOH, what are you and other "Toronto" types offering?
>
> I fall into the trap again. Time for EOT.
Hm - here you are saying you are incapable of learning from
failures. A characteristics above said person had, too ...
I felt a strong need to use strong wording here. Please:
Learn - think - evaluate - think - check - think - and then post
here.
Frank
Javier
Frank Goenninger DG1SBG ha escrito:
> Learn - think - evaluate - think - check - think - and then post
> here.
Right, I'll trye.
Ok, this is really my EOT (hope so!). This is the trap I'm refering:
"troll v.,n. To utter a posting on Usenet designed to attract
predictable
responses or flames. Derives from the phrase "trolling for newbies";
which
in turn comes from mainstream "trolling";, a style of fishing in which
one
trails bait through a likely spot hoping for a bite. The
well-constructed
troll is a post that induces lots of newbies and flamers to make
themselves
look even more clueless than they already do, while subtly conveying to
the
more savvy and experienced that it is in fact a deliberate troll. If
you
don't fall for the joke, you get to be in on it."
And from the expert (which I think Ken sympatices with):
I have been more and more viewing things from a Artificial Life dynamic
system point of view. Ignoring trolls is indeed a above-average advice,
because it is a form of education, of the probable theorization of how
troll operates. However, it is a bit valueless if one do not understand
the core of the problem, or never took time to think and analyze the
complete picture. There are indeed many perspectives and questions to
be asked on the subject of troll. For example, why do trolls troll?
What is their ilk, if any? What caused their disposition? Apparently a
simple first question like this already calls for researches that
likely no sociologist has undertook. Immediately the question begs how
do we define a "troll". As with "intelligence", i'm sure it is
elusive. Of the liberally or literally endowed, one can probe on the
writing styles of good trolls, such as mine. Now, have you observed,
that certain trolls tend to exhibit phantasmagoric reconditeness in
their produce? Say, the Erik Naggum fellow, who has i'm sure in various
times been labeled a troll, and a big monstrous one at that. As you can
see, a clear definition of troll now becomes painfully necessary. Just
exactly who is troll and who is not? Is it by intent or by result?
http://xahlee.org/UnixResource_dir/writ/troll_ignorance.html
Rahul Jain
> I think it is the fault of ken and his partisans. Their innate
> hostilities are contagius and can easily contaminate an entire
> comunity.
I didn't realize Kenny worked for a major Norwegian telco. ;)
(c.l.l inside joke)
HAHAHAHAHAHAHAHAHAH!
How ironic.
--
Rahul Jain
rj...@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Nicolay Giraldo
> Neil Toronto wrote:
>
> Lousy spelling. Should be "fom the t-r-o-l-l".
>
I don't see how somebody who just has not grokked s-expressions is a
troll. He has to learn to grok s-expressions, but you have to learn to
grok humans.
hth, me
Nicolay Giraldo
Normal s-expressions are more than sweet enough. When I read the
subject of your post, I though it was about very nice, normal
s-expressions. What you learn in lisp is not easy to forget, including
the syntax. After a while (at least to me) it is easier to read than
most, including C++ and its family. Well may be not, as I have C++
syntax hardwired in my brain after many years (and I still like C++
more than, say, Java). But Lisp syntax is pretty easy.
When trying to teach Lisp, I have found two groups of people that grok
Lisp faster, much faster than any other programming language they have
to learn:
- Children
- Math and physics undergraduate students
To me that's just a sign of the really simple and useful syntax of
Lisp, as children are always right about learning new stuff. What it
means is that when you have Lisp syntax hardwired in your brain, it's
faster to grok than any other syntax in any other language.
And the group that seems to never, ever get Lisp until they need its
power and meanwhile only bitch about the parenthesis (including me a
while ago):
- Information Technology undergraduate students
Because of my 10+ years experience doing C++ programming, that insight
about the simplicity of Lisp is far from obvious. I needed to interact
with other people to understand that, I would never have got it just by
myself. And the fact that when you only know one language you very
probably wish all others had the syntax of the one you know (that's
just code reuse, meatware instead of software, very logical isn't?).
When you know both syntaxes do you ever get confused between them ??
No, I has not happened to me. Ever.
Ken Tilton
Bullsh*t. When I taught eighth grade in a former life, a new student to
the school stopped by on my prep period and started talking about how
unfriendly the students were. Seems she had been talking about how much
better her old school was. I clued her in that, true or not, it was a
great way to piss off her new classmates. She said, Oh, OK and soon
enough had fit right in.
Her excuse was being thirteen, what's yours?
kenny (praying to god I do not have to explain the parallel with the OP)
Alain Picard
> It probably says a lot about how alive lisp is. Unfortunately.
No, it just says that Erik has left us for good. :-(
Rahul Jain
You have to learn how to grok English. He _refuses_ to grok sexprs. That
was the whole point of the post. He knows what they are but doesn't want
their benefits. If that's the case, he has no reason to be coding in
Lisp. He'd be happier in Dylan, at least.
Nicolay Giraldo
> was the whole point of the post. He knows what they are but doesn't want
> their benefits. If that's the case, he has no reason to be coding in
> Lisp. He'd be happier in Dylan, at least.
That doesn't seems to be the case, at least to me. He just has not
enough experience using s-expressions.
It's related to the Aha! moments. He should get one big Aha! moment
when he gets macros, and then he will grok (not simply understand
superficially) s-expressions.
When reading stranger in a strange land, 'grok' appeared to me not
simply as understanding, not something purely intelectual but as the
profound enlightment that you get when you master something. One can't
grok something at the first attempt, unless one is a genius. Or the boy
from Mars.
For me, I will just assume that the 's' in s-expressions already stands
for sweet. :D
Rahul Jain
>> You have to learn how to grok English. He _refuses_ to grok sexprs. That
>> was the whole point of the post. He knows what they are but doesn't want
>> their benefits. If that's the case, he has no reason to be coding in
>> Lisp. He'd be happier in Dylan, at least.
>
> That doesn't seems to be the case, at least to me. He just has not
> enough experience using s-expressions.
From what I've gathered, he's been using them for decades...
> It's related to the Aha! moments. He should get one big Aha! moment
> when he gets macros, and then he will grok (not simply understand
> superficially) s-expressions.
... and still hasn't had an Aha! moment.
> When reading stranger in a strange land, 'grok' appeared to me not
> simply as understanding, not something purely intelectual but as the
> profound enlightment that you get when you master something. One can't
> grok something at the first attempt, unless one is a genius. Or the boy
> from Mars.
Yes, that's exactly how I interpreted your statement. I grok "grok". :)
> For me, I will just assume that the 's' in s-expressions already stands
> for sweet. :D
We definitely agree on that point!