Considering that we're familiar with the latter syntax (more or less) since kindergarten, I'd say... yes. And the idea that you'd somehow start to consider something you've been doing all your life as “irregular” after 2–4 weeks of Lisp cure is just hilarious.
Depending on how frequent are complex equations in your code, you could make a macro for it, and write it e.g. like this:
(math 5 * f (x + 2))
I might be tempted to do so if I frequently encountered math expressions of depth 3 or more, which in my short Lisp career I didn't.
Also, I would probably rewrite the expression as:
(* 5 (f (+ x 2)))
to make it easier to read by putting the simple operand first; or in case of two difficult operands I would use formatting:
(* (f (+ x 2))
(g (+ x 3)))
Note that a good editor would check that the parentheses match the formatting, so I wouldn't really count that 3 closing parentheses are needed in the last line; they would be inserted automatically.
>And the idea that you'd somehow start to consider something you've been doing all your life as “irregular” after 2–4 weeks of Lisp cure is just hilarious.
And yet we learn all kinds of syntax that we haven't been familiar at all (zero indexing, x=x+1, etc which we used to the exact inverse: math assignments being immutable or denoting an equation not increment, etc),
-- not to mention advanced stuff like generics, futures, closures, etc --
Yes. 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. Parens, parens, everywhere, nor a drop of structure.
And when it comes to macros and (pseudo)-quoting, the LISP is hands down more obnoxious (again, for me) than, say, Python's f"{}".
> 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.
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?
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.
> 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.
is
that more difficult than: ?Or:
that more difficult than: