Hacker News Reader

Comment by paultopia | Hacker News Reader

Absence of syntax! I really wish every language were a lisp. Like, Rust, the lisp, Swift, the lisp. Who needs rules of precedence and associativity and statements vs expressions and all the other stuff that languages that aren't lisps impose on you? Just stick an expression in some parentheses! And then put that in another expression!

View on HN

Absence? There's absolutely syntax in Clojure.

1) Lexemes have a specific structure.

2) Core data types have a specific syntax (representable with a grammar).

3) The data types used to represent programming constructs also have a specific set of syntactic rules by which they are assembled.

It's a different kind of syntax than the usual - more raw/direct, perhaps - but it's a misconception to say there is an absence of syntax. A big part of the reason I mention this is that the nature of Lisp's syntax is one of its biggest strengths.

Fair enough. I was aiming for a non-technical use of the term "syntax" more or less tracking the cognitive burden of remembering and parsing out the relationship between symbols for the programmer. Like, putting s-expressions in the front seat feels like a much lower cognitive load to me than, for example, all the stuff you have to think about writing, or, god help you, reading, pointfree haskell or line noise perl

Yes, there is syntax, but there is a lot less noise and syntactic bureaucracy compared to other languges.

Same here, after working with s-expressions I realized that you don't need to drown in syntax to have a flexible and expressive language.

Complex syntax introduces a ton of mental overhead, and it's a constant source of weird and hard to debug errors because code often does something subtly different from what you think it's doing. S-expressions enforcing a consistent and explicit syntax frees up a ton of mental space for me.

Amen. S-expressions allow you to navigate the code through your editor, and everything is consistent. Semicolons, commas, and curly braces are major cognitive overhead.

Yes please. Like the sibling comment says, it's definitely a syntax, but what a lovely syntax it is! Like a master key unlocking program structure. When I'm studying other functional languages, I find that the best way to make sense of their syntax is to figure out where the parentheses should go.

(find (most people) difficult (without (infix operations) (to expressions write)))

There’s definitely a learning curve, but it’s not a terribly steep one, and most minds with programming aptitude don’t seem to have much trouble with it after that.

It’s similar to learning declensions in Russian/German/Latin: weird and seemingly pointless to English speakers, and then usually fully internalized after a few months, with better intuition for costs and benefits of syntax vs cases.

I’d argue that the Clojure learning curve is significantly shorter than that also.

The best criticisms of Clojure (and I’ve written a lot in it) have nothing to do with parentheses, but rather the difficulties of grokking other people’s dynamic, untyped code.

Worse than untyped code is undocumented code.

Some programmers think types obviate the need for docs. Some programmers think concision obviates the need for docs. Except in the most trivial cases, they're both wrong.

My gripe with other people's code in Clojure is less understandability in terms of types and more in terms of style. A lot of major clojure libraries seem to use a really indirect style that brings a bunch of OO-style concepts back in. Like, I'm thinking of libraries like Component and Mount whose authors seem to have been aiming for a dependency injection kind of experience and end up creating a bunch of free-floating state, where, for example, you use a template to scaffold a simple webapp up, and it's surprisingly hard to figure out where in the code it's talking to the database. This actually caused me to leave the clojure ecosystem eventually.

If you use "The Pure Function Pipeline Data Flow",it only need Unix-style pipes and functions. you won't have to use concepts or patterns of OO&FP, and the parentheses are less than any programming language ;)

[The Pure Function Pipeline Data Flow](https://github.com/linpengcheng/PurefunctionPipelineDataflow)

Hi Lin Pengcheng, do you have an example of making side-effect calls with Pure Function Pipeline Data Flow method? e.g. database query.

A series of functions in a ->> block can only have one function with side effects and can only be at the end.

Exception handling is included in the function of side effects, and the exception is handled as actively as possible. In management, if an exception is encountered, always throw it to the superior, who will be fired:-)

you can do it like ring, treat client and server as db, query each other.

yes but (takes only (a (of bit practice)))

