You already use Lisp syntax

http://blog.danieljanus.pl/blog/2014/05/20/you-already-use-lisp-syntax/

by nathell • 12 years ago

110 109 12 years ago

blog.danieljanus.pl

ben0x539• 12 years ago

hey guys i think haskell is a lisp too

nox_• 12 years ago

Why was this downvoted when it clearly shows how this article is misguided? Just because a language uses parentheses for some of its constructions doesn't mean we can call Lisp syntax.

Dylan16807• 12 years ago

That sure does look like lisp. It also looks like a way I would definitely not use to do arithmetic if I could avoid it.

This is more of a cautionary tale of going too far in making programs do 'one thing' than it is an endorsement of lisp.

robin_reala• 12 years ago

In Fish shell backticks for evaluation are replaced by parentheses. One step closer I guess.

jimktrains2• 12 years ago

$() = `` in bash and zsh too. Bonus that $() can be nested.

lispm14• 12 years ago

Lisp syntax is quite a bit more than prefix operators + postfix arguments.

* s-expressions are a syntax for data

* Lisp syntax is expressed on top of s-expressions, reusing s-expression syntax for data

* Lisp has built-in syntax for several constructs: lambda, let, block, setq, if, ...

Many programming languages have some form of prefix operators.

Btw., some Lisps allow to omit outer parentheses in a Listener (aka REPL):

    CL-USER 30 > delete-file "/Lisp/foo"
    NIL

arethuza2• 12 years ago

Speaking of leaving parentheses out of lisp - you can go the whole way and have a whitespace lisp:

http://draketo.de/light/english/wisp-lisp-indentation-prepro...

lispm14• 12 years ago

Stuff like that exists for decades:

For example RLISP:

    SYMBOLIC PROCEDURE SMEMBER(U,V);
       %determines if S-expression U is a member of V at any level;
       IF U=V THEN T
        ELSE IF ATOM V THEN NIL
        ELSE SMEMBER(U,CAR V) OR SMEMBER(U,CDR V);

Which would be in Lisp:

    (defun smember (u v)
     "determines if S-expression U is a member of V at any level"
      (cond ((equal u v) t)
            ((atom v) nil)
            (t (or (smember u (car v))
                   (smember u (cdr v))))))

RLISP has been developed somewhere in the 60s/70s as a parentheses free notation for Lisp on top of Standard Lisp. Much of the computer algebra system REDUCE is written in RLISP.

taeric• 12 years ago

This is directly addressed in the article. The main point was simply that prefix notation for all things isn't that confusing. In fact, the main place it is somewhat confusing is with the math operators.

basdp• 12 years ago

Well, if you limit yourself enough, almost any language is a 'lisp'. Maybe we should stop calling anything with parentheses a 'lisp'.

pdpi• 12 years ago

Perhaps it's meant as a joke, but "prefix-RPN" grinds my gears. Just call it "Polish Notation", instead of "prefix Reverse Polish Notation".

VLM• 12 years ago

Look on the bright side, when HP48 calculators were more common so RPN was better known, I heard a lot of "Reverse RPN"

Jtsummers• 12 years ago

Some of us just said that as a joke. Like the day we finally thought about the banks telling us to enter our PIN numbers and decided to embrace the redundancy and repetition.

arethuza2• 12 years ago

I once worked on a project where I was writing Lisp, C and PostScript most days - quite an interesting combination.

zokier4• 12 years ago

I though a pipeline would be more idiomatic way of doing this in bash. But my initial attempt resulted quite unreadable mess:

    $ cat <(echo 2) <(cat <(cat <(echo 10) <(echo 4) | +) <(echo 7)| d) | x
    4

Is there any way of making that more readable? My variation of the C utility source code is here: https://gist.github.com/zokier/c55e9c9736009981b494

captainmuon2• 12 years ago

Let the operators take one argument?

    # 2*((10+4)/7)
    $ echo 10 | add 4 | divide-by 7 | times 2
    4

zokier4• 12 years ago

I do like that, it also makes the utility more filter-like. Here is that implemented in C: https://gist.github.com/zokier/6b43032afb248bef68b7

richardwhiuk• 12 years ago

By that argument Objective C is using Lisp syntax [a b:1 c:2].

Besides, if you want to persuade me to use Lisp, then starting by comparing the syntax to the shell is probably a bad idea, as others have said.

spion• 12 years ago

Yup. See http://clochure.org/

davidw• 12 years ago

From that point of view, Tcl is even more lispy.

     set foo [somefun $a $b]

networked• 12 years ago

I recently discovered Tcl and it immediately struck me as a refinement of the "stringly typed" design behind the Unix shell.

I've been wondering if it would be a good idea to try building a modern fish-style [1] shell aimed primarily at interactive use and one-liner expressiveness based on a Tcl interpreter. (I tried eltclsh and it's close but not quite that out of the box.)

[1] http://fishshell.com/

captainmuon2• 12 years ago

Sure, you can write bash like that. Actually, if you shift the parenthesis a bit, you can write almost any language like that:

    (add 4 (mul 2 5))  vs.
    add(4, mul(2, 5))

But that doesn't mean you should write bash like that. In fact, it is (IMO) very bad style to nest $(). When people complain about Lisp syntax, it's only partially about the RPN or the parens, its about the incredible amount of nesting.

Funnily enough, of all things bash offers an alternative paradigm. Instead of nesting, you use filters:

    # pseudocode
    echo 2 | mul 5 | add 4

For example, you can write:

    nerrors=$(mycommand | grep error | sort | uniq | wc -l)

instead of:

    # pseudocode
    nerrors=wc("-l", uniq(sort(grep("error", mycommand))))

I find this paradigm of "do A, then do B, then do C" much easier to think about than the nested "do C on the result of doing B on A". I wish more programming languages would embrace that kind of coding, which is basically functional, but in imperative or data-flow order. You have aspects of that in C# (LINQ), SQL, and some others. I know you can achive something like that in Haskell though Monads and `do`, though it feels a bit bolted on as a concession to having to do imperative stuff in a purely functional language. (And as nice Haskell is, it will probably never have the use base that bash has...)

Jach2• 12 years ago

