gregfjohnson

It is a surprising and delightful consequence of this observation that there is a polynomial whose integer-valued roots are exactly the set of all prime numbers.

(Show HN?) There is a deep and lovely connection between the Y-combinator and the classic version of Godel's incompleteness theorem: https://gregfjohnson.com/incompleteness/

One use case that I'm beginning to find useful is to go into a specific directory of code that I have written and am working on, and ask the AI agent (Claude Code in my case) "Please find and list possible bugs in the code in this directory."

Then, I can reason through the AI agent's responses and decide what if anything I need to do about them.

I just did this for one project so far, but got surprisingly useful results.

It turns out that the possible bugs identified by the AI tool were not bugs based on the larger context of the code as it exists right now. For example, it found a function that returns a pointer, and it may return NULL. Call sites were not checking for a NULL return value. The code in its current state could never in fact return a NULL value. However, future-proofing this code, it would be good practice to check for this case in the call sites.

This all reminds me of one of the most foundational and profound papers ever written about software development: Peter Naur's "Programming as Theory Building". I have seen colleagues get excited about using Claude to write their software for them, and then end up spending at least as much time as if they had written it themselves trying to develop a theory the code that was produced, and an understanding sufficient to correct the problems and bugs in the created code. Every professional software engineer confronts the situation of digging into and dealing with a big wad of legacy code. However, most of us prefer those occasions when we can write some code fresh, and develop a theory and deep understanding from the get-go. Reverse-engineering out a sufficient theory of legacy code to be able to responsibly modify it is hard and at times unsatisfying. I don't relish the prospect of having that be the sum total of all my effort as a software engineer, when the "legacy code" I need to struggle to understand is code generated by an AI tool.

https://gregfjohnson.com

The original comment by Rob Pike and discussion here have implied or used the word "evil".

What is a workable definition of "evil"?

How about this:

Intentionally and knowingly destroying the lives of other people for no other purpose than furthering one's own goals, such as accumulating wealth, fame, power, or security.

There are people in the tech space, specifically in the current round of AI deployment and hype, who fit this definition unfortunately and disturbingly well.

Another much darker sort of of evil could arise from a combination of depression or severe mental illness and monstrously huge narcissism. A person who is suffering profoundly might conclude that life is not worth the pain and the best alternative is to end it. They might further reason that human existence as a whole is an unending source of misery, and the "kindest" thing to do would be to extinguish humanity as a whole.

Some advocates of AI as "the next phase of evolution" seem to come close to this view or advocate it outright.

To such people it must be said plainly and forcefully:

You have NO RIGHT to make these kinds of decisions for other human beings.

Evolution and culture have created and configured many kinds of human brains, and many different experiences of human consciousness.

It is the height (or depth) of arrogance to project your own tortured mental experience onto other human beings and arrogate to yourself the prerogative to decide on their behalf whether their lives are worth living.

Build one yourself! Here's an interactive balanced binary tee builder: https://gregfjohnson.com/redblackbuilder.html

(Show HN?) Here is another attempt at providing intuition on complex numbers, the multiplication rule in particular: "Why does complex multiplication have to be the way it is?" https://gregfjohnson.com/complex/

I find that the easiest intuitive on-ramp to complex arithmetic is to start with compass headings: "Oh that nice coffee shop? Go two blocks north and then a block east." Numbers come with any direction on the compass, not just "east" and "west". It turns out that it is pretty easy to intuitively justify multiplication by a scalar and addition of complex numbers, but multiplication is harder. A great way to get a feel for multiplication is to consider the equation "(x+1)(x-1) = x*2 - 1". Then, substitute "i" for x. The left-hand side is (intuitively) on a circle of radius 2 centered at the origin, and the right-hand side is on a circle of radius 1, where the circle is shifted horizontally so that its center is on the real line at -1. There's only one place these two circles meet: -2 on the real line.

There are bitter and heartstrong arguments on this topic. Brachycephalic breeds with flat faces or short snouts (for example pugs, bulldogs, boxers, Boston terriers) cause anger among some and devotion among others. (We are a three-pug family.) Pugs have an average lifespan of 12 to 15 years, as compared with the overall average dog lifespan of 10 to 13 years. We have also had (and loved) boxers, which have an average lifespan of 10 to 12 years. Boxers seem to be genetically prone to cancer, which is how we lost our most recent boxer.