In 99% of programming languages, infix operations are only used for arithmetic -- and more than 99% of the programming I do doesn't involve that. Even the numerics software I've written is >90% non-numeric parts.

Arithmetic doesn't even look right in programming languages with infix operators. Go to the "Chalk is still one of the primary tools of mathematicians" article here, and try typing the inequality in Java. Mathematicians aren't writing "Math.floor()" and "% 2" on their blackboards.

I think you're optimizing for the wrong thing. Arguing that we need infix operations for 1% of our programs, so that arithmetic looks like how we entered it on a TI-81 or Apple II, is a false economy. It was a good tradeoff 25 or 50 years ago, but the majority of programming has moved past writing programs in terms of arithmetic on registers.

That said, there is a nifty macro [1] which adds infix support to Clojure, if you really want that. It even supports symbols like "√", unlike any other language I can think of!

[1]: https://github.com/rm-hull/infix

> In 99% of programming languages, infix operations are only used for arithmetic

I've been spoiled by Scala, but certainly most languages allow a "subject.verb(object)" style for general-purpose code, and that reads a lot better (particularly for those looking from the business domain) than "(verb subject object)".

> It even supports symbols like "√", unlike any other language I can think of!

Heh, again I'm spoiled by Scala, where √ is just another method/operator (there's no distinction) name if you want it to be.

> most languages allow a "subject.verb(object)" style for general-purpose code, and that reads a lot better

Why do you think this?

Programming isn't natural language, and I don't even know what the "subject" or "object" is in most cases.

> Programming isn't natural language

It's not, but it should be close; readability is important, and particularly when you want to express domain logic it's important to be able to hew closely to the actual language of the domain. Arithmetic is the most obvious example of this but it's just as true for other domains.

You're right readability is important, and Scala fails terribly in that department. I worked with Scala for around 6 months or so at one point, and I was still constantly looking things up after months of using the language. There's simply too much syntax and weird quirks in the language that it becomes impossible to keep it all in your head.

Not my experience - I found Scala's syntax is a lot more consistent than most mainstream languages (though, yes, it certainly doesn't go as far as lisps). Operators are just normal methods. Rather than complex rules about which constructs require braces, everything permits an expression or you can put a braced block of statements anywhere you could put an expression. Rather than a bunch of different special case syntaxes for collections / async / possibly-absent values, you have a single lightweight syntactic sugar (for/yield) that translates directly into plain old method calls. There are some libraries out there that make poor choices of method name, but that's about all.

My experience with Scala matches this pretty closely https://www.reddit.com/r/scala/comments/4246qc/heres_why_sca...

That's a strange set of complaints for a clojure advocate, since most of what they're complaining about is not too much syntax but too little - no mandatory braces, mandatory brackets, mandatory types. Indeed "a -> b" for "(a, b)" is not syntax or even a macro, but just a function.

_ is genuinely costly syntax, as are by-name parameters (though less costly in an age of IDEs). I consider _ to be worth its while (indeed I miss it a lot when writing lambdas in any other language); if you're going to have syntax in your language at all then it's one of the most general-purpose, effective constructs I've seen.

The problem isn't whether there's too much or too little, it's that the syntax is incredibly inconsistent. There are a million ways to do anything, and you have to juggle it all in your head. Consider stuff like this:

https://twitter.com/pembleton/status/1116343189437394944

A new line can be significant syntax in Scala!

With s-expressions, all of this mental overhead goes out of the window. I have regular boring syntax where pretty much everything works the same way. It's incredibly liberating. On top of that, s-expression syntax facilitates structural editing, where I'm manipulating the code tree semantically as opposed to thinking about moving lines of text around.

Scala has three styles, OO, FP, Python. When learning, people can find their comfortable style. But at work, any style of preference must endure the other two styles.

People use non-arithmetic infix operators in Haskell constantly. It's great.

It's also pretty easy to add prefix operators in e.g. Haskell or ATS (for something like square root)

Or, rather, a single simple syntax that applies throughout the language.

This sounds horrifying.

Reply on news.ycombinator.com