
Not Lisp again (2009) - solidsalvia
https://funcall.blogspot.com/2009/03/not-lisp-again.html
======
kkylin
The real power of this isn't just differentiating a given function; as others
have pointed out, you can do this in, e.g., C with function pointers. Having
first-class procedures _and_ closures means you can actually return the
derivative as a function. This lets you do things that the simple example
doesn't show. For a physics example, see
[https://mitpress.mit.edu/sites/default/files/titles/content/...](https://mitpress.mit.edu/sites/default/files/titles/content/sicm/book-
Z-H-37.html#%_sec_Temp_235) : given a Hamiltonian (generalized energy)
describing a mechanical system, you can automatically construct a function
that computes the associated Hamiltonian vector field. Pass the vector field
and an initial condition into a numerical integrator, and out pops the
trajectory.

~~~
kkylin
To clarify, the relevance is that deriving the vector field from the
Hamiltonian requires taking partial derivatives; see the linked section from
Structure and Interpretation of Classical Mechanics (SICM) by Sussman and
Wisdom w/ Mayer. Closures lets one do this by composing functions in a way
that mirrors the mathematical structure. Note in the SICM implementation, the
partial derivatives are computed exactly, not numerically, but the resulting
ODEs are integrated numerically.

------
pmoriarty
The objections the author had way back in the day are no longer the objections
programmers of mainstream languages have to Lisp today.

Today the objections I hear are more along the lines of:

1 - All those parenthesis. (Still a top objection)

2 - Lisp doesn't look like or work like what I'm used to.

3 - Lisp doesn't have as many libraries as the most popular mainstream
programming languages.

4 - There aren't nearly as many Lisp programmers, so it'll be hard to find
more to join your project/company if you use Lisp.

5 - There aren't nearly as many Lisp jobs, so why bother learning Lisp if
you're going to have a hard time finding work using it?

6 - Lisp is ancient, and anything that old is useless and primitive compared
to new and shiny languages.

~~~
hasenj
_My_ main objection to lisp is that it's confusing.

I don't mean the syntax is hard to grasp. I mean the way it looks. It becomes
very confusing when the program grows in size.

This is not unique to Lisp. It applies to all dynamic languages that don't
have strong tooling support (IDE's with intellisense).

(Maybe I am wrong about Lisp being dynamic; my only experience has been with
"arc"; and I have had someone tell me before that common-lisp has static
types)

I used to be happy about programming python and javascript in a plain text
editor (vim).

However, as I was doing my first intermediate size project, I realized that
I've hit a limit.

My project was in Javascript (frontend) and I couldn't keep track of what was
going on anymore. Each unit of code is understandable on its own but the whole
thing is a mess to look at. When I need to change the inputs or outputs of a
function, I have no idea if I've done it correctly or not; due to the lack of
type checking.

I absolutely _need_ to make sense of what is what. Having everything look the
same makes me confused. And I've come to realize that tooling support is of
the utmost importance. Having an editor like vim with cool tricks is nice, but
what I really need is to "rename variable" or "rename function" automatically
across all usages in the project.

~~~
dorfsmay
They are IDEs, and if you think about it for a minute, Lisp languages have to
be the easyest to implement IDEs for, as their syntax is exactly the AST and
easy to parse.

~~~
dualogy
> _if you think about it for a minute, Lisp languages have to be the easyest
> to implement IDEs for, as their syntax is exactly the AST and easy to parse_

I wouldn't think the _parsing stage_ has ever been the top bottleneck or chief
complexity/complication for IDE/tooling developers..

------
hprotagonist
Weird lineage-jumping: Bill Siebert, in his other career as a hearing
researcher, is my academic grandfather.

His textbook on signals and systems is one of the two classics in the field --
i wonder, now, how much commonality there is between that and his LISP
experience.

------
_ph_
I was similarly impressed when reading the first chapter of SICP
([https://mitpress.mit.edu/sicp/](https://mitpress.mit.edu/sicp/)), which
shows the same code examples. In a very few elegant lines, without explaining
much syntax, some very fundamentals of computing are explained. I can only
recommend to read the book, even if "Lisp programmer" is not on the career
plan.

------
gravypod
If you're interested in the math-abilities of LISP you should check out Gerald
Sussman's talk on Flexible Systems [0]. It's THE Sussman doing THE LISP.

[0] - [https://vimeo.com/151465912](https://vimeo.com/151465912)

------
phailhaus
I'm having trouble understanding why the derivative example was so impressive
to the author. Can someone explain? It seems trivial to do in any language
where functions are first class citizens.

~~~
jlongster
This was back in 1983 where most (all?) other languages did not have first-
class procedures. If you can imagine programming without them and then being
exposed to that, it would be a big deal. We take them for granted today.

~~~
AnimalMuppet
Well, in 1992 (IIRC), I did a numerical integration in C. For a "first class
function", it just took a function pointer. That approach would have been
available in C in 1983...

~~~
jlongster
That's not really the same thing at all. What's missing is the ability to
close over values, which is a key part of first-class functions. You could not
re-create the original example in C, which is to return a new function. You'd
have to return some sort of object that keeps a reference to the function
pointer, and provides a special mechanism for calling it, i.e. a poor man's
closure.

~~~
groby_b
Sigh. How soon they forgot. You create a thunk that provides the closure.
Which _used_ to be a common thing to do when you wrote C code.

Note: I'm not saying that C could express closures and first-class function
objects anywhere near as neatly as Lisp. But the idea that only Lisp allowed
you to use them, and C was the land of straightforward procedural code... does
not represent what I saw back then.

Just as you can write FORTRAN code in any language, you can transfer ideas
from other languages to C. What's great about Lisp is that it made the ideas
easily accessible.

~~~
int_19h
There's no way to create a thunk in _portable_ C even today, much less back
then. You had to do some form of machine code generation on the fly, which
instantly limited it to some particular architecture / calling convention at
the very least.

------
TheApexTheater
I have to admit, the slightly misleading title got me. I'm currently going
through SICP myself (albeit at a snail's pace), but it seems like the
article's author and I both had the same initial objections to LISP, only to
be blown away by its simplicity and expressiveness with a few keywords and
lines of code. I'm still partial to other programming languages, but LISP
holds a special place in my hard drive.

------
Illniyar
a lot of people handwave the parenthesis and prefix notation as something you
get used to, but it really is the thing that I think most people can't get a
handle on.

There's a reason why DSPs and languages that look like a real languages are
sought after - it makes conversion between business logic/requirements to code
easier.

It makes maintenance easier - it's easy to make sure you made the right
changes when the changes to your code looks like the changes to your business
logic.

~~~
gimagon
What's DSP in this context?

~~~
SomeHacker44
I'm guessing he meant DSLs.

------
dang
Previous discussions:

[https://news.ycombinator.com/item?id=5375735](https://news.ycombinator.com/item?id=5375735)

[https://news.ycombinator.com/item?id=504667](https://news.ycombinator.com/item?id=504667)

------
RangerScience
> Slower than assembly? Maybe for table lookups, but who cares about something
> as mundane as that? I want to do magic. If I have to look up something in a
> table, maybe I'll use assembly code.

Best line.

Also, I wonder how Go compares? Can you do basically the exact same things?

------
kyberias
I wanted to try the examples. Installed MIT/GNU Scheme on Windows. It gives me
some heap errors. There's a bug open about this from year 2010. I despise GNU
software.

~~~
a3n
Racket.
[https://en.wikipedia.org/wiki/Racket_(programming_language)](https://en.wikipedia.org/wiki/Racket_\(programming_language\))

------
Nanshan
> An Introduction to Programming in Emacs Lisp > 1 List Processing > To the
> untutored eye, Lisp is a strange programming language. In Lisp code there
> are parentheses everywhere. Some people even claim that the name stands for
> "Lots of Isolated Silly Parentheses". But the claim is unwarranted.

Someone show code in other programming languages want to show Lisp's
parentheses is silly or other languages more elegant.

BUT: I can't find any language can treat __the code is data and the code is
data __AND: I can 't find any except Lisp there is just one syntax ().

------
cygned
Interestingly similar to the beginning of "Structure and interpretation of
computer programs" \- great book, by the way!

~~~
jimbokun
Yes, he is talking about taking the class of the same name, based on the book.

------
taeric
The derivative examples are almost magical to watch. I highly recommend that
section for anyone interested.

------
ASipos
2009 should be added to the title.

~~~
bryanlarsen
Why? It's an article written about an experience in 1983. The article's
publish date is pretty irrelevant.

~~~
taeric
I view the publish date as much to help people know if they had seen it
already.

------
c3534l
Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a
design _feature_. If you're going to sell people on the benefits of functional
programming, I think you should really be pushing more for SML or Haskell or
something like that.

~~~
BoiledCabbage
It's been stated a number of times, but

x.f(y, z) has just as many parens as (f x y z). And Haskell particularly comes
with so many syntax quirks. There is a lot of cruft you need to learn to get
to the underlying functional core of haskell. Lips you can get 100% of the
cruft out within a few days / 1 week. And the rest is just understanding
programming concepts.

I don't use any LISP on a regular basis, but it still amazes me how often
people are willing to dismiss a language based on parens.

It reminds me of a friend who would never try food from any other country
because: _Look at all the weird colors and ingredients. I 'm not trying that._

In the end, no one will ever force anyone to try something - but my view in
life is if everyone raves about something, and my main concern with it is by
(my own admission) superficial. I still go and give it a try.

SICP gives you a new view on programming regardless of whether you ever touch
lisp again or not.

~~~
mnarayan01

      x + y * z
    

has way fewer than

    
    
      (+ x (* y z))
    

though. I'm not arguing for one or the other, but e.g. infix operators do have
upsides.

~~~
thoth
>infix operators do have upsides

What you are also glossing over are the precedence rules for operators. In
this case it works in favor of your point and LISP indeed needs more parens.

However in other situations, you might need to re-parenthesize (language with
flat precedence like APL) or consult your favorite chart[0] in order to figure
out what is going on.

[0]
[http://en.cppreference.com/w/c/language/operator_precedence](http://en.cppreference.com/w/c/language/operator_precedence)

