Readit News logoReadit News
fouric commented on Zig's Lovely Syntax   matklad.github.io/2025/08... · Posted by u/Bogdanp
Twey · 4 months ago
> 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]).

[1]: https://xkcd.com/927/

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.

fouric · 4 months ago
As someone who loves Lisps, I still have to disagree on the value of the s-expression syntax. I think that sexps are very beautiful, easy to parse, and easy to remember, but I think that overall they're less useful than Algol-like syntaxes (of which I consider most modern languages, including C++, to be in the family of), for one reason:

Visually-heterogeneous syntaxes, for all of their flaws, are easier to read because it's easier for the human brain to pattern-match on distinct features than indistinct ones.

fouric commented on Pony: An actor-model, capabilities-secure, high-performance programming language   ponylang.io/... · Posted by u/RossBencina
poulpy123 · 5 months ago
If the syntax is not important, that would mean coding in whitespace or malboge would be as easy as coding in python
fouric · 5 months ago
The GP is factually wrong. There's plenty of empirical evidence to indicate that language influences thought, and that syntax is therefore important.

Although, I would point out that while your argument ad absurdum is generally reasonable (the fact that syntax can make the difference between a very good language and an unusable one), whitespace and malbolge also have terrible semantics that contribute to them being unusable.

As a former Lisp enthusiast (and still an enjoyer), I'd actually use my own darling as an example: Lisps have amazing semantics and are generally good languages. Their syntax is highly regular and structured and easy to parse...except that it's brain-hostile, and I'm convinced that it actively makes it harder to read and write - not just adopt, but actually use.

fouric commented on The Illuminated Gospel of St John   cambridge.org/universityp... · Posted by u/ycombinete
harepods · 8 months ago
In an era where handwriting has atrophied significantly (read: mine especially), I am heartened to see such precision and artistry.
fouric · 8 months ago
Forget handwriting - I rarely see anything with as much care and effort put into it as this project.

I like to think that I put a lot of ~~craftmanship~~ into my code, but the effort put into every single letter of a roughly fifteen-thousand-word book (to say nothing of the letter at the beginning of the chapters or the illustrations) is on another level.

fouric commented on Unforgeable Quantum Tokens Delivered over Fiber Network   spectrum.ieee.org/quantum... · Posted by u/pseudolus
gus_massa · a year ago
Once you put error correction, doenn't you lose all the nice properties of the non cloning theorem? If the protocol tolerates 30% of errors, doesn't it tolerate 30% of MITM? (60%??)
fouric · a year ago
No-cloning theorem applies to logical qubits too! That "30% of errors" doesn't allow you to read out the logical state. Information is physical.
fouric commented on Crunch – a Scheme compiler with a minimal runtime   more-magic.net/posts/crun... · Posted by u/sjamaan
dokyun · a year ago
I don't believe it's not intrinsic. A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. Lisp programmers don't want to be told what to do, especially by the compiler. Some CLs like SBCL have allowed some form of inference through the standard type declarations in the language. This leads me to believe that the 'right thing' in the case of Lisp is a combination of dynamicity and some stronger typing features that can be applied during the optimization stage. The dynamic nature and ease of use of Lisp relative to its performance is one of its greatest assets: it would be nearsighted to try and sacrifice that--a good Lisp programmer can optimize the important parts of his programs such that they're comparable to or even outperform their equivalents in other more ``high-performance'' languages. With that being said, these developments might bring us closer to a ``sufficiently smart compiler'' that could make that latter stage mostly unnecessary.
fouric · a year ago
> A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system.

This perceived inflexibility is what my comment was getting at - that for primitive type systems available back in the 80's, yes, the types significantly constrained the programs you could write. With today's type systems, however, you have far more flexibility, especially those with "Any" types that allow you to "punch a hole in the type system", so to speak.

When I tried typed Python a few years ago, I found out that, to my surprise, 99% of the code that I naturally wrote could have static types attached (or inferred) without modification because of the flexibility of Python's type system.

I also learned that types are a property of programs, more than just languages. If a program is ill-typed, then having a dynamically-typed language will not save you - it will just crash at runtime. Static types are limiting when either (1) they prevent you from writing/expressing well-typed programs because of the inexpressiveness of the type system or (2) it's burdensome to actually express the type to the compiler.

Modern languages and tools present massive advances in both of those areas. Type systems are massively more expressive, so the "false negative" area of valid programs that can't be expressed is much, much smaller. And, with type inference and more expressive types, not only do you sometimes not have to express the type in your source code at all (when it's inferred), but when you do, it's often easier.

