OliverJones

Good material!

It has to be said, the order of columns in correctly designed multicolumn BTREE indexes is governed by the shape of the queries the indexes support.

So don't arbitarily reorder columns in your indexes to handle alignment.

In my time as a biochem undergrad and grad student, I had to memorize and regurgitate the Krebs cycle no less than four times. None of those romps through it addressed the question of how TF did those scientists figure it out.

There's the science of Karl Popper, where no statement can be considered scientific unless it is possible to devise an experiment to disprove it. And there's the science of education, where we memorize and regurgitate stuff.

Those two are stunningly different from each other. Yet, it's not possible to get to the mysterious work of actually doing Popper-level science without memorizing what went before. The critiques of this paper still ring true half a century on. I wish more students of science from primary school on up would pester their teachers and each other with the question, "how do you know?"

FWIW, the XML signature stuff in dot net just works. Once you get dot net's XML stuff itself working.

I needed to use SQLite from php to develop a WordPress plugin. (Yeah, yeah, I have heard most if not all the jokes about that particular stack.)

Here are some notes about my experience, offered to anybody who might be able to use them. https://www.plumislandmedia.net/reference/sqlite3-in-php-som...

Looks like some web designers in law enforcement are having some fun making fun of the cybercreeps.

Dang, Rachel, you must have had a rough day at the orifice that day. Condolences.

Let us not forget his collaborator, Amos Tversky, who died young in 1996, and who certainly would have been a co-prize-winner had he lived.

This is great.

I wish it worked with glass :-) :-)

I sometimes sweep up broken glass from bike lanes in my community. I need gloves, a broom, a dustpan, and a trash bag. Not as efficient. Needs a car, not a bike.

Read about what to do: _The Fifth Discipline_ by Peter Senge. A bit dated by now, it's still good stuff about "systems thinking" . And you'll need a lot of deliberate systems thinking in your job, and you'll need to teach others to think that way.

Read about what not to do: _The Ultimate Question_ by Fred Reichheld. This book is about the notorious Net Promoter Score. (Would you recommend HN to a friend? Would you? Would you?) Reading it will give you insight into how bonehead MBAs with Cs in their marketing classes can convince leadership they've come up with a good way to measure customer satisfaction. (Net Promoter Score works fine for competitive businesses selling commodity products -- rental cars to individuals for example -- but not for many places where it is now used.)

It would be great to get a straightforward assessment of the improvements in reactor tech in this new plant. "Passive safety features" sound pretty good to my untrained ear. But how much of this is marketing bullshytt?

Cool! The 11/70 I worked on had a defective floating point unit for a while; when it overheated it would start garbling MUL results. I don't suppose this has that "feature" :-)

In wood shop in school, they teach you to use the saw, screwdriver, and tape measure before they say "make a box". Why not in programming shop?

One wishes there were a version of this article for science journalists.

And, one wishes that a university class on scientific ethics asked students to read this article with a critical eye and figure out what they can learn from it.

Myths about human-health topics spread faster than truth sometimes. cf. stomach ulcers and "stress" vs. pylobacter. It's hard to stop that. But it's easier to stop if we're aware of the myths.

It has to be said, web dev got better when the Redmond Middle School science projects (Microsoft Internet Explorer and old Edge) went into the dustbin of history where they have long belonged.

There's a book by Jen Pahlka called Recoding America. https://www.worldcat.org/title/Recoding-America-:-why-govern...

Germany seems to have similar sorts of federal / state / municipal government issues and other bureaucratic constraints as the US. And, this article makes it clear it has the same sorts of opportunities for improvement.

Maybe it's time to establish Programmieren für Deutschland as a parallel org to Code for America.

XML and JSON are for serialization. zip and sqlite, and file-system files, are for lossless persistence. They're separate issues.

An app can go bananas with serialization and use, I dunno, binary JSON or Matroska / ebml or .mp4 containers or whatever, and still serialize any way it wants.

It's trivial to implement hierarchical data with recursive common table expressions. https://www.sqlite.org/lang_with.html

If you're seriously interested in this topic, it's worth taking a look at Jen Pahlka's book Recoding America. https://www.worldcat.org/title/Recoding-America-:-why-govern...

Ms. Pahlka crawls through some large-system horror stories, and some success stories. The horror stories share something in common: design documentation that outlives its usefulness, takes on a life of its own, and drives implementation decisions in harmful directions.

Brandow's article (the subject of this thread) emphasizes the usefulness of documentation. And it's certain that long-lived software systems (like his php example) need excellent documentation. That documentation is targeted at people like many of us. It answers questions like, "how do I use that blankety-blank IMAP module?".

But long-lived documentation is often misunderstood and misused. For an overstated example, some "non-technical" administrator might read the php docs and somehow infer that "systems developed in php MUST use the IMAP module, or it won't pass acceptance testing." Then, the developers -- employees of some contract development team -- will comply. They'll have to figure out some way to incorporate email store-and-forward systems into the product, even if it makes no sense to do that.

There's a danger inherent in extensive documentation: it WILL be misunderstood in the future, and those misunderstandings may turn out to be costly. More systematic documentation -- for example boilerplate "scope" sections at the beginning of docs -- are not a great way to mitigate that danger.

Seriously, go read Pahlka's book.

When I'm coding / debugging with a framework of some kind (nodejs, dotnet, jdk, wordpress, whatever I'm using to deliver value at the time) I sometimes "step into" the framework or a library to see what happens. (Of course, I need open source for the framework/lib for this to work.) It sometimes opens a window to interesting code to read that's relevant to what I'm thinking about at the time. And sometimes doesn't.

Lots of source these days has auto-documentation comments. Good IDEs present that documentation, which helps guess what might be worth diving into the Step Into rabbithole.

Often, from a high-quality framework / library I learn a bunch about handling weird edge cases and about writing code for long-term maintainability. And, I often learn some useful constructs and techniques. (And, it's possible to learn useful things from not-so-high quality code too.)

I would really like to see what Joel Spolsky and Jeff Atwood, the original creators of Stack Overflow, have to say about the current state of affairs. Their business model was recruiting by identifying people with specific skills, and it was effective. I hired and was hired that way.

(They sold it years ago to a South African private equity venture and made the pile of money they deserved.)

People working in science have employed this process for a long time. Hit your local academic library and look for periodicals called "Annual Review of whatever". More generally, look for review articles and you'll see their work product. Some of these articles are stunningly informative: Feynman's approach works.

Review articles are not the same as meta-analyses; they aren't attempting to evaluate novel hypotheses using existing experimental data, but rather to understand the state of knowledge in a field.

When an academic worker, especially one on the publish-or-perish treadmill, wants to get into a new corner of their field they sit down and write a review article to both get up to speed and to rigorously explore their personal approach. And everybody who cares about the field is better for it.

One wonders about gut biome and whether any microorganisms there have any effect on this.

One also wonders how humanity can adapt to dramatically extended lifetimes without obliterating our planet.

What could a YC-style startup do for construction?

A lot of stuff is already done.

There's total standardization of parts sizes, and has been for decades. If you order a 2x4" wall stud from your local lumber yard, it will be the same size as the ones you order tomorrow. (It won't be 2x4, but that's another story.) Doors, windows, stairways, plasterboard, switchboexes, plumbing parts, basically everything in stock at a Lowes, are all designed to standard sizes, made in factories, and delivered to the site. The CAD software has all those standards built in.

Payroll and scheduling for workers? Done.

Ordering? Done.

I imagine any startup app opportunities will be in something you'd only learn about by going out to jobs sites and swinging a hammer for a year or two. If someone came in with such an idea, it might be wise to say "let's go on a tour of the jobsites you've been on in the last year" just as a way of validating real experience.

And every time this happens from now on, the fine should be doubled. When the fine gets too high for the lazy lawyer to pay, they may instead relinquish their bar admission (lose their license to practice law) for five years.

Lawyers admitted to the bar aren't innocents. They're "officers of the court", meaning the legal system relies on them to avoid BS in their citation of other cases and of statutes and laws. It's never been acceptable for a lawyer to sign off on something without reading it and making sure it's right.

What if registered professional civil engineers started asking generative AI for sewer-system or bridge designs and then didn't inspect them before approving them and handing them off to the guys with dozers and cement trucks? Not only would people fall into rivers, but the rivers would be polluted.

The real world consequences are similarly serious when lawyers make stuff up, or let their interns or word-processing software make stuff up.

Right. And all the GPL, MIT, and CC Sharealike-with-attribution material I've been stashing on Github is going into the vast code anonymizer called Copilot.

The good news for me the open-source developer: it looks like the closed-source code people write with the help of Copilot and all the open-source code in its learning set will also feed into that learning set.

I guess code just wants to be free -- free as in speech, expensive as in yachts and fine wine for VCs and private equity pirates. Plus ça change, plus ça reste la même chose. Sigh.

As an experienced (===old) developer, I have learned that data long outlasts the programs that access it. The lifetime of data is measured in decades, but programs last for years. Most SQL-based RDBMS teams have figured out workable version migration paths allowing old data to run on newer servers. Because this kind of migration is a very common and economically valuable operation, the vendors make sure it works correctly.

Sometimes a project, especially a greenfield project, looks like it will benefit from more recently invented data storage and query tech than your grandmother's SQL. That's always possible. And as developers we hope for, and work for, continued progress. But consider what may happen when the project succeeds.

If you're still on the project, you'll wake up one day and realize your oldest data is 20 years old. What happens if your storage and query engines are also 20 years old, because they didn't succeed to the extent needed to pay for maintenance and upgrades? You'll be in the software equivalent of the century-old subway system where you have to make all your replacement parts yourself, or get gouged by vendors that can't spread their costs among many customers.

Build for the ages, not for the moment!

Nice.

Effect of frequency downclocking when AVX-512 instructions get used?

https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Dow...

I'm convinced by this... as long as we make a distinction between mathematics and arithmetic.

I'm grateful now, and was not at the time, to my educator mother for drilling me and drilling me again on addition, subtraction, multiplication, and division. She drilled me until we were both so frustrated we couldn't see straight.

Her relentlessness gave me a basic numeracy that set me free to explore conceptual math and actually have fun doing it. She did it for my sibs too. It made us kiddos capable of playing car-trip games like "spot the prime number on the license plate".

She knew there was no magic pedagogy to learning that basic arithmetic, just drilling. Now she was no mathematician herself. Mention the central limit theorem to her and you'd get "huh"? She studied classics in school. But she sure knew how to to teach.

I take the author's point for single-user write-frequently search-rarely use cases. Plenty of small greenfield projects look like that.

Bigger projects, or projects that are enjoying fast growth, may well need indexing. Why? to keep search performance up under a multi-user workload and/or a mixed write-query workload. Complex multi-table searches often also benefit from judicious indexing.

Here's something to keep in mind: Successful projects often find that an unpredicted query pattern has become very popular and/or a bottleneck. Often the bottleneck is remediated in production by adding appropriate indexes. SQL's designed to add indexing without changes to the data model, for precisely that reason. It's normal to add indexes as projects grow, and no sign of bad design or expensive technical debt. (Unsuccessful projects, or projects that don't need to grow? They don't have the problem.)

The most important sentence in this article:

"Remember that you are a problem solver before you are a technologist."

(Almost) everything we make has users. The most important criterion we have for deciding how to build things is "will it make life better for our users?"