There's a classic cartoon showing two wolves in the bushes at the edge of a campfire, looking at the leftovers being thrown around by the humans. One says, "Look, what the heck, let's cozy up to these two-legged creatures that seem to have lots of food. What could go wrong?"

Next frame is a picture of an unhappy-looking pug wearing a birthday hat..

There is this wonderful concept of "flow state", which I'm sure most of us are familiar with. It was originated by Mihaly Csikszentmihalyi. Many of us in this thread (and Linus's essay quoted in OP) are referring in various ways of getting into the flow state while programming.

Something I learned late in the game as a programmer is how beautiful it is when multiple people somehow sync up and get into a flow state together. It is like a choir, where everyone is somehow elevated and together they achieve a lovely unity. Or a sports team where all of the players are locked in, seemingly reading each others' minds, and getting to some amazing transcendent place together. The book "The Boys in the Boat" describes this phenomenon beautifully. When all nine members of the team achieve this sort of locked-in unity, the boat just flies across the water.

In software, there are times when ideas seem to pass with electricity from person to person. People immediately build upon the thoughts of others. Ideas seemingly come from nowhere, a synthesis of the conceptual pieces held by each of the team members. You realize that some wonderful new way of doing things has emerged from the dialog, and no one person could have possibly gotten there on their own.

There is a wonderful old-fashioned phrase that describes this: "The whole is greater than the sum of the parts."

My programming brain has two modes. One is playful mode, and the other is drudge workaday mode. 9-to-5 Monday through Friday is workaday mode. Other times are playful mode. As it turns out, I am a far better programmer in one of those two modes. It won't be hard to guess which one. In drudge mode, I may spend three hours some afternoon trying to force my way through a problem. No turning back, the clock is ticking! In play mode if I spend three hours goofing around with the exact same problem and it's kinda not happening, well, screw it. That was sorta fun, but let's goof around with it some more and try something else. BANG! Sweet clean obvious beautiful solution straight from Erdos' BOOK. The powerful sense of joy in the latter mode sustains my love for programming, but I wish I could convince my lizard brain that it would be OK, indeed far better, to stay in play mode and not get sucked into the dark doldrums of drudge mode during "job" time.

I heard an interesting talk recently by a Stanford neuroscientist.

He was studying standing waves of brain activity among circularly linked groups of neurons. Neurons can provide both excitatory inputs and inhibitory inputs to other neurons.

For a computer programmer, it is easy to imagine excitatory and inhibitory localized phenomena giving rise to all sorts of interesting and complex self-sustaining standing waves.

Think of the study of cellular automata by Stephen Wolfram and others, in which various simple localized rules give rise to all sorts of interesting computational phenomena, up to and including Turing Completeness.

In animal models such as pigs, these standing waves can be observed to persist for months if not longer.

His particular area of interest is to subject the brain to gentle sub-lethal doses of radiation treatment in order to change selected standing waves.

My thought is that there may be a qualitative difference between the underlying "neural hardware" and the thought processes that "execute" on this hardware.

It is the bread and butter of computer scientists to reason in a world in which the complexity of software greatly exceeds the simple computational artifacts on which it runs.

One might say that chess has information content that is qualitatively dissimilar to the wood-working needed to make a pretty chess board.

The information content in DNA is composed of chemically interchangeable A, G, T, and C molecules. So, one might say that the underlying physics is "walled off" from the information content of the DNA. Evolution has, as it were, a free hand to encode advantageous alleles, with no bias introduced by the underlying physics or chemistry.

All this is to say "Hear hear!" to this excellent article.

The "metaphorical brain talk" the author describes may indeed be a conceptual limitation if applied too broadly to the mind.

I hacked up a version of minesweeper that was “forgiving:” if there was no selection that was provably safe, it gave you a safe move. If you picked any square that was not provably a bomb, it would not be a bomb. Typically, as long as you don’t select a number of bombs equal to the number of squares , your first move is safe. I just extended that for the whole game. If you select N-1 bombs, you always win on the first move..

On the topic of Microchip and secrecy: I downloaded and installed their IDE, MPLAB X IDE v6.20. It is for a pic3mx chip. The compiler looks like a completely generic gcc, built to cross-compile on a Windows host. However, they want a $1000.00 “licensing fee” in order to enable any optimization level above -O0. This seems wrong. Wouldn’t this be a violation of the copyleft license covering gcc? I’m guessing there’s some loophole, since otherwise EFF and folks would be going after them. Or perhaps they don’t know about this situation? Should I alert EFF to this situation

I wonder if there are any plans to place meat along the bridge to attract mountain lions. Will ecologists try to "train" the wildlife to use the bridge, or just let nature take its course?

One possible definition of "random" in this context: Is there any conceivable algorithm, perhaps one that models the entire universe in all of its particulars, that predicts the next string produced by the NIST quantum beacon?

PuTTY is a supurb tool. Thank you so much for your efforts over the years.

IBM wrote APL\360 in 360 assembly language. The IBM 5100 personal computer had a small cpu. They wanted APL on the 5100, so they implemented a 360 emulator and ran the original implementation of APL on that.

OK here is my attempt at intuition:

Here is an approximation that captures the main effect (the 23.5 degree tilt of the earth's rotation axis) and overlooks secondary effects.

Consider the equator. Imagine a circle on the X-Y plane centered at the origin. Angle the circle up 23.5 degrees, rotated around the x axis. The projection of this circle back onto the plane is an ellipse on the X-Y plane, with the vertical axis about 92% of the length of the horizontal axis. Now, consider a series of vectors in the X-Y plane starting on the X axis, with angles in steps of 0.986 degrees. (This is approximately the angle the earth progresses around the sun each day.)

Where each vector hits the unit circle, move the point up or down so that it hits the ellipse. The angle will change a bit for most of the rays. In some cases the angle will be a bit smaller, and in some cases a bit larger. These discrepancies are the variations in time of day of sunrise and sunset over the course of a year on the equator.

Thanks, very much appreciate the thoughts and pointers!

This brings to mind something I've wondered about for a while. Sunrise on the shortest day of the year is earlier than sunrise for several days after it.

Sunset on these days after the shortest day is of course even later than sunset of the shortest day.

On the beautiful image of the OP, you can see that after dawn of December 21, dawn continues to get later over the next few days.

In my area, sunrise on 12/21/2024 was 6:54am, and it will continue to get later until 1/8/2025, when it is at 6:59am.

Length of day on 12/21/2024 is 9 hours, 54 minutes, and length of day on 1/8/2025 is 10 hours, 2 minutes.

Searching the web, I haven't found an explanation for this that "clicks" for me as both intuitive and rigorous. Any thoughts or pointers on this?

I've been trying to find discussion of this topic on Hacker News between October 1582 and September 1752, but to no avail.

'cal 9 1752' is .. funny. I guess instead of doing this annoying a-periodic leap second business, they accumulated a bunch of leap seconds owed, and skipped 11 days at one go. Sysadmins at the time were of divided opinion on the matter.

This short book is (IMHO) one of the best on software design. To me the main point of the book is the importance of well-designed abstractions. The "surface area" of a well-designed abstraction is small, easy to understand, and helpful as you reason through your code when you use it. The underlying implementation may be deep and non-trivial, but you find that you don't have any need to worry about the underlying internal details.

In short:

A beautifully designed abstraction is easy to understand and use.

It is so trustworthy that you don't feel any need to worry about how it is implemented.

Finally, and most importantly, it enables you to reason with rigor and precision about the correctness of the code you are writing that makes use of it.

This same identity can be used to provide geometric intuition as to why i*i must equal -1. This is shown in the diagrams at the bottom of http://gregfjohnson.com/complex/.

A nice way to think about eta-reduction is that it asserts something about the types of expressions in lambda calculus, namely that every expression is in fact a function.

If an expression M can appear in the left position of the function application operation, this implies that M is a function.

By way of analogy, if I have a formula x == x+0, this implies that x is a number.

Or, s == s + '' would imply that s is a string.

So, if M == lambda x. M(x), this is saying that M is a function.

I work at a medical device company that specializes in radiation treatment for brain tumors.

This thoughtful and profound essay brings home the lived reality of the patients who are treated by our systems.

The writer speaks lived truth that has a tone of heft and substantiality.

Human life is a fragile and temporary gift. Most of us are lucky enough to have a few moments of transporting and profound beauty and joy.

While life's journey has an inevitable end for all of us, we can help each other in innumerable ways to make the journey more bearable, and at times joyful.

I'm an old guy, and have an artificial hip and cataract implants. I'm deeply grateful for the quality of life I've been gifted to receive by the medical people who make these kinds of things possible.

I hope that the brain treatment system I work on will be a similar gift to the lives of at least some of the patients who require that kind of treatment.

We used LwIP for a project some years ago, and found a very nice way to do system testing.

The project involved multiple microcontrollers communicating over an internal LAN. They used a small embedded kernel named MicroCOS, with LwIP as the IP stack.

We had cross-platform build tools set up, so we could build our stand-alone microprocessor applications either for native execution or with gcc, compiling to x64 code and executable on developer boxes. In the latter case, we implemented the lowest level link-layer part of LwIP using a mock, that used standard TCP/IP! We wrote a small TCP server and would spool up the micro-controller applications, which would then talk to each other on the developer machines as though they were running inside the actual system.

This setup worked really well, and we used it for years during the development effort for the project.

A person close to me works at a law firm. She was feeling a bit stagnant, so she connected with a recruiter. She got a very solid offer with a significant pay bump. She gave her two weeks' notice to her firm, including appointments with the partners. One of the partners asked her for a half hour. They came back with a massive pay raise, and a promotion to partner if she would stay. She was in a state of shock, but then informed the other firm that she was staying at her current firm.

By way of contrast, an engineering firm I am familiar with had an employee who had been there six years, and knew the company's very complex product inside and out, every nook and cranny. He was one of the only people who had such deep understanding of the system that he could fix any issues that might come up, hardware, firmware, software, everything. He gave his two weeks' notice, and then went to a different job. He's a very talented guy, who would command a very attractive offer, but his talent to the current company is vastly greater than his generic value on the market, because of his detailed knowledge of the product. Although he diligently documented his knowledge, the company was still left in a jam after his departure. It would have been great if the company had fought for him the way the law firm fought for the other individual described above.

I grew up seeing founder mode first-hand. My dad founded Celestron, and he operated just as Paul is describing. At my current company, I see the CEO doing the exact same thing, which gives me great hope. Huge contrast from my previous start-up, for which I have great anti-hope unfortunately. (Current company is Zap Surgical Systems, with Dr. John Adler as the founder.) I've seen John everywhere, all day every day. I've seen him literally on his hands and knees under our robotic treatment table back in the engineering lab, discussing details with a young mechanical engineer. And yeah, we are curing cancer ;-)

To re-iterate: What I believe PaulG is saying is that there is a crucially important phenomenon that we don't yet understand, and naming it will facilitate the process of bringing it into focus so that we can help more companies be successful.

His footnote has a painful resonance: "I also have another less optimistic prediction: as soon as the concept of founder mode becomes established, people will start misusing it."

This is exactly what has happened to the Agile methodology.

I turn 70 tomorrow, and have been programming for about 53 years. Started a new job about six months ago. I immensely enjoy banging out the code every day. It still feels like a guilty pleasure! "Shouldn't I be doing homework right now rather than creating 3-D worlds algorithmically?" My first language was APL, which I learned in a college computer science course. This hard-wired me to think in functional terms; I personally think Iverson and Dijkstra were saying the same thing, but Iverson said it better: reason about your code from an "outside of time" perspective rather than mentally imitating the fetch-execute cycle of the machine. I view software development as a form of discrete mathematics; inductive reasoning for sequential blocks of code, Pnueli-style temporal logic for concurrent and parallel code. I've learned from some wonderful people how powerful it can be when a team likes each other and gets into a collective flow state. It is a bit like a mental version of quantum entanglement, and it is a very satisfying and meaningful thing when you get there. I've benefited from friends who helped me get that next job, and I've helped friends get their next jobs. About 20 years ago I made a switch to medical device software development. That is a domain that requires dedication to learn relevant mathematics, it is not going to go away, and you become a valued commodity when you have specialized skills and a talent pool that is not too large. And, you get to do things like visit your grandchildren in a NICU and see neonatal ventilators that you helped develop. So, I've been lucky, being able to play all day and do something I love! There are a million different paths through the space of software development; I've tended to traverse the space using the "what would be fun to goof around with on a Saturday" metric.