This is the main reason I really like concatenative syntax for languages — this property is _enforced_ for programs (minus some delimited special cases, usually). It also neatly generalizes the special `self` argument so you can dispatch on the types of all the arguments.
Readit NewsTwey commented on Left to Right Programming graic.net/p/left-to-right... · Posted by u/graic
That's fine for doing algebra in pure functions, but what about destructive commands or interactive scenarios?
For example, using "rm" on the command line, or an SQL "delete". I would very much like those short programs to be invalid, until someone provides more detail about what should be destroyed in a way that is accident-resistant.
If I had my 'druthers, the left-to-right prefix of "delete from table" would be invalid, and it would require "where true" as a safety mechanism.
The solution suggested by the author, I assume, is `table.where(true).delete()` and `all_my_data.rm()`, which indeed has the property you describe.
Without curring and closures it certainly will be more painful!
I might write the equivalent signature,
D f(A, B, C)
Right, due to the complexity of the syntax one of the most sensible things to do in C if you're faced with a problem that maps naturally to higher-order functions is to reframe the problem so that the solution doesn't use higher-order functions — basically doing a compilation step yourself. D (*f(B (*)(A)))(C) is definitely a fancy type, after all :)
For those of us that haven't used Java for a decade...
> In text blocks, the leftmost non-whitespace character on any of the lines or the leftmost closing delimiter defines where meaningful white space begins.
From https://blogs.oracle.com/javamagazine/post/text-blocks-come-...
It's not a bad option but it does mean you can't have text where every line is indented. This isn't uncommon - e.g. think about code generation of a function body.
Right, this is a pretty common syntax, but doesn't address the same problem as Zig's syntax.
I've only seen two that do: the Zig approach, and a postprocessing ‘dedent’ step.
Fair enough. I think it qualifies as "essential complexity" and in my limited experience it's not a common use case and so doesn't make sense to optimize for.
In fact in my academic and professional career most of the highly "functional" C that I've come across has been written by me, when I'd rather amuse myself than make something readable.
It (this particular example, of function pointer syntax) is absolutely just incidental complexity, though. E.G. Haskell
(a -> b) -> c -> d
becomes C
D (*f(B (*)(A)))(C)
and it's no surprise that the former is considered much less fancy than the latter.
Of course it's not common — because the language makes it painful :) The causation is the other way around. We've seen in plenty of languages that if first-class functions are ergonomic to use then people use them all over the place.
Ambiguous parse. I don't mean that all function types are fancy, I mean that some are fancy (when you have a function pointers in the arguments or return value, or several layers of indirection), and that those which are fancy are helped by typedefs.
I maintain — they shouldn't be fancy. ‘Fancy’ is the mark of something your language doesn't support well. They can be _long_, and that's often worth breaking up, but if something is ‘fancy’ it's because it's not clear to read, so you should attach some identifier to it that explains what it's supposed to mean. That's significantly, though not exclusively, a function (ha) of the syntax used to express the concept.
If you're working with Roman numerals, division is a very fancy thing to do.
I considered making the case for the parallels to Lisp, but it's not an easy case to make. Zig is profoundly not a Lisp. However, in my opinion it embodies a lot of the spirit of it. A singular syntax for programming and metaprogramming, built around an internally consistent mental model.
I don't really know how else to put it, but it's vaguely like a C derived spiritual cousin of Lisp with structs instead of lists.
I think because of the forces I talked about above we experience a repeating progression step in programming languages:
- we have a language with a particular philosophy of development
- we discover that some concept A is awkward to express in the language
- we add a special case to the language to make it nicer
- someone eventually invents a new base language that natively handles concept A nicely as part of its general model
Lisp in some sense skipped a couple of those progressions: it had a very regular language that didn't necessarily have a story for things that people at the time cared about (like static memory management, in the guise of latency). But it's still a paragon of consistency in a usable high-level language.
I agree that it's of course not correct to say that Zig is a descendent or modern equivalent of Lisp. It's more that the virtue that Lisp embodies over all else is a universal goal of language design, just one that has to be traded off against other things, and Zig has managed to do pretty well at it.
We can just use a crate for that and don't have to have this horrible comment like style that brings its own category of problems. https://docs.rs/indoc/latest/indoc/
And what if you do want to include two spaces at the beginning of the block (but not any of the rest of the indentation)?
Choice of specific line-start marker aside, I think this is the best solution to the indented-string problem I've seen so far.
I worked with browsers since before most people knew what a browser was and it will never cease to amaze me how often people confuse slash and backslash, / and \
It’s some sort of mental glitch that a number of people fall into and I have absolutely no idea why.
I wonder if it's dyslexia-adjacent. Dyslexic people famously have particular difficulty distinguishing rotated and reflected letterforms.
this is a really, really good article with a lot of nuance and a deep understanding of the tradeoffs in syntax design. unfortunately, it is evoking a lot of knee-jerk reactions from the title and emotional responses to surface level syntax aesthetics.
the thing that stands out to me about Zig's syntax that makes it "lovely" (and I think matklad is getting at here), is there is both minimalism and consistency to the design, while ruthlessly prioritizing readability. and it's not the kind of surface level "aesthetically beautiful" readability that tickles the mind of an abstract thinker; it is brutalist in a way that leaves no room for surprise in an industrial application. it's really, really hard to balance syntax design like this, and Zig has done a lovely and respectable job at doing so.
> it's not the kind of surface level "aesthetically beautiful" readability that tickles the mind of an abstract thinker
Rather, the sort of beauty it's going for here is exactly the type of beauty that requires a bit of abstraction to appreciate: it's not that the concrete syntax is visually beautiful per se so much as that it's elegantly exposing the abstract syntax, which is inherently more regular and unambiguous than the concrete syntax. It's the same reason S-exprs won over M-exprs: consistently good often wins over special-case great because the latter imposes the mental burden of trying to fit into the special case, while the former allows you to forget that the problem ever existed. To see a language do the opposite of this, look at C++: the syntax has been designed with many, many special cases that make specific constructs nicer to write, but the cost of that is that now you have to remember all of them (and account for all of them, if templating — hence the ‘new’ uniform initialization syntax[1]).
This trade-off happens all the time in language design: you're looking for language that makes all the special cases nice _as a consequence of_ the general case, because _just_ being simple and consistent leads you to the Turing tarpit: you simplify the language by pushing all the complexity onto the programmer.