Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The LISP version can be more readable with (e.g. Clojure’s) threading macros:

    (-> 1
        (- t)
        (* a)
        (+ (* t b)))
Obviously use more or less whitespace to taste.


The Lisp version can also be more readable with a macro (like https://github.com/quil-lang/cmu-infix): #I(a*(1.0-t) + b*t). Or something else that would let you write GP's preferred syntax. One of the things that makes Lisp Lisp is that if the parens are over-cumbersome, you have the tools to take them away. See also CL:LOOP.


This is almost equivalent to my proposed syntax, just replace `->` with commas between each term (minus the parens)!


Yup, definitely, I find the parallels interesting. Also reminiscent of languages like Io that stack functions together based on the output of the last.


I can not read that at all.


On the premise that someone might write LISP for a living, I'm saying it can help clarify a multistep mathematical expression. It's incredibly tedious to relitigate people's feelings about brackets over and over again.


I think it actually obscures the important facts about the expression by breaking up the structure which is displayed by the usual infix notation

1. It is a linear combination of a and b: there are two symmetric terms, a scaled copy of a and a scaled copy of b

2. The factors are functions of t alone which goes between 0 and 1 as t does

This isn't litigating about brackets, the traditional prefix notation also displays this structure (though less well than the infix notation IMO)

  (+ (* a (- 1 t))
     (* b t))


I was really only interested in the similarity between the threaded form and the proposal with all the commas (since they mentioned LISP) but I wish I'd had an aneurysm and died before sending the comment tbh.


Yeah, sorry, didn't mean to pile on. I guess my thoughts re the OP are that the common notation for addition and multiplication is not just "what you're used to", but is connected to objective mathematical properties (associativity, commutativity, distributivity).


No need to apologise, sorry for the unwarranted grumpy replies. Clearly it's tough to design for a wide audience, some of whom want to reason about programs as a series of steps, and some of whom deal with compositions of abstractions which may have deeper meanings outside the computer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: