alexdowad

There's obviously some nuance here, but the fact is that much modern software is riddled with bugs, and this is sub-optimal for everyone (both software users and software builders). Most of the bugs which frustrate and irritate software users are not due to uncontrollable events such as cosmic rays flipping a bit. Most of them are plain old code defects.

But, you do have a valid point. Allow me to rephrase it this way: The answer is not for software companies to spend unbounded amounts of engineer time chasing every reported bug.

But there are ways that we, as an industry, can do better, and it's not by pouring all our time into chasing hard-to-diagnose bugs. Here are a few ways that I personally see:

1. Some very powerful technologies for finding many bugs with little engineering effort already exist, but are not widely used. As an example, coverage-guided fuzzing is amazingly good at finding all kinds of obscure bugs. The idea of coverage-guided fuzzing was known from the 1990's, but it took AFL (in ~2013) to take it mainstream. Even now, much of the industry is not benefiting from the awesome power of coverage-guided fuzzing. And there are other, equally powerful techniques which have been known for a long time, but are even less accessible to most software developers.

So: spread the word about such techniques, and for programming language/platform developers, work on making them more easily applicable. This could help many software companies to catch a great number of bugs before they ever go to production.

2. Similarly, there are extant historical computing systems which had very powerful debugging facilities, much better than what is currently available to most developers. The ideas on how to make our platforms more debuggable are already out there; it's now a matter of popularizing those ideas and making them readily accessible and applicable.

3. Since it's widely known that many bugs (real bugs, not "cosmic rays") are extremely hard to reproduce, an admirable target for us to aim for as developers is to implement debug logging in a way which allows us to root-cause most obscure bugs just by examining the logs (i.e. no need to search for a reproducer). Some real-world systems have achieved that goal, with very good results.

4. While there is currently much buzz about using LLM-based coding agents to write code, I think an almost better use case for coding agents is in triaging bug reports, diagnosing the bugs, finding reproducers, etc.

I've recently had a couple of shocking experiences where, just given a written description of an intermittent, hard-to-diagnose bug, a coding agent was able to search an entire codebase, identify the exact cause, and write a reproducer test case. (And this after multiple experienced human programmers had looked at the issue but failed to identify the cause.)

In summary, I think there are ways to "cut the Gordian knot" of bug reports.

Quite impressive...

Yes, quite! Monsieur Bellard is a legend of computer programming. It would be hard to think of another programmer whose body of public work is more impressive than FB.

Unfortunate that he doesn't seem to write publicly about how he thinks about software. I've never seen him as a guest on any podcast either.

I have long wondered who the "Charlie Gordon" who seems to collaborate with him on everything is. Googling the name brings up a young ballet dancer from England, but I doubt that's the person in question.

Lua isn't my primary programming language now, but it was for a while. My personal experience on the library ecosystem was:

It's definitely smaller than many languages, and this is something to consider before selecting Lua for a project. But, on the positive side: With some 'other' languages I might find 5 or 10 libraries all doing more or less the same thing, many of them bloated and over-engineered. But with Lua I would often find just one library available, and it would be small and clean enough that I could easily read through its source code and know exactly how it worked.

Another nice thing about Lua when run on LuaJIT: extremely high CPU performance for a scripting language.

In summary: A better choice than it might appear at first, but with trade-offs which need serious consideration.

Agree. It always seemed like a strange and poorly conceived technology to me.

ivanjermakov, I don't know if you are an open source maintainer or not (I am, for several projects). If you are, and you follow the policy that "I will never reject PRs because of having no time, I will always get to it eventually", then I salute you. That is a self-sacrificing, altruistic position to take. It's also a very difficult position to maintain for the long term. If you can do it: congratulations!

As for me, my position is: "My project is my house. You want to be a guest in my house, you follow my rules. I really like people and am usually happy to answer questions from people who are reasonably polite, to review and provide feedback on their PRs, and so on. But I won't be pressured to prioritize your GitHub issue or PR over my work, my family, my friends, my health, or my personal goals in life. If you try to force me, I'll block you and there will be no further interaction."

If you don't like that position, well, I understand your feelings.

Be tactful and kind, but straightforward about what you can't/don't want to spend time reviewing.

"Thanks for the effort, but my time and energy is limited and I can't practically review this much code, so I'm closing this PR. We are interested in performance improvements, so you are welcome to pick out your #1 best idea for performance improvement, discuss it with the maintainers via ..., and then (possibly) open a focused PR which implements that improvement only."

My belief is that whatever technology can be invented by humans (under the constraints of the laws of physics, etc) will eventually be invented. I don't have a strong argument for this; it's just what makes sense to me.

If true, then an immediate corollary is that if it is possible for humans to create LLMs (or other AI systems) which can program, or do some other tasks, better than humans can, that will happen. Inevitabilism? I don't think so.

If that comes to pass, then what people will do with that technology, and what will change as a result, will be up to the people who are alive at the time. But not creating the technology is not an option, if it's within the realm of what humans can possibly create.

Afraid that I can't apply for this (because it's on-site), but what you are doing looks awesome. Hope that you succeed!

Wholeheartedly agree.

There are absolutely times when one can get LLMs to "say something valuable". I am still learning how to put them to good use, but here are some areas where I have found clear wins:

* Super-powered thesaurus

A traditional thesaurus can only take a word and provide alternative words; with an LLM, you can take a whole phrase or sentence and say: "give me more ways to express the same idea".

I have done this occasionally when writing, and the results were great. No, I do not blindly cut-and-paste LLM output, and would never do so. But when I am struggling to phrase something just right, often the LLM will come up with a sentence which is close, and which I can tweak to get it exactly the way I want.

* Explaining a step in a mathematical proof.

When reading mathematical research papers or textbooks, I often find myself stuck at some point in a proof, not able to see how one step follows from the previous ones. Asking an LLM to explain can be a great way to get unstuck.

When doing so, you absolutely cannot take whatever the LLM says as 'gospel'. They can and will get confused and say illogical things. But if you call the LLM out on its nonsense, it can often correct itself and come up with a better explanation. Even if it doesn't get all the way to the right answer, as long as it gets close enough to give me the flash of inspiration I needed, that's enough for me.

* Super-powered programming language reference manual

I have written computer software in more than 20 programming languages, and can't remember all the standard library functions in each language, what the order of parameters are, and so on.

There are definitely times when going to a manpage or reference manual is better. But there are also times when asking an LLM is better.

If your firm has been around for long enough, then it will almost certainly have long-standing clients who repeatedly come back for changes, additions, and general maintenance to existing software, as well as new development. Those long-standing clients will also introduce new clients.

Hi! It's strange for me to see one of my posts get some love on HN, years after I wrote it (and not one of my best pieces, by my own estimation).

Thanks to everyone who took the time to read.

I'm together with sethammons in that "rounding error". I actually go further and explicitly list things which I'm not good at on my resumé.

I've worked on numerous Rails projects since 2010, and it has lots of strengths, but I would really hesitate to base a new project on Rails.

The benefits of using a big framework (which you alluded to in your question) are easy to see in the short term. The pain comes in the long term.

Of course, there's no panacea. Your current "simple and low-dependency" approach has its own challenges, so choose your poison.

Ah, that must have been it. Thanks for the link!

Great article.

It reminds me of another anecdote, regarding a university professor who told his students that he would deliberately include one falsehood in each lecture, and the students were charged with listening carefully and identifying the 'mistake' in each class.

For the very last class in the course, the professor trolled his students by not including any mistake.

One small tip: Senior candidates may be discouraged from applying if you don't mention up front what your compensation range is.

I'm not an AI expert, but feel free to ping me on other CS-related topics. See https://alexdowad.github.io/cv for a rundown of which topics I am 'expert' (or at least semi-expert) in.

Start the team from hiring senior talent...

This is very important! Once you hire the first couple members of a development team, subsequent hires will almost certainly be at the same level of technical skill or weaker.

Although it doesn't help with your current problem: for future projects, consider demanding payment in installments, linked to project milestones. When the final invoice is small, the motivation for unscrupulous clients to stiff you becomes less, and if they do, the downside for you is also less.

Sure. I've done similar things myself, though the "advanced languages" which I'm expert in do not include Scala. This is a good example of what I'm talking about in the last paragraph of the comment which you are responding to.

