Hacker News: ethanlipson

New comment by ethanlipson in "Curly braces: An evolution of Unix and C"

ethanlipson — Sun, 24 May 2026 16:36:39 +0000

In the words of my combinatorics professor, Dave Bayer:

> It is hard to shed prejudices about how code should look, even if learning to see clearly past convention is the only good reason to be a mathematician. I'm already quite sure how I will die: I'll read another article on Hacker News about a new programming language where I see nothing new, and I'll read that they included {}; to make C programmers comfortable. I'll have a massive stroke.

New comment by ethanlipson in "Omarchy Is Not A Distro"

ethanlipson — Sun, 24 May 2026 16:29:27 +0000

Whether we call it a distribution or not is really a matter of semantics.

The more interesting question is, do people actually want a hyper-opinionated Linux install? Based on the reactions to Omarchy that I've seen, the answer is obviously yes. Broadly, people seem ok with just not using some of the suggested software if the defaults get them most of the way there.

More generally, I would say that configuring one's own Linux installation is not in itself virtuous. It used to be a way to identify people who were "committed" to using it via gatekeeping. The OP says that Omarchy is just DHH "cashing in" on new inexperienced Linux users, but as long as we don't value customizing one's own installation just for the sake of customization (I certainly don't anymore!), why is this a problem?

New comment by ethanlipson in "Futhark by example (2020)"

ethanlipson — Sat, 16 May 2026 13:37:49 +0000

I'm talking about cases where the array size is not known at compile time. For example, say the user passes in a list of numbers as command line arguments. Then we have

  argv: Vec

If I want to map these to ints, then I'd like a compile-time guarantee that the resulting array

  nums: Vec

is the same length as argv. Lean and Idris can do this, but AFAIK no commonly used languages can. But unlike general dependent types, these are not hard to wrap one's head around and would save a lot of frustration, in my experience.

New comment by ethanlipson in "Futhark by example (2020)"

ethanlipson — Sat, 16 May 2026 10:42:47 +0000

Futhark is really such a great idea. I'm not convinced that dependent types are worth the cognitive overhead in general, but it's definitely worth it to include the length as part of the type information for dynamic arrays, e.g.:

  concat(Vec, Vec) -> Vec
  matmul(Mat, Mat) -> Mat
  head(Vec) -> (T, Vec)

This would have saved me so much headache debugging CUDA kernels and numpy!! I wish it were a first-class feature in those frameworks, and even general-purpose languages, but alas.

New comment by ethanlipson in "If AI writes your code, why use Python?"

ethanlipson — Tue, 12 May 2026 18:05:14 +0000

For models as complex as these I'm not confident we can apply arguments from first principles; we could just as easily argue that type information is helpful, from first principles. What is much more useful is empirical evidence, and AutoCodeBench [1] found that LLMs are most proficient in Elixir (dynamic) followed by Kotlin (static), with Rust and PHP at the bottom. So it would seem like, as of publication, typing style doesn't really matter!

[1] https://autocodebench.github.io/

New comment by ethanlipson in "The shadows lurking in the equations"

ethanlipson — Wed, 05 Nov 2025 15:50:10 +0000

For a general function F, finding the points (x, y) with F(x, y) = 0 has no closed-form solution. The entire field of mathematical optimization is largely dedicated to finding solutions to F(x, y) = 0, in one form or another.

When F has a special structure (say, low-order polynomial), we can actually find the exact solutions. More general structure (e.g. convexity, differentiability) doesn't give us the exact solution, but it lets use use clever numerical algorithms to find them. There are techniques we can use when F has little to no structure, known as "black box" methods, and they work particularly well when we have few variables. In the case of "fuzzy graphs", there are only two variables, so this software takes the approach of computing F(x, y) for every pixel on the screen. In general this doesn't work due to the curse of dimensionality, but it creates good visualizations in low dimensions :)

To answer your question directly, yes we can use differential geometry to speed up optimization. As an example, you've probably heard of gradient descent. Preconditioned gradient descent leverages the geometry of the surface to speed up convergence. In the language of differential geometry, if we're optimizing f(x), then x is "contravariant" but grad(f) is "covariant", so technically we can't just add grad(f) to x since they have different types. We first have to multiply grad(f) by a rank-2 tensor (the "preconditioner") that encodes the local curvature of f around x. This technique is used by the Adam optimizer, with the assumption that the preconditioner is diagonal.

New comment by ethanlipson in "The shadows lurking in the equations"

ethanlipson — Wed, 05 Nov 2025 15:22:03 +0000

Neat, but I think it's deceptive for the website to claim this is a "new type of graphing" [1]. The fuzzy graph of F(x, y) = 0 is simply a 3D plot of z = |F(x, y)|, where z is displayed using color. In other words, F(x, y) is a constraint and z shows us how strongly the constraint is violated. Then the graph given by F(x, y) = 0 is a slice of the 3D graph. If you're claiming that you've discovered visualizing 3D graphs using color, you're about 50 years too late.

[1] https://gods.art/fuzzy_graphs.html