sramsay

Yes. Or "Lisp for hardware nerds." ;)

I think what you're talking about is part of a much larger pattern. Autotools imagines that the most important thing is the "user" in a world where people want to download your software and build it on their machine. They don't care (as much) about fast build times, the semantic clarity of the build files themselves, the ease with which one may change or extend the build sequence, test harnesses . . . Those are all developer worries.

They do care that the code can compile on their (possibly old) machine. They do care about the ability to include some features and not others (including their ability to not have to make decisions on this if they don't want to). And they certainly want documentation that helps them to achieve their goal (which, again, is to build the software).

The newer tools make substantial inroads in making the developer's life easier. If your software is not of the sort where people download it and try to build it (because it only ships as a closed binary, is entirely internal, etc.) then maybe that makes sense. But until all these fancy gadgets start seriously caring about the use case above, I'm going to stick with autotools.

I do find that "signalling expertise" is important. "I have a significant background in biblical scholarship. You can assume I've read the most important works in NT studies in particular. Do not translate Greek, Latin, Hebrew, or Syriac. Now, I would like to know . . ." That changes things significantly. So does telling it you have 20+ years of experience with C programming, that you have a robust understanding of machine organization, memory layouts, embedded systems, etc.

I absolutely understand what you're saying. It makes complete sense. But I will never, ever shake the sense that software that isn't as fast as possible is offensive, immoral, delinquent -- the result of sloth, lassitude, lack of imagination, and a general hostility toward our noble Art.

"Fast enough" will always bug me. "Still ahead of network latency" will always sound like the dog ate your homework. I understand the perils of premature optimization, but not a refusal to optimize.

And I doubt I'm alone.

I'll put TB Barricade against Pro-L 2 and TB Reverb against Pro-R for sure. I mostly use other stuff for EQ and compression, but those two are really very similar to the FB offerings.

And honestly, if I was on a desert island with just u-he plugins . . .

This. Is. Awesome.

Really. It amazes me that I still find out about new Linux plugins after years of producing music on the platform. It could not have been easy to compile this; the information is all over the place online.

The ability to filter (!) for compression, saturation, etc. is so great.

Thank you!

Author, here. This is exactly the question I was trying (perhaps ineptly) to pose: If we designed a programming language with the idea that it would be primarily or exclusively vibe coded, what would that language look like? Might it look something more like Lean? Or more like theorem provers in general? Or would it look more like a natural language PL (think Inform 7)? Or what about a heavily declarative DSL like FAUST (for audio DSP)?

None of our existing programming languages were designed for quite the circumstance in which contemporary programming now finds itself; they all address an ergonomic situation in which there are humans and machines (not humans, machines, and LLMs).

It's possible, I suppose that the only PL that makes sense here is the one the LLMs "knows" best, but I sort of doubt that that makes sense over the long term. And I'm repeating myself, but really, it seems to me that a language that was written entirely for the ergonomic situation of human coders without any consideration of LLMs is not addressing the contemporary situation. This is not a precise analogy, but it seems to me a little like the difference between a language that was designed before vs after multicore -- or before vs after the internet.

There might be. And I certainly bear no ill will of any kind toward the project or its devs. But I am in terminals all day long, and I hesitate to use one that is written in a language that hasn't yet hit 1.0.

Foot is way more my speed. Fast, extremely stable, and (most importantly) barely noticed. When it comes to terminals, the slightest flicker -- the merest bug -- and I'm gone. And that happened to me with both ghostty and alacritty.

I keep hearing this, but I fail to see why "the massive, well-maintained set of critical libraries upon which UNIX is based" is not a good reason to use C in 2025.

I have never seen a language with a better ffi into C than C.

Truly, one of the most original artists of our time. I am among those who think Einstein on the Beach is one of the greatest theatrical works of the twentieth century, but I don't think I ever saw a Wilson piece that didn't completely blow my mind.

I seem to recall an interview in which he said that he didn't think many of his works should be revived. I hope that's not true, and that his pieces have a long life in repertory.

> I'm not a scholar, just an amateur, but two sentences were strikingly ridiculous.

Well, I am a scholar, and if you mean "Noah clearly did not hide these texts," then yes. Of course, that is ridiculous.

But it's actually a crucial bit of information if you're a humanist scholar. The article doesn't say anything about it, but the question would be: Which tradition recorded this legend about these texts? Almost any answer is important, because one culture trying to legitimate its own literary traditions or those of another through its own myths or those of another is absolute gold. It helps us to understand the way literary and religious syncretism unfolded (or failed to unfold) in the ancient near east and in later epochs . . .

I remember megatons of Java Servlet(tm) hype convincing us that real programmers do OO.

Java remains the only programming language I've ever heard covered in a feature story for NPR.

Actually, what's amazing is that many of the people being mentioned fit within any coherent statement of the boundaries. Schaeffer is on it but not Radigue? When it said, "There's few women," I didn't think they meant it leaves off Oliveros!

When translating ancient Greek in class, one often slips into a weird translation-ese that would be pretty funny if you didn't know what was going on. You end up saying things like: "The going-into-the-temple men were on the one hand brave and on the other hand afraid."

It's funny you mention Kiril. I keep thinking about Pope Francis's (apparently deep and genuine) friendship with Bartholomew, Ecumenical Patriarch of the Orthodox Church.

It is traditional for the EP to visit Rome on the patronal Feast of Saints Peter and Paul and for the Pope to visit Istanbul on the Feast of Saint Andrew, which is apparently when the friendship first formed. My absolute favorite story about Francis is his deciding to send some of the most precious relics in the Vatican to Bartholomew as a gift: https://www.vaticannews.va/en/pope/news/2019-09/pope-francis... (That sent some people into a fury).

Actually, it's my second favorite story. My favorite story is his insistence that he live in the Vatican guesthouse (and not the Papal apartments). Or perhaps the fact that as archbishop of Buenos Ares he insisted on taking the subway.

I was really struck by the antipathy toward GCC. I'm not sure I quite understand where it's coming from.

This has more-or-less been my setup for over twenty-five years. I've used gentoo and vim that entire time, but have changed desktops a few times (i3 currently, but always something along those lines). All development -- and all writing -- is in terminals.

The difference is that I tend to to work on pretty high-powered machines (not for graphics or gaming, but for audio).

But the main reason I have this set up is that I find the minimalism . . . calming? It's not entirely distraction free, but I just find it easier to work in a kind of low-stimulation environment. I do occasionally work on way less powerful rigs (and way more powerful servers), and it's nice that the basic tools don't change. But ultimately, I think my fondness for this way of working might be aesthetic.

I'm talking about who can sign the forms that say you fulfilled the requirements of a degree. Random people cannot do that. Emeritus professors usually retain that ability.

I've served on PhD defenses where you had uncredentialed people on the committee, but who could not sign off on the degree.

This probably looks different to you if you're a student, because you typically don't see the paperwork that gets sent around afterward. But a diploma is a legal document. There is no "rubber stamping" of anything. Not if the school would like to maintain its accreditation.

> That's just an honorary title

It's true that it's an honorific, but I think it has a little more teeth than you think. At the institutions I've worked at, it comes with a few perks (like faculty-level library privileges), but it also includes the ability to serve on MA/PhD committees -- which is to say, you can be part of the group of people who certify the completion of an academic degree, which is not a privilege normally extended to retired professors. I've seen it granted when someone is switching institutions, but would like to remain the major advisor for a PhD candidate.

But whatever the case, the person is absolutely "still associated with the university;" that is part of the reason they're awarded. It's an award, certainly, but it's also a way for an academic to keep their credentials and for a university to keep their association with a (sometimes famous) academic.

But yes: It can be revoked at any time. I would be surprised if this one wasn't.

The question is, who among is willing to be the object of tomhow's first official Unsportsmanlike Conduct penalty? ;)

> Everyone may pick their language based on their aesthetic preference and attraction to certain features, but we should avoid sweeping statements about software correctness and the best means to achieve it. Once there are costs involved (and all languages that prevent certain classes of bugs exact some cost) the cost/benefit calculus becomes very complex, with lots of variables. Practical software correctness is an extremely complicated topic, and it's rare we can make sweeping universal statements.

Thank you. I feel like this perspective is forever being lost in these discussions -- as if gaining the highest possible level of assurance with respect to security in a critical system were a simple matter of choosing a "safe language" or flipping some switch. Or conversely, avoiding languages that are "unsafe."

It is never this simple. Never. And when engineers start talking this way in particular circumstances, I begin to wonder if they really understand the problem at hand.

Last release was four years ago.

I don't think people realize just how important XML is in this space (complex documentary editing, textual criticism, scholarly full-text archives in the humanities). JSON cannot be used for the kinds of tasks to which TEI is put. It's not even an option.

Nothing could compel me to like XSLT. I admire certain elements of its design, but in practice, it just seems needlessly verbose. But I really love XPath, though.

> it is C with a bit of polish.

I am fast becoming a Zig zealot.

What I've discovered is that while it does regularize some of the syntax of C, the really noticeable thing about Zig is that it feels like C with all the stuff I (and everyone else) always end up building on my own built into the language: various allocators, error types, some basic safety guardrails, and so forth.

You can get clever with it if you want -- comptime is very, very powerful -- but it doesn't have strong opinions about how clever you should be. And as with C, you end up using most of the language most of the time.

I don't know if this is the actual criterion for feature inclusion and exclusion among the Zig devs, but it feels something like "Is this in C, or do C hackers regularly create this because C doesn't have it?" Allocators? Yes. Error unions? Yes. Pattern matching facilities? Not so much. ADTs? Uh, maybe really stupid ones? Generics, eh . . . sometimes people hack that together when it feels really necessary, but mostly they don't.

Something like this, it seems to me, results in features Zig has, features Zig will never have, and features that are enabled by comptime. And it's keeping the language small, elegant, and practical. I'm a big time C fan, and I love it.

But is not, in any sense of the term, a DAW.

How so?

(If you're hearing a combative tone, it's unintended; I'm asking seriously, because I would love for this to be true!)

Better than C++? Better than Lua?

Hmm. I could substitute lots of languages for zig in that first sentence. But that doesn't invariably lead the communities that maintain those languages to utter the second.

I also doubt I have space to enumerate the languages that claim to "easily wrap c libs." None of them easily do that. That statement imagines that there's some basic consistency between APIs (and that those APIs are asking for and returning fairly simple types).