Hacker News Reader

Comment by wtetzner | Hacker News Reader

> It's all personal, of course, but I find that the typographical variety of "traditional" languages with syntax makes it way easier to me to read/parse them than LISP.

I wonder how much of that has to do with your familiarity with "traditional" language syntax. For example, when I started writing Lisp, I had a similar opinion. But I write Clojure professionally for a while, and that disappeared. Now I haven't written Lisp in probably 7 years, but I still have no problem reading it.

> Parens, parens, everywhere, nor a drop of structure.

On the other hand, in some sense it's all structure. There are certainly advantages to having everything be delimited.

View on HN

Yes, it's just that it's the useless (unless you write an AST-rewriting macro) structure that gets in my way. Say, naming a thing, a function definition, and a function invocation are all very visually different in, say, JS, while in LISP it's just a slightly different pattern of parens and two keywords ("let" and "lambda") that are, of course, not actually keywords but just happen to be interpreted in that way by the eval.

And yes, human ability to pattern-match things is astonishing, I am sure if I were to program exclusively in Scheme for half a year, I too would one day grow accustomed and used to it. But do I want to? I am really not convinced about that. A human can get used to pretty much anything, even to almost constantly being in mild pain, but... no. I'd rather just not.

> it's the useless (unless you write an AST-rewriting macro) structure

In a good JS editor, how many key combinations and mouse clicks are required to jumping into, jumping out of, and cutting a block of code (eg. a function definition or a conditional expression), or transposing, merging, splitting, annexing, and de-annexing 2 blocks of codes? It usually takes me at most 2 key combinations with a Lisp editor (including navigating the cursor to the right place), thanks to Lisp's uniform structure.

> Say, naming a thing, a function definition, and a function invocation are all very visually different in, say, JS

Aren't these also visually highlighted in a Lisp editor as well?

Besides, a Lisp editor can optionally blur the parentheses so users don't mentally have to.

(edit: formatting, recounting the key presses required)

I believe it's also 1 or 2 shortcuts, thanks to the IDE's understanding of the language syntax, unless I misunderstood your scenario?

> Besides, a Lisp editor can blur the parentheses so users don't mentally have to.

Besides, another languages can throw away the parentheses entirely so neither users nor editors don't mentally or visually have to.

> I believe it's also 1 or 2 shortcuts, thanks to the IDE's understanding of the language syntax, unless I misunderstood your scenario?

I have not seen transposing, merging, splitting, annexing (moving a block into the inside another block), and de-annexing (the opposite of annexing) 2 blocks of codes in JS without using the mouse yet, so I just want to check.

> Besides, another languages can throw away the parentheses entirely

JS uses parentheses for grouping complex arithmetics and for function's argument lists (eg. func(arg) in JS vs. (func arg) in lisp). JS also uses curly braces to mark code blocks, which is similar to Lisp parentheses but at the cost of more complex parsing for the compiler and the mental distinguishing between functions' argument lists and code blocks on the coder (they are just lists).

JS statements use semi-colons, which makes editing them feel like editing lines of codes while editing Lisp statements is editing nodes of a tree, which is a very different experience.

> Besides, another languages can throw away the parentheses entirely so neither users nor editors don't mentally or visually have to.

Which mainstream languages have no brackets?

> It usually takes me at most 2 key combinations with a Lisp editor (including navigating the cursor to the right place)

Is that in emacs/slime or another editor?

Emacs/slime.

> Besides, a Lisp editor can optionally blur the parentheses so users don't mentally have to.

How do I do that with spacemacs?

Try:

===

(package-install 'paren-face)

(global-paren-face-mode 1)

(custom-set-faces '(parenthesis ((t (:foreground "gray50"))))))

===

(edit: formatting)

In the user init file? I'm not an expert on spacemacs.

> Clojure professionally for a while, and that disappeared. Now I haven't written Lisp in probably 7 years, but I still have no problem reading it.

Slightly off-topic but interesting none-the-less. After starting to program with Clojure both as an hobby and professionally, how do you go back something that is not lisp/repl driven?

I've tried time and time again to go back to JavaScript, as I used to be OK with it, but I just cannot justify the hassles I have to fight with everyday, compared to if my co-workers just picked up Clojure instead.

Going back to something that's not REPL-driven takes some adjustment, but I try to find and focus on the advantages the other language has, instead of on what it's missing. For example, when using OCaml (which incidentally does have a REPL, but I don't use it often), I get a lot of value from the type system and the module system.

Even Java has advantages in terms of tooling, and from Java 8 on, you can write code using some Clojurish idioms with streams. Though for immutable data, you need something like Lombok + pcollections.

JavaScript, on the other hand, really doesn't offer anything over Clojure, so I can see why you'd struggle going back to it. It's just a downgrade.

You can get some of the interactivity through unit tests. Admittedly, the feedback loop is not always that tight as with the repl.

Reply on news.ycombinator.com