The "Any" type is really what steals the show. I don't think that there's a lot of value in a fully statically-typed Lisp where you can't have dynamic values at all - but I think there's a lot of value in a Lisp with a Python-like type system where you start out static and can use "unknown", "any", and "object" to selectively add dynamic types when needed.

Because, being a Lisper, you probably think like me, I'll give you the idea that really convinced me that types are positive value (as opposed to "only" being small negative value): they enable you to build large, complex, and alive systems.

Types are a force-multiplier for our limited human brains. With types, you can more easily build large systems, you can more easily refactor, you can start with a live REPL and more easily transition your code into source on disk. Types help you design and build things - which is why we use Lisps, after all!

fouric commented on Crunch – a Scheme compiler with a minimal runtime   more-magic.net/posts/crun... · Posted by u/sjamaan
fouric · a year ago
For Common Lispers such as myself, who are vaguely aware of developments in the Scheme space: the most important difference between CRUNCH and Chicken appears to be that, while both compile down to C/object code, CRUNCH is additionally targeting a statically-typed subset of Scheme.

Opinion: this is great. The aversion of Lispers to static types is historical rather than intrinsic and reflects the relative difference in expressiveness between program semantics and type semantics (and runtime vs tooling) for much of computing. Now that types and tools are advancing, static Lisps are feasible, and I love that.

fouric commented on Web Browser Engineering (2021)   browser.engineering/index... · Posted by u/MrVandemar
pavpanchekha · a year ago
Author here, and I also teach web dev, including CSS, at the University of Utah (including this semester). Newer parts of CSS, like flex-box layout are both simple and powerful. Just use those! I think it's important to start thinking about learning all of the Web Platform like you'd think about learning all of the Windows APIs or all of the Linux system calls or all of your favorite programming language's features. People rarely do! (I have 15 years of Python experience, and I do not understand metaclasses or async.) There are lots of weird obscure corners, but you don't need to know those to build websites.
fouric · a year ago
Thanks for the response!

Are there any resources on learning to design simpler layout systems (like flexbox + any other important parts) without having to adjust the design to compensate for older systems (e.g. if you were to try to implement CSS).

fouric commented on Web Browser Engineering (2021)   browser.engineering/index... · Posted by u/MrVandemar
mannyv · a year ago
One great thing about this book is the 'stuff I didn't do' part.

Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head.

At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today.

As an aside, video decoding is offloaded onto hardware, so it's not as battery intensive as it used to be.

fouric · a year ago
Layout is so difficult that it made me quit using Common Lisp and ncurses to build my passion project and become the very thing I swore to destroy (a React developer).

I can't be the only one who wants a simpler layout language than CSS that's designed with two decades of hindsight to provide the maximum simplicity-expressiveness product. Are there any serious projects to engineer something like this, or has everyone given up and either embraced CSS3 (waiting for the LLVM backend) or gone back to plain text?

fouric commented on Porting SBCL to the Nintendo Switch   reader.tymoon.eu/article/... · Posted by u/todsacerdoti
fouric · a year ago
This is super neat - SBCL is an awesome language implementation, and I've always wanted to do CL development for a "real" game console.

I'm also surprised (in a good way) that Shinmera is working on this - I've seen him a few times before on #lispgames and in the Lisp Discord, and I didn't know that he was into this kind of low-level development. I've looked at the guts of SBCL briefly and was frightened away, so kudos to him.

I wonder if SBCL (+ threading/SDL2) works on the Raspberry Pi now...

fouric commented on Poor Foundations in Geometric Algebra   terathon.com/blog/poor-fo... · Posted by u/ibobev
fouric · a year ago
I'm currently very slowly making my way through Geometric Algebra for Physicists by Doran and Lasenby. The book is a delight to read, but I'm not a mathematician, and this article is showing me that my small amount of understanding is...not nearly as deep, and especially not nearly as rigorous, as I would like. I should try to re-read with Eric's criticisms in mind.

u/fouric

KarmaCake day2087November 6, 2015
About
[ my public key: https://keybase.io/fouric; my proof: https://keybase.io/fouric/sigs/HFySFrX4sAbp5oBxACXHtsLYX0E_ZFXv1rASLXhbqAM ]

de5141c14b04cb621e0dcaa72565aef7f2e39dcd84c680f1277fde59931bc3fc

email: my HN username, at the proton mail domain or bold.tree8821@fastmail.com

interests: lisp and lisp-y things (emacs, structure editing, smalltalk, live editing, capability-based OSes, etc.)

View Original