There are lots of interesting ideas to be found in the Lisp/Scheme family. A Lisp can be an excellent choice of primary dev language, especially for a dev shop which puts enough investment into training and tooling.

At the same time, the state of the art in programming languages has advanced since PG wrote those essays. Even many of the languages which he was presumably referring to as "Blub" are much better now than they were.

A bigger issue is: As one gets better and better at computer programming, at some point the specific implementation language starts to matter less and less. (It never completely ceases to matter; but, less and less.) In one of his essays, PG contrasts "applying Bayesian filtering" with "applying if statements", which describes the matter quite aptly. At some point, language constructs such as "if statements" really do melt away.

For this reason, I reject claims that using a certain programming language will make one "1000 times more productive" (or similar) out of hand. The big problems in software are not at the level of the language at all.

This may sound false to newer programmers who have just discovered a fantastic programming language which allows them to work much faster than they could before. To such ones: I've been in your shoes. I've tried many languages, perhaps even the one you are enamoured with now. The benefits don't scale indefinitely. At some point, as you apply your fantastic new language to bigger problems, you will find yourself wrestling with the same issues as you used to with your old language, perhaps in a different form.

From your description of your current level, reading Patterson's "Computer Architecture: a Quantitative Approach" would be a next good step.

"Recently" (~5 years ago) I got very interested in mathematics, and decided to self-study up to an undergrad degree-equivalent level.

I researched what topics are typically included in a 4-year math major university program and what textbooks are used to teach those topics at MIT. Then started grinding all the way through from beginning to end.

It was so awesome that upon finishing, I promptly started all over again... but with physics instead.

Aside from what has already been suggested, you could consider reading selected chapters of Intel's programmer manual. I personally read through the whole thing once (well, skimmed some parts).

From my experience, Intel's x86 manual is better and easier to read than AMD's. It's a free download.

Mr. Courtice, your cautious and restrained assessment of the value of your own work is appreciated. I applaud your humility and like to think that I would take a similar approach in your position.

However, you have not really answered the big question which others who are interested in your work would like to understand. To mix metaphors, you are dancing around the elephant in the room.

You are welcome to keep dancing around that elephant if you wish. If you are ready to stop dancing, then:

In what ways, if any, do you aspire for Ripl to achieve (objective or subjective) superiority over other libraries "of similar feature-set"? Is it intended to offer better performance? An API which some users might prefer? A smaller deliverable code size? An implementation which is easier to understand? Or something else?

You stated that your goal is to achieve "feature/stability parity", but is that really it? Or is there something else?

This is interesting to me. The first question which comes to my mind is: As a D3 user, is this something which I might prefer to D3, at least in some contexts? If so, when might it be preferable to D3?

That's obviously a controversial question, and I can understand that the OP might want to avoid it, but realistically that is what potential users will want to know.

Anyone here who knows both D3 and Ripl and is willing to dip their toes into controversy?

Don't be sorry! I enjoyed your post, and your English is very good.

Here's another tiny little nitpick if you want to improve your translation a bit more: In English we don't say "inequation", we say "inequality".

That is doubtless true for the type of people who frequent Hacker News (mostly computer programmers). But in some other communities, the word 'theory' is commonly used in the same manner as Gilbert Ryle uses it. The author of this article is apparently unaware of that fact.

Aren't you modeling an entirely different problem...

Not really, but read on:

You correctly state that in the Monty Hall problem, the host reveals a door without the prize. That's the same situation which I described in my previous comment.

Try thinking about it this way: Say you are the contestant on that show. You have never played the game before, and you will never play it again. So you don't know how the host behaves. You pick your door, he reveals another door, there is no prize behind it. You would have to ask yourself: did he deliberately open that door because it had no prize? Or did he just happen to open a door that had no prize?

Your best estimation of your odds of winning changes completely depending on how you model the behavior of the host.

However, with any type of host, the situation whereby "contestant opens door with no prize, host reveals another door with no prize" can still occur, and regardless of whether you deem that the 'original' Monty Hall problem or not, it is the most interesting way to define the Monty Hall problem. Call it the extended Monty Hall problem if you want: the situation described above has occurred, and you have to both define a model for the behavior of the host (and game) and calculate your odds under that model.

Here's a challenge for you: Can you find a model under which the contestant has 100% chance of winning by not switching to the unopened door?