Lisp is too powerful...

65 views
Skip to first unread message

Jim Powers

unread,
Apr 15, 2013, 4:50:20 PM4/15/13
to li...@lispnyc.org
This is now hot on the interwebz

Since when is too powerful a bad thing? ;-)

--
Jim Powers

puzio1.excite

unread,
Apr 15, 2013, 5:37:44 PM4/15/13
to li...@lispnyc.org
> Since when is too powerful a bad thing? ;-)

When you're too weak to harness it :-o

Making good use of recursion, higher order functions,
and metaprogramming requires quite a sophisticated
ability for abstract logical thought. Until one gets to
that level, formalisms like LISP or Lagrangian mechanics
look like clumsy and convoluted ways to do things.

Jonathan E. Magen

unread,
Apr 15, 2013, 6:51:19 PM4/15/13
to puzio1.excite, li...@lispnyc.org
I think you make an excellent point.

> Until one gets to
> that level, formalisms like LISP or Lagrangian mechanics
> look like clumsy and convoluted ways to do things.

It never ceases to humble me how people can carry on excellent
discussions and debates without understanding much about Lisp or the
way people use it. For example, please take the following SO thread
regarding a proposal to author an OS kernel in Lisp and compile it
with SBCL:

http://stackoverflow.com/questions/1848029/why-not-port-linux-kernel-to-common-lisp

As a side note, I wonder what will happen if the discussions of macros
and quasis in future versions of ECMAScript come to fruition:
http://wiki.ecmascript.org/doku.php?id=harmony:quasis

Would people mount similar objections to similar features? Would they
do it because they really believe such objections or would they
embrace the new features as wonderful until someone points out they
were pioneered in Lisp?

--
Jonathan E. Magen
http://www.yonkeltron.com
GTALK: yonke...@gmail.com
http://twitter.com/yonkeltron
ב"ה

John Cowan

unread,
Apr 15, 2013, 7:45:52 PM4/15/13
to Jim Powers, li...@lispnyc.org
Jim Powers scripsit:

> Since when is too powerful a bad thing? ;-)

When you wish to prove something about it, so as to enable less general
(and faster/smaller) implementation methods to be used. Fully general
Earley parsing is very powerful, but it is also O(N^3). LALR(1) parsing
is linear with a small constant factor; packrat parsing is also linear,
but with a much larger constant factor. If you limit your input
language to something that can be parsed by a LALR(1) parser, you get
a big performance win.

This tradeoff extends well beyond computers. If you want to be able to
transport an object (of reasonable mass) over any terrain, hire a human
being: neither snow nor rain nor darkness of night, etc. But if you can
count on having some sort of roads, a truck will give you greater speed
*and* greater mass, and the better the roads, the better the results.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
One of the oil men in heaven started a rumor of a gusher down in hell. All
the other oil men left in a hurry for hell. As he gets to thinking about
the rumor he had started he says to himself there might be something in
it after all. So he leaves for hell in a hurry. --Carl Sandburg
Reply all
Reply to author
Forward
0 new messages