Punch-configured textiles go all the way back to the 1700s! The 1804 Jacquard Loom, which used cards, was a big part of the Industrial Revolution and influenced Babbage's Difference Engine and Analytical Engine, both of which use punchcards.
Yes and no. The both involve implementing a sequence of instructions to perform mechanical motions on fiber to form textiles. It might be moving frames to open the shed for weaving, or it might be opening hooks to chain for knitting. The fiber used and the properties of the produced textile may have different properties and the machinery may differ in detail but the processes are essentially identical.
If you are drawing up blueprints for a machine the two are essentially identical. You choose whichever makes sense for the joint you need, but they are essentially identical on the blueprint.
If you are making the card reader for automated machines, knitting, weaving, and playing a piano are virtually identical - you just move some lever in response to a hole. Someone working on a different part of the machine cares about the difference, but to the card reader they are identical.
This reminds me of the Citycorp Center near-disaster:
> LeMessurier's original design for the chevron load braces used welded joints. To save money, Bethlehem Steel proposed changing the construction plans to use bolted joints, a design modification accepted by LeMessurier's office but unknown to the engineer himself until later.
> With the tuned mass damper active, LeMessurier estimated that a wind capable of toppling the building had a one in fifty-five chance of happening any year. But if the tuned mass damper could not function due to a power outage, a wind strong enough to cause the building's collapse had one in sixteen chance of happening any year.
One of their line items complains about being unable to bind 65k PostgreSQL placeholders (the linked post calls them "parameters") in a single query. This is a cursed idea to begin with, so I can't fully blame PostgreSQL.
From the linked GitHub issue comments, it looks like they adopted the sensible approach of refactoring their ORM so that it splits the big query into several smaller queries. Anecdotally, I've found 3,000 to 5,000 rows per write query to be a good ratio.
Someone else suggested first loading the data into a temp table and then joining against that, which would have further improved performance, especially if they wrote it as a COPY … FROM. But the idea was scrapped (also sensibly) for requiring too many app code changes.
Overall, this was quite an illuminating tome of cursed knowledge, all good warnings to have. Nicely done!
Another strategy is to pass your values as an array param (e.g., text[] or int[] etc) - PG is perfectly happy to handle those. Using ANY() is marginally slower than IN(), but you have a single param with many IDs inside it. Maybe their ORM didn’t support that.
> This is a cursed idea to begin with, so I can't fully blame PostgreSQL.
After going through the list, I was left with the impression that the "cursed" list doesn't really refers to gotchas per se but to lessons learned by the developers who committed them. Clearly a couple of lessons are incomplete or still in progress, though. This doesn't take away from their value of significance, but it helps frame the "curses" as persona observations in an engineering log instead of statements of fact.
that also popped out at me: binding that many parameters is cursed. You really gotta use COPY (in most cases).
I'll give you a real cursed Postgres one: prepared statement names are silently truncated to NAMEDATALEN-1. NAMEDATALEN is 64. This goes back to 2001...or rather, that's when NAMEDATALEN was increased in size from 32. The truncation behavior itself is older still. It's something ORMs need to know about it -- few humans are preparing statement names of sixty-plus characters.
> One of their line items complains about being unable to bind 65k PostgreSQL placeholders (the linked post calls them "parameters") in a single query.
I've actually encountered this one, it involved an ORM upserting lots of records, and how some tables had SQL array-of-T types, where each item being inserted consumes one bind placeholder.
That made it an intermittent/unreliable error, since even though two runs might try to touch the same number of rows and columns, you the number of bind-variables needed for the array stuff fluctuated.
Or people who try to send every filename on a system through xargs in a single command process invocation as arguments (argv) without NUL-terminated strings. Just hope there are no odd or corrupt filenames, and plenty of memory. Oopsie. find -print0 with parallel -0/xargs -0 are usually your friends.
Also, sed and grep without LC_ALL=C can result in the fun "invalid multibyte sequence".
I don’t think that makes intuitive sense. Whether I send 50k rows or 10x5k rows should make no difference to the database. But somehow it does. It’s especially annoying with PG, where you just cannot commit a whole lot of small values fast due to this weird limit.
During the period for which we have evidence, Neanderthals seem to have had smaller populations than Homo sapiens, and they reproduced more slowly (longer gestation plus longer interval between pregnancies). So it may be that they went extinct for those reasons.
Their ratio was about the same as homo sapiens. It's not clear that they were less intelligent, they seem to have had a similar degree of intelligence based on findings from caves in Spain.
He was critical of blockchain, because he considered a permanent register of transactions to be the antithesis of privacy. How much store you want to set by that is up to you, but my instinct says that he was sincere.
This made me think of Dirk Gently's Holistic Detective Agency, Douglas Adams's 1987 novel, where there's an AI company that takes military and political decisions and comes up with post hoc rationalizations for them.
There's an excellent SF novella, Walter Jon Williams' The Green Leopard Plague, where Transnistrian corruption happens to be a major plot device. The other characters derisively call the Transnistrian government "Trashcanistanis." This story was my first encounter with Transnistria, and it seemed weird enough to be fictional, but later I found out it was real.
Tiny correction: I heard it as "all languages are really just dialects of Perl 6," which makes a bit more sense in context. Either way it's a cute Wall witticism, of which there were many that night. Word has it that there will be a video in a couple of weeks, at which point you can judge for yourself!
More background: https://en.m.wikipedia.org/wiki/Jacquard_machine