Hacker News Reader

Comment by IshKebab | Hacker News Reader

I disagree. I have no problem with lists obsession in other languages like OCaml.

The parentheses are just too much. I get how elegant and unambiguous they are for computers but I am not a computer. It's like RPN. It's elegant and easy for code to parse and unambiguous and all these nice things.... except it isn't easy for me to parse.

Compilers are perfectly capable of compiling readable code like Rust so I don't see why I should have to do the tedious work of figuring out all the parentheses manually.

Lisp is like a really great IR. But I don't want to program in an IR.

View on HN

> I don't see why I should have to do the tedious work of figuring out all the parentheses manually.

I think most people who write a lot of Lisp don't do that. I use Paredit mode in Emacs, which doesn't allow the parens to become mismatched and has operations like "move the last token out of this expression" and "jump to the next expression" so it actually feels like you're editing a tree rather than a chunk of text.

A quick search says there's an equivalent for VSCode, and I'm sure other editors have options as well. I've seen some amount of structural editing for languages that don't use s-expressions, but it's always pretty limited.

If you've written Lisp with a good structural editor and still don't like editing a program as a tree, then we think about code very differently.

> operations like "move the last token out of this expression" and "jump to the next expression"

And that is the problem. When I am writing code, last thing I want to do is to think about tree manipulation and the numerous commands to do similar-but-not-the-same operations.

This is the same reason I don't like Vim, it's hard enough to keep the problem domain in mind, there's no mental space to also remember the ed-style editing commands.

After the learning period it becomes muscle memory and you don't have to think about it. If you're not willing to put in even the small amount of effort to build up new muscle memory, I don't know what to say other than don't be so defeatist.

This must be where we think about code very differently.

Most code has a tree structure, though many put the root token outside the brackets that mark it. Languages like C, Java and Rust use brackets to express their tree structure much like Lisp does, though they use more flavors of bracket than Common Lisp. Python uses indentation, but it's still expressing a tree. Ruby, Lua, BASIC, and others add keywords, but the stuff inside `do ... end` is still a branch of a tree.

Without a structural editor, I'm still building a tree, but I have to keep more of it in my head.

I think it's as much about familiarity than anything else. I've programmed full time in Clojure for the last 6 years, and I find it just as easy to read than other languages I'm familiar with (JavaScript, Java) and way less easy to read than other languages like Haskell or OCaml that have their own syntax lineage. I'm sure if I spent an amount of time becoming familiar with them, I'd find them just as easy as I do Lisp.