Indeed having a chain is often nicer than a lot of nested stuff. And when your base language is an abstract syntax tree, it becomes pretty easy to write a macro to let you flatten a lot of things out (among a bunch of other neat things). If your complaint with a lisp is that there's too much nesting, you haven't seen enough lisp. Pretty much every lisp has an infix-math library somewhere, for the popular lisps there's probably at least a dozen, and they usually allow mixing in prefix-math as well because nuts to typing "a + b + c + d + e" when I can just type "(+ a b c d e)" or if I want to call functions anywhere in the middle. There's no reason you couldn't write your example using a threading macro in Clojure, assuming your functions are defined such that they take input explicitly as the last argument instead of reading a common stdin. (Or if they take it as the first argument, you use a different macro but the same syntax.) Your code just becomes

  (->> (command) (grep "error") sort uniq (wc :-l)

Does anyone think (wc :-l (uniq (sort (grep "error" (command))))) is a better option? And instead of typing that out manually, I just used the REPL.

    user=> (use 'clojure.walk)
    nil
    user=> (macroexpand-all '(->> (command) (grep "error") sort uniq (wc :-l)))
    (wc :-l (uniq (sort (grep "error" (command)))))

Even without macros you can still setup nice-looking chaining with generators and coroutines. "Too much nesting" seems like the wrong complaint.

bjourne• 12 years ago

Take a look at factor: http://factorcode.org/ Your example would be written as:

    "C:/tmp/adinst.log" utf16 file-lines [ "SEARCH" swap start ] filter members length

File is opened into a sequence of lines, then the sequence is filtered so that only lines containing "SEARCH" remain, then members removes duplicates, then length gets the number of elements left in the sequence. In the shell, "|" is the function composition operator, in haskell it's "." In Factor, any whitespace is function composition!

zokier4• 12 years ago

You mentioned C#/LINQ, but F# has very nice looking pipeline operator, which does exactly that. Here is a blog post explaining it: http://lorgonblog.wordpress.com/2008/03/30/pipelining-in-f/

notduncansmith• 12 years ago

You might really enjoy Elixir[0], a language that runs on the Erlang VM. They provide (what I find to be) a nice feature called the pipe, which looks like this: |> and works basically like a bash pipe (use the output of A as the input of B).

I've played around with Elixir a bit and while I don't quite have a nail to hit with that particular hammer, it has been really fun and mind-expanding (my first functional language!).

[0] http://elixir-lang.org/

jerf• 12 years ago

"I know you can achive something like that in Haskell though Monads and `do`"

The closer equivalent to UNIX pipelining in Haskell is actually the simple "." operator, function composition. That pipeline would generally look more like

    countLines = wc LineCount

    countLines . uniq . sort . grep "error" $ mycommand

It's not a direct translation, because that is exactly neither legal Haskell (I'm munging program vs. some sort of shell here), nor exactly how you'd really do that in Haskell, however, pipelines of several functions composed together is idiomatic and frequently-used.

"though it feels a bit bolted on as a concession to having to do imperative stuff in a purely functional language"

It really isn't. IO is only one particular monadic thing; check out Parsec for some more fun. It only looks bolted on if you look very superficially, and you darned near have to bring the preconception in the first place to even briefly come to that conclusion. That idea basically comes from the misconception that "Haskell can't do side effects", then "Oh, well, this way of doing side effects must be a bad idea or something"... the first statement is false. Honestly, I miss the way Haskell does IO in other languages far more than I miss the way other languages do IO in Haskell. (To be clear, I do have both feelings, but the former is way more common.)

thinkpad20• 12 years ago

For what it's worth, I often do something like this:

    (!) = flip ($)

Which then allows me to do things like

    mycommand ! grep "error" ! sort ! uniq ! wc lineCount

Which is nice because it visually resembles `|` (which is a reserved symbol in Haskell).

Similarly for fmap:

    (<!>) = flip (<$>)
    result <- get <!> table <!> lookup "foo"
    print result ! liftIO

Or for function composition:

    (~>) = flip (.)
    doStuff = reverse ~> head ~> negate ~> print
    doStuff [1,2,3]

That being said, lisp does seem far more suited to shell programming than Haskell, because every function is variadic. What would probably be nice (and probably has been done) is a Lisp with syntax extended to include a few symbols to allow bash commands like |, >, etc:

    $ def nth-line (n) (read a | head -(n) | tail -n 1)
    $ ssh -i .ssh/some.pem (python show_servers.py | grep 'cool server' | cut -d ' ' 
      -f 3 | nth-line 1)

mcguire5• 12 years ago

"It only looks bolted on if you look very superficially, and you darned near have to bring the preconception in the first place to even briefly come to that conclusion."

...or read any of the older Haskell books and tutorials, which all seemed to start in pure expression-land and attempt to stay there as long as possible (which is good programming style, don't get me wrong; but learning is different). IO and other monadic things are treated like huge and scary monsters that must be left until the very last possible moment, if treated at all, because they're HUGE AND SCARY!!!!1! Aaaaahhhhhh!

dllthomas2• 12 years ago

"Honestly, I miss the way Haskell does IO in other languages far more than I miss the way other languages do IO in Haskell. (To be clear, I do have both feelings, but the former is way more common.)"

Well said - this is very much my experience as well.

Symmetry• 12 years ago

It's way easier than that in Haskell, you just need to do:

  x -: f = f x

and boom, a Unix style pipe.

(Courtesy of Learn You a Haskell, http://learnyouahaskell.com/a-fistful-of-monads, but using no actual monads).

tomp• 12 years ago

Oh god, another barely valid non-argument about the superiority of LISP syntax.

Well, guess what. Function name, followed by arguments, is not LISP, it's Mathematics. `A x` has meant applying a linear transformation to a vector (i.e. matrix multiplication) for a very long time.

Furthermore, saying "it's like LISP but without parenthesis around it" is like saying "it's like Java but without parenthesis around arguments and commas between then" when you actually mean to say "it's just like ML".

Finally, bash has infix operators (like `|` and `;`), which make it infinitely more readable than it would be without them. Really, if we can compare bash with any other programming language, it's ML.

drunken_thor• 12 years ago

whoa settle down, the article wasn't about the superiority of LISP syntax, it was more about how the syntax is not as weird as you might think.

chr1• 12 years ago

The weird thing about Lisp syntax is that people try to find all kinds of justifications why not having infix syntax is ok.

The fact that arithmetic can be written in weird form in other languages too isn't very interesting.

grayclhn• 12 years ago

There's more prefix notation in math than you think:

∑ᵢ xᵢ

∫ x² dx

etc. And `A x` is more likely to be written as `(A x)` than `A(x)` in your example. I don't necessarily agree with the article, though...

sp332• 12 years ago

tomp's point is that "LISP syntax" is actually math syntax. I think you're in violent agreement...

scott_s• 12 years ago

The purpose of this article is try to teach people how to think about Lisp syntax through analogy, not argue that it is a superior syntax.

praptak• 12 years ago

For me there were one and a half tricks to get Lisp syntax.

The first was the mental conversion to/from f(a,b,c) to (f a b c) which is just moving the opening parenthesis one token to the left and seeing both commas and whitespace as "something between the tokens that really matter".

The remaining half was starting with Clojure. It is a Lisp whose constructs are really optimized towards dumping extraneous parentheses so it is easier not to get lost in the nesting levels.

jeremiep• 12 years ago

You also don't need to quote data structures other than the list in Clojure since they evaluate to themselves.

(foo '(1 2 3)) simply becomes (foo [1 2 3])

lispm14• 12 years ago

Just like Common Lisp and Scheme.

Common Lisp:

A vector:

    CL-USER 34 > #(1 2 3)
    #(1 2 3)

A string:

    CL-USER 35 > "1 2 3"
    "1 2 3"

A structure:

    CL-USER 36 > #S(FOO :A 1 :B 2 :C 3)
    #S(FOO :A 1 :B 2 :C 3)

klibertp5• 12 years ago

Oh, but you're wrong I believe. In Clojure, as well as in most other lisps, this:

'(1 2 3)

constructs a value of type list, while this:

[1 2 3]

constructs a value of type vector.

They are not the same and you cannot say that one somehow becomes the other. And from what I remember Clojure does have a list data-type and it still needs to be quoted, except for empty list literal, (), which is self-evaluating.

So, in Clojure you need to quote your lists, exactly like in many other Lisps, and you have literals for other data structures, exactly like in many other Lisps ([] in Elisp, #() in Racket, CL covered by lispm). But of course Clojure is so much more readable because it has so few parentheses in comparison... to Java, I suppose.

brudgers13• 12 years ago

To me, right now, I think the core difference between Clojure and other Lisps is Clojure gets rid of memory management. Yes, other Lisps have automatic deallocation, but the fundamental constructor, `cons`, is a raw memory allocation. It`s `malloc`for linked rather than sequential memory.

Although Clojure still has a `cons` it has been replaced by `seq` as the fundamental abstraction. Clojure takes advantage of being fully managed code and in a sense is as much a Lisp as C# is a C [if we were inclined to think of C as a genre, else Algol?].

It seems this, combined with a formally incorporating a DSL of the kind a experienced Lisper (such as Hickey) might create for writing programs gives Clojure it's syntax: e.g. [x y] is syntactically like a quoted list and writing a macro is the sort of thing hubris drives lazy impatient Lispers to do. In special forms [x y] is like a different more complex macro, but again the sort of thing people would write for themselves. In other Lisps the ad hoc nature of such macros however makes other people's code notoriously hard to follow.

lispm14• 12 years ago

Clojure constructs don't allocate memory - okay...

Although Clojure still has a `cons` it has been replaced by `seq` as the fundamental abstraction.

Common Lisp has lists and sequences as abstractions. But it does not take away the low-level operations.

eudox• 12 years ago

`cons`, is a raw memory allocation. It`s `malloc`for linked rather than sequential memory.
Clojure takes advantage of being fully managed code
writing a macro is the sort of thing hubris drives lazy impatient Lispers to do

The ignorance of Clojure programmers is really incredible.

wes-exp2• 12 years ago

`cons`, is a raw memory allocation. It`s `malloc`for linked rather than sequential memory

Yeah, cons is like malloc, except that the object it creates is automatically memory managed / garbage collected. There is no corresponding "free" call. Actually, that means cons is not like malloc.

Clojure takes advantage of being fully managed code

Do you realize that Lisp uses automatic memory management (just like the JVM or CLR)?

arh684• 12 years ago

Lisp... doesn't really have syntax. S-expressions have syntax: parens, whitespace, symbols, comments. S-expressions are for data. Lisp is a subset of the sexps.

Lisp adds just one rule: a Lisp program is an sexp whose root node is a function symbol.

Naturally, since sexps nest, Lisp programs can nest.

The author demonstrates nested computation with bash's $( .. ) syntax. Lisp, by the nature of the sexps, is nested computations. I think the author almost hits the nail on the head here:

Our two basic rules — program-name-first and $()-for-composition — allowed us to explicitly specify the order of evaluation, so there was no need to do any fancy parsing beyond what the shell already provides.

Sexps provide nesting/composition. Lisp just means program-name-first.

lispm14• 12 years ago

Lisp adds just one rule: a Lisp program is an sexp whose root node is a function symbol.

Now you explain these three examples. All have a symbol at the start of the list.

    * (let foo bar)
    ; in: LET FOO
    ;     (LET FOO
    ;       BAR)
    ; 
    ; caught ERROR:
    ;   Malformed LET bindings: FOO.
    ; 
    ; compilation unit finished
    ;   caught 1 ERROR condition


    * (lambda a b)
    ; in: LAMBDA A
    ;     (LAMBDA A B)
    ; 
    ; caught ERROR:
    ;   The lambda expression has a missing or non-list lambda list:
    ;     (LAMBDA A B)


    * (defun foo (a) (+ a 10) (declare (fixnum a))
    )
    ; in: DEFUN FOO
    ;     (DECLARE (FIXNUM A))
    ; 
    ; caught WARNING:
    ;   There is no function named DECLARE. References to DECLARE in some contexts
    ;   (like starts of blocks) have special meaning, but here it would have to be a
    ;   function, and that shouldn't be right.

Obviously the SYNTAX for LET, LAMBDA, DEFUN, ... is more complex than what you think.

Looks like there is Lisp code where it is not sufficient to have a symbol at the start of an s-expression. There seem to be more constraints to the allowed s-expressions.

For example the syntax for LET is:

    let ({var | (var [init-form])}*) declaration* form*

arh684• 12 years ago

Yeah you're right, it's not turtles/functions all the way down. At some point, your functions are defined in terms of special forms.

Your special forms will either be natively supported or they'll be written with a defmacro in terms of native special forms. The definitions can't be circular, of course: if defmacro was used to define if, then if cannot be used in the definition of defmacro.

So my "rule" isn't really a hard rule. Macros/forms are the exception. But it seems more intuitive for me to think in terms of functions whenever possible, then to bend the rule when macros get involved.

cwp• 12 years ago

Lisp... doesn't really have syntax.

Yes, it really does. Let me finish that chain of reasoning for you:

S-expressions have syntax. Lisp is a subset of the sexps. Therefore, Lisp has syntax. QED

Yes, Lisp has very simple syntax. Yes, it's neat that eval can be implemented in a few dozen lines of Lisp. But as a practical matter Lisp is a programming language like any other. This sort of mysticism does not encourage people to learn Lisp or help the ideas behind Lisp become more mainstream.

AnimalMuppet2• 12 years ago

I believe that arh68's point was that Lisp doesn't have a syntax that is something different than the syntax of S-expressions. You're actually agreeing, but you're quibbling over the way it was stated.

smoyer2• 12 years ago

The filters you specify for LDAP searches were probably inspired by Lisp syntax too:

(&(|(uid=smoyer)(uid=swm))(mail=redacted@gmail.com))

To be honest, I'm not sure why the test expressions are infix while the logical operators are prefix. My guess is that it allows a filter to be specified without whitespace.

zokier4• 12 years ago

Wouldn't it be whitespace-free with prefix test expressions too?

    (&(|(=(uid)(smoyer))(=(uid)(swm)))(=(mail)(redacted@gmail.com)))

smoyer2• 12 years ago

Wow ... I hadn't pictured it with parenthesis but you're right! I still don't know why the tests were infix then ;)

kermitdance• 12 years ago

I prefer comparisons of XML and LISP syntax to counter people complaining about the latter, while happily applying the former to pretty much everything under the Sun (application configuration, data exchange, dependency mgmt, build mgmt, scripting...) I'm not saying LISP is good and XML is bad; but I've seen some baffled faces when pointing out the similarities.

jlas• 12 years ago

This is silly, sh/bash natively support arithmetic operations with infix notation. He writes a contrived arithmetic solver in C to support his argument.

espadrine• 12 years ago

In Scheme, SRFI 105[1] gives the ability to do math with infix operators. There's no reason you can't have your cake and eat it too!

[1] http://srfi.schemers.org/srfi-105/srfi-105.html

ktg• 12 years ago

L++ is a programming language that transcompiles to C++. It uses Lisp-like syntax. Macros are supported via Racket's macro system define-syntax, define-syntax-rule and defmacro.

L++ | https://bitbucket.org/ktg/l

Monkeyget• 12 years ago

Stopping at the syntax when talking about Lisp is pretty narrow-minded and completely misses what makes Lisp so great. It's like saying to a car driver that motorcycles are nice because they only have two wheels and thus take less parking space. Technically true but not what makes them exciting. When you describe to the coffee-drinking radio-listening commuter about taking corners and being one with the road he won't understand what the point is. But if he were to drive a bike around a circuit, oh boy! I'm probably going to fail miserably but let me attempt to explain cornering and being one with the road in Lisp.

What's so great about Lisp? : its extreme malleability in the way you write code and the data it uses.

Code and data are the exact same things in lisp. They are represented the same way : lists represented with braces around them who can be nested. It's called s-expressions and they are in the form (<operator> <operand1> <operand2> <operand3>). There is no fundamental difference between code and data they are just list represented as s-expressions:

  (list 1 (list 2 3))
  (+ 1 (+ 2 3))

Another example :

  (task 
    (time 14 00)
    (log "beginning of task")
    (job (backup-files (important-files-in (list-files))))
    (job (delete (list-files))))

Quick, what's that above, code or data? How about both?

The one nice thing about s-expressions (sexp) instead of classical curly braces is that the code written in sexp IS ITSELF the abstract syntax tree of that code.

For example, think of a function function add(a, b){return a+b;}

You could convert this function into its syntax tree like this :

  (define-function (name add) (parameters a b)
  (body (return (+ a b))))

If we simplify things a bit we end up with :

  (defun add (a b)
    (+ a b))

Lo and behold, the example above IS Lisp code. Is that code or data? How about both?

The syntax of Lisp is the same as its internal represention. That's called homoiconicity.

What's so great about that? Well, mix that with macros whose language is Lisp itself and can do anything with s-expressions and you end up wielding great powers.

A simple example. Let's go back to our task example. We can treat it as data :

  //not actual lisp code but you get the point
  var my-task = (task 
    (time 14 00)
    (log "beginning of" )
    (job (backup-files (important-files-in (list-files))))
    (job (delete (list-files))))

my-task is now a list containing sub lists representing a task. What if we did this now :

  //not actual lisp code
  (defun time (hour minutes) (print "%d:%d" hour minutes))
  (defun log (string) (print string))
  //we say that task is a function
  //that should call each list it contains as a function
  (defun task () /*execute each list it contains*/) 
  //...

Now we can just do:

  (my-task)

What do you think is going to happen? Yes, the data, the task is being executed.

Now for the last touch : add to Lisp a powerful macro system that can take any s-expression (any list) and transform it any way it see fits and you end up yielding great power. What's that language? It's Lisp itself. Code is data. Lisp code evaluting other lisp code. I am so enlightened.

Not enlightened? Didn't get anything out of my post? Then give Lisp a try! You have to dive into Lisp to be able to get it. As Eric raymond put it : "Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot." - ESR

evanspa• 12 years ago

Nice comment. Very reminiscent of PG's "Beating the Averages" essay:

http://www.paulgraham.com/avg.html

Paul's essay was the catalyst that got me to (re-)discover Lisp for myself. Scheme was taught in my CompSci I course a long time ago; but at the time, it was just a weird looking language that I forgot (CS II and beyond was all in C++ at my college).

Denzel• 12 years ago

For the past few months I've been studying Lisp, reading SICP, and just trying to become more familiar with the concepts. Like many people, I was put off by Lisp's seemingly arcane syntax, which now feels beautiful to me. I can't fully explain it, but for years I had been searching for a way to reduce and abstract duplication in the structure of my code. (There's a fundamental difference between this, and simply pulling something out into a function or method.) It wasn't until I came across a great explanation of homoiconicity and macros that I became "enlightened." Lisp was what I was looking for all along.

One day, I tried explaining it to my manager, and he just couldn't get it. It wasn't clicking. Until I showed him a demo of symbolic differentiation (a la SICP), at which point he said, "Holy shit," and sat there for a few minutes considering all the implications. That was one of the greatest moments we ever shared together.

Jach2• 12 years ago

For those who aren't so lucky to have an understanding manager (though you didn't say your manager then agreed to let you start writing everything in a lisp...), I just wanted to bring out the punchline of this hilarious and melancholy comment[1] from a couple months ago: "And yet: the money guys are offering money. Just swallow your pride, play 'Stairway to Heaven' at the wedding, and pretend you've never had crazy eyes when talking about homoiconicity, and the rent will be paid."

[1] Don't upvote me: https://news.ycombinator.com/item?id=7423626

theothermkn• 12 years ago

I don't know if Rich Hickey said it first, but he said it well when he noted that programmers get really upset when the parenthesis is on the left side of the function name, instead of the right side.

DoSomething(an_arg, another_arg);

vs.

(DoSomething an_arg another_arg)

I'm not sure the second is markedly less readable than the first.

You already use Lisp syntax

Related Stories