Hacker News Reader

Comment by alkonaut | Hacker News Reader

Are there "conversions" for other languages as well? I know it's almost required reading for any software developer worth their salt, but I have several failed starts with the original version and have sworn to never have to read Lisp code. I get the gist. I get that Lisp elegantly represents the close tie between data and programs in a way that procedural programs never will, which is probably why it is chosen for the book. But no matter how perfectly suited for the task it is, I won't squint at lines ending in ))))) to try to see that meaning.

View on HN

> I get that Lisp elegantly represents the close tie between data and programs in a way that procedural programs never will

Procedural is probably the best paradigm box to fit most Lisp in.

> I won't squint at lines ending in ))))) to try to see that meaning.

Nor do people who read and write Lisp. The indentation is really all that matters when reading Lisp. When writing Lisp, having your editor highlight matching parentheses is really the only feature you need to edit an expression that is deeply nested at the end like that. I bet your editor can already do that :)

In general, I would suggest that conversions to non-LISP languages (and that includes things like Ruby because people say "Ruby is my favorite LISP") makes pedagogical goals of teaching the theory difficult.

When I took my intro class in college, it was taught in Pascal. I had already been programming pascal (as taught by a chemist) in high school for a year or so. The first assignment which was Hello World I didn't even need to wake up in lectures for.

The second assignment... I didn't do quite so well. I had been using global variables and playing fast and loose with scope and passing variable parameters into procedures rather than using a function.

The thing was I already "knew" pascal and I had to unlearn what I knew before I could learn how to write pascal properly.

LISP (and Scheme and Clojure) work well in part because it always forces you to learn new concepts rather than having to unlearn what you did as a hobbiest before taking the class. The LISP family is unlikely to have been the choice language of a high schooler.

---

> But no matter how perfectly suited for the task it is, I won't squint at lines ending in ))))) to try to see that meaning.

When I took an AI class taught in LISP a few years later, the TA sent a joke email about how they had broken into some top secret code only to find it was all written in LISP. Due to the constraints of the mail system there they could only send the last {some number} characters.

))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))

Oh, newbies can learn Common Lisp badly and have to unlearn. Like, oh, use this let thing rather than introducing variables with setq inside your function, and speaking of which, for proper globals use defvar.

Are you saying let is bad? Why? Or am I reading you wrong?

I only use elisp though, and not common lisp or clojure

Yeah that's exactly why (I imagine) the first course in programming I was taught at University was Haskell. All of us who had been programming since age 8 had to reset our brains. A fantastic strategy for a curriculum if you ask me.

Lisp/Scheme/Clojure I'm sure are elegant and great for the same reasons as Haskell. They have unique traits that work well for teaching CS concepts.

I have one single issue: the syntax. I'm not getting past it. I'm 45 years old and have coded since age 8. I have tried and failed to manage learning or reading Lisp many times. I have tried picking up clojure, reading SICP I have had to tinker with AutoCad (AutoLisp) stuff for work. I'm just accepting that I'm not going to enjoy doing anything Lisp-related to the point where I'll ever manage to usefully read SICP, or learn one Lisp-y language to the point where I'd choose it for anything. And frankly it doesn't matter. I just accept it and move on. And I also understand that I can gaze at some Typescript monstrosity with sixteen levels of curly brackets, and while it's terrible syntax, my brain accepts it. But I can only imagine that it's 30 years (or just 1, who knows!) of curly bracket coding that makes my brain able to swallow that. But I'm not ready to invest even a week or two of time in teaching my brain to accept Lisp syntax.

While I had a class in '94 using LISP, it wasn't until dabbling with using "compute pi using pi/4 = 1/1 - 1/3 + 1/5 - 1/7 ..." as a replacement for FizzBuzz. In 2013 (and I can point to the date) I was also playing with Clojure and wrote:

    (defn pi
      ([] (float (* 4 (pi 1 0.01 0 true))))
      ([term tol accum pn]
        (let
          [t (/ 1 term)
           a ((if pn + -) accum t)]
          (if (< (* 4 t) tol)
            a
            (pi (+ term 2) tol a (not pn))
          )
        )
      )
    )

While I won't claim that that is beautiful Clojure, the `((if pn + -) accum t)` part was a lightbulb moment for me about how LISP and functional programming really worked.

With Java 8 (and beyond) I've become comfortable with passing around functions themselves or creating a Map<String, Function> or having an enum with a function field.

    if (type == enum.FOO) {
      UnaryOperator<String> trim = s -> s.replaceFirst("^0+", "");
      idFun = trim.compose(DTO::getFooNum);
    } else {
      idFun = DTO::getBarNum;
    }

    // ...

    Set<String> ids = results.stream().map(idFun).collect(Collectors.toSet());

As to LISP-ish concepts with {} syntax... https://en.wikipedia.org/wiki/Schwartzian_transform

    @sorted = map  { $_->[0] }
          sort { $a->[1] <=> $b->[1]}
          map  { [$_, -s $_] }    # get the size of the file on disk
          @files;

Reading Lisp isn't that onerous. For a start, the brackets (and particularly the closing brackets) are basically irrelevant. They help the computer parse the code but you can read it mostly based on indentation.

Anyway, there is a version in Javascript and the linked page has a textbook in Python.

If you have reasons to believe that the ))))) is correct (or in any case you are not looking to convince yourself whether it is correct or not) then it just means "multiple expressions are being closed here, consistently with the indentation". There is no reason to stare at it.

But you are OK looking at this?:

"...if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

I think he's probably right for C. Unfortunately for TS/JS it's not just idiomatic it's downright unavoidable to have at least twice that number of { } levels.

Before async/await I would have agreed with you, but now I think 3 indents is a reasonable maximum (4 if you're writing classes).

"If somebody starts talking about stuff like lines count, function sizes, nested ifs depth and tries to define optimal values, then be very careful about their advices" - me, &currentYear

Regardless of what you think of this particular maxim, one could do worse than cargo-culting Linus.

Code org itself is IMO fairly trivial. I just do whatever I think happens to look good. But trends will emerge even when you're just coding to taste. Thumbing through my code I find very few instances of either `} } } } }` or `)))))` (disclaimer - I don't use lisp).

Some times it's unavoidable but I'd try to avoid it if at all possible. There is no perfect syntax. It's common, especially with some newer constructs in TS/JS/C# that you end up with lines saying })), because of a closure passed. And I consider that kind of token salad to be quite a smell too.

Were you merely reading, or were you doing the exercises as well?

SICP was my first introduction to Scheme/Lisp - and not at a young age. Once I started doing the problems, reading it became trivial.

I was trying to read it, without being at all comfortable with the language. But I have also tried and failed multiple times to accept it by e.g. doing Clojure before that. So I wasn't entirely new to the syntax when I tried to read the book.

or you could just use m-expressions. just an idea. you know. use the tools provided by the language.

Nobody actually uses M-expressions. Mathematica and Wolfram use something quite close, but Lisps are almost universally written in S-expressions.

There are some alternative syntaxes like Sweet expression[1] (t-expression), but they've not found any widespread use.

[1]:https://srfi.schemers.org/srfi-110/srfi-110.html

Reply on news.ycombinator.com