There are certain things that languages can do that make syntax easier; for instance, Clojure's default constructs reduce a lot of parens compared to CL by using brackets [] and removing nesting. For instance

    ;; clojure
    (defn sum-and-square [a b]
      (let [sum (+ a b)]
        (* sum sum)))

    ;; common lisp
    (defun sum-and-squaer (a b)
      (let ((sum (+ a b))
        (* sum sum)))

This leads some people to assert (with other reasons too) that Clojure is not in fact a "lisp."

    ;; common lisp
    (defun sum-and-square (a b &aux (sum (+ a b))
      (* sum sum))

    ;; clojure
    (defn sum-and-square [a b] (let [sum (+ a b)] (* sum sum)))

Honestly, I'm not sure what you're trying to show.

I'm not sure what you are trying to show? Code can be in one line? Okaaaaay...

I was trying to show that one can define local variables without adding another list level via let.

Like if one would/could write in Clojure:

    (defn sum-and-square [a b &blah sum (+ a b)] (* sum sum))

Another Common Lisp example, we'll stick to your one liner format, using infix syntax via a reader macro:

    (defun sum-and-square (a b) #I(sum=a+b,sum*sum))

Before you ask: what am I trying to show? This shows that Common Lisp syntax can be deeply extended by the user and that this is a standard feature of the language. Want a shorter infix notation without s-expressions? Why not...

Reader macros are global and stateful, this is one of the worst things about Common Lisp. Excellent feature, pity we're forever burdened with the implementation.

> It's like RPN

That's genuinely fascinating for me, because I find postfix notation to be more intuitive and easy to parse than infix notation.

It's definitely easier to parse programatically, but IMO it's a nightmare to read as a human. e.g. compare these expressions:

  (x+y)^2 = x^2 + 2xy + y^2
  x y + 2 ^ = x 2 ^ 2 x y * * y 2 ^ + +

I find it nearly impossible to parse this without actually maintaining the stack in my mind.

It's exactly how you would do the calculation if you ran it by hand, unlike the regular algebraic notation. I am flabbergasted that anyone uses the latter, especially as for most of the history of mathematics calculation was done by hand!

I don't "run" x 2 ^ by hand and I don't think anyone does. Some people find different notations more intuitive and that's fine but whether it's prefix postfix or infix, it's still an abstraction.

> I don't "run" x 2 ^ by hand and I don't think anyone does

Of course everyone evaluates expressions symbolically: in code review, when debugging, even when looking over an expression just after typing it to make sure it’s right.

Many languages have different verb order - English is notionally SVO (subject-verb-object), while Hindi is SOV.

That is probably much more related to why we use prefix/infix/postfix notation: because it maps to our native languages better.

> I find it nearly impossible to parse this without actually maintaining the stack in my mind.

You don't write out RPN in a long sequence like that. I'm a devoted RPN advocate and seeing "x y + 2 ^ = x 2 ^ 2 x y * * y 2 ^ + +" is indeed difficult to parse. But that's not at all how you use RPN.

You compute the problem going from smaller units to larger units getting intermediate results as you go and combining them. You'd never write out the sequence as you did and try to follow it after the fact.

I went through EE using an HP 49G+ and continue to this day using RPN in Emacs calc-mode.

>> I find it nearly impossible to parse this without actually maintaining the stack in my mind.

> You compute the problem going from smaller units to larger units getting intermediate results as you go and combining them

That's totally it. I've tried doing infix/standard algebraic notation on a calculator and unless the screen is big enough to see all of your brackets you're almost certainly going to screw up one of the big terms in a fraction or something like that. I think a good different way of stating the "intermediate results" part is that instead of computing the solution from left to right you're computing the solution from the inside-out.

By far the most satisfying part of doing computation in RPN is that moment at the end when you've got a big stack full of intermediate results and you just do that "+ + + + +" to add them all up and bam! Answer!

Edit: I had two thoughts back-to-back after writing that.

First thought: I do actually struggle sometimes with doing math in Lisp because prefix notation isn't a way that I'm used to doing math. Which led to "Hmmm... what if you did Lisp but with postfix notation instead of prefix notation"

Second though: "Ohhh... that's Forth. And you don't need brackets at all..."

> Ohhh... that's Forth. And you don't need brackets at all...

You still need them if you want variadic functions. Symmetrically, you don't need parentheses in lisp if you don't want variadic functions, as long as you're willing to draw an explicit distinction between calling a function and referring to it.

You might as well just make that distinction by using the parentheses, though.

I'm convinced a large part of the benefit people see from RPN calculators is that you have to figure out the order of operations before you start. It forces a way of thinking about the equation which is less error-prone, you're more likely to notice mistakes as well.

Takes a little getting used to, but the interesting thing is that analyzing an equation for the proper order of operations on an RPN calculator is not at all an error-prone process. It's a careful process, and it forces an understanding of the equation itself which just churning through it on an infix calculator does not.

How would you write this algebraic identity?

You write equations in the usual algebraic form. You don't write RPN on paper (or screen), that's not a thing.

When you're going to compute a value on the calculator, that's where you use RPN starting from the innermost computations working outwards, because you have a stack to keep all the intermediate results handy.

Again for like 2+2 it doesn't make any difference, but if you have a long formula with lots of values and different operations, it is much easier to do correctly and fast with RPN.

But this was a super easy sequence.

Can you give an example how it should be written?

For simple stuff, sure. Try -b±√(b²-4ac))/2a. Or anything complicated really. You end up counting parenthesis, writing down intermediate values, and just blowing it and starting over.

It's really nice to have something complicated, being able to sanity check intermediate values, and having a visible stack made things crazy easier.

I had friends in high school, for anything non trivial they would call out "anyone get 123.5 for the answer?". Look at me, and if they didn't get my answer they would try again.

So sure, postfix is easier for the simple stuff (which is easy either way), but postfix is MUCH easier for anything non-trivial.

> For simple stuff, sure. Try -b±√(b²-4ac))/2a. Or anything complicated really.

In anything complicated and long is where RPN shines the brightest!

If it's 2+2 I don't care whether I type 2+2 or 2 2 +. But for long complex equations, give me RPN every time. All my calculators are set to RPN mode (if it doesn't have RPN mode, I'm not using it).

I know it takes a bit of getting used to, but once you do it is a huge advantage. Particularly great for university tests where speed matters.

Indeed, great for speed and correctness.

It also makes awesome use of a multiline display, even an extra 3 lines to see the stack is a game changer. Without RPN I just use the extra area for graphing.

It's especially useful for unit conversions, since with prefix you never see the intermediate values.

With Rust do you close all your } manually? Do you have an example of Rust code where the equivalent Lisp code would be harder to parse, assuming equal familiarity with both languages?

> With Rust do you close all your } manually?

You don't have to, because you don't end up with }}}}}}}}} in Rust, because statements end with ; and not }.

I didn't end up with ))))))))) in Scheme because it was easy to create smaller functions. I do see rust ending with

      }
    }
  }

In TypeScript I'll often find myself ending blocks of code with

        });
      }
    });
  }

I'm having fun with TS, but I do miss the parentheses. They were simpler.

1. Lots of small functions lead to code in which bugs often hide in plain sight, see this old memo by John Carmack: http://number-none.com/blow/john_carmack_on_inlined_code.htm...

2. Scheme is better than Common Lisp when it comes to Lots of Irritating Superfluous Parenthesis, since declaring a variable in Scheme (using 'define') doesn't create a new nesting like it does in Common Lisp (using 'let').

I do, but there are about 4x fewer }'s in Rust than there are )'s in Lisp.

Look at these:

https://rosettacode.org/wiki/Archimedean_spiral#Common_Lisp

https://rosettacode.org/wiki/Archimedean_spiral#Rust

Reply on news.ycombinator.com