wpollock

This. Except worse, during busy days you had to stand on line for an hour or more for a turn on the machines. I believe the skill of debugging by mentally stepping through a program's execution came from such long run times, a useful skill many younger programmers lack.

It's probably not wise to say so on HN, but one possible strategic goal of this war was to distract from the Epstein files.

> They don't? It is taught in schools in the early elementary level. I see no indication that most are failing.

Programming in elementary schools typically involves moving a turtle around on the screen. (My mother taught 4th grade in New York for many years, and I believe her when she explained the computer instruction.)

Economically valueable programming is much more complex than is taught in many schools through freshman college. (I taught programming at the college level from 1980 till I retired in 2020.)

> If the company makes it impossible for you to communicate with them, the only recourse is to draw public attention to it in order to shame them.

Legal action works too. You'd be surprised how effective a letter from an attorney can be.

Your post reminded me when Yahoo IM updated their chat protocol to an incompatible version with a gradual rollout! Half their eight servers used v1 and half v2. A v1 only client would connect half the time depending on which server the round-robin DNS sent you to. This took me forever to figure out, but the fix was to put the IP address of the four v1 servers in the hosts file. (Until the client updated its support for v2.)

> And, especially what most people call big-endian, which is a bastardized mixed-endian mess of most significant byte is zero, while least significant bit is likewise zero.

In the 1980s at AT&T Bell Labs, I had to program 3B20 computers to process the phone network's data. 3B20s used the weird byte order 1324 (maybe it was 2413) and I had to tweak the network protocols to start packets with a BOM (byte order mark) (as the various switches that sent data didn't define endianess), then swap bytes accordingly.

Lesson learned was Never Ignore Endian issues.

My fantasy: After the salesman says (for the 4th time), "Sorry, the manager won't approve that price, but if you could add X hundred dollars, I'm sure I can convince them!", I wait until they are through high-fiving each other and then tell the salesman "Sorry, my trust manager didn't approve that price. I'm sure I can convince him if you lower the price by X hundred dollars".

My reality: I use my bank's car-buying service and pay the bank's negotiated price.

eiffel.com is a support tooling company. Eiffel the language has the website <https://www.eiffel.org/>. Both sites are worth a look.

Age verification is simple! A Kelvar strap must be attached to the user before the device will power up. A probe in the strap takes a drop of blood from the user and analyzes the protein markers to determine the user's age. (See the Stanford U. study for details.)

Surprised G. Orwell or A. Huxley didn't think of it first.

> Programming languages used for correct-by-design software (Ada, C++, Rust) ...

A shoutout to Eiffel, the first "modern" (circa 1985) language to incorporate Design by Contract. Well done Bertrand Meyer!

You're right, thanks!

This works too (but I wouldn't recommend it):

   assert( someBooleanExpression || ! "It is false" );

Allowing Unicode characters, then stating best practice is to stick with ASCII, is weird. (Go is not alone in this practice.) Unicode identifiers have a host of issues, such as some characters have no case distinction, some have title-case but not uppercase, some "capitalize" the last letter in a word and not the first (Hebrew has five "final form" letters), etc. Does Go specify the meaning (exported or not) if a letter has no case, or if an identifier starts with a zero-width joiner character? Without a huge list of detailled rules, too much is left to the implementation to decide. I prefer to stick with ASCII for names.

Fun fact: When printing with movable type began, printers would travel with large "type cases" containing the small wood or metal blocks with glyphs on them. The ones the used frequently were kept in the lower half of the case, in easy reach. That's where the terms "lowercase" and "uppercase" come from.

> assert(x > 0 && "x was not greater than zero");

Shouldn't that be "||" rather than "&&"? We want the message only if the boolean expression is false.

> In the modern world there is no plausible scenario where this would compromise a password that wouldn't otherwise also be compromised with equivalent effort.

Not sure about that. I'm no expert but for high risk scenarios one might have to worry about binoculars from the building opposite your window, power line monitoring, and timing attacks. All scenarios where the attacker cannot see your hands/keyboard.

I don't believe you're missing anything. This is just stegenography with a possibly new covert channel, right? Apparently the secret depends on advisaries not noticing the special hardware deployed on each end. Would using spread sprectum techniques would work just as well?

> "It was a straight port by Ken Smith (the only code in "Mocha" I didn't write) of Java's Date code from Java to C."

This is funny to me; Java's util.Date was almost certainly a port of C's time.h API!

RFCs have four digit numbers. This will likely change within a month or so; RFC 9945 was recently assigned so it won't be long. I wonder what RFC9999 and RFC10000 will be?

If they're Greek ferrets, apparently they become constipated. :-)

This discussion reminds me of this bit of security theatre: <https://wpollock.com/images/Security-done-wrong.jpg>

> RFC 1738 was superseded by RFC 3986 (URIs) ...

RFC 3986 has the same wording (appendex C), <https://datatracker.ietf.org/doc/html/rfc3986#appendix-C>.

It's been a few years, but for Java I used OWASP: <https://owasp.org/www-project-dependency-check/>, which downloads the NVD (so first run was slow) and scans all dependicies against that. I ran it from maven as part of the build.

Here's a handy shell script to show only the options from a command's man page:

   showoptions() {
      man -s 1 "$*" |col -bx |awk '/^[ ]*-/,/^$/' |less
   }

(Won't work for every man page, but most of them where options start with a dash.)

Enjoy!

An interesting approach, Good luck with it! A nit to pick: find is not a bash command. You can run it for example from a Windows DOS command line as:

wsl find ...

You can run all Linux commands this way. Also, pretty sure that find's "-o" is the Boolean "or", not "otherwise". (Yet another example of why learning from LLMs is dangerous, I suppose).

The first section in the introduction describes a YAML file. Bait and switch?

There's always TECO! <Joking>

> Steel-manning the idea, perhaps they would ship object files (.o/.a) and the apt-get equivalent would link the system? I believe this arrangement was common in the days before dynamic linking. You don't have to redownload everything, but you do have to relink everything.

This was indeed comon for Unix. The only way to tune the systems (or even change the timezone) was to edit the very few source files and run make, which compiled those files then linked them into a new binary.

Linking-only is (or was) much faster than recompiling.

> Ban publication of any research that hasn't been reproduced.

Unless it is published, nobody will know about it and thus nobody will try to reproduce it.

One purpose of QA testing is compliance assurances, including with applicable policies, industry regulations, and laws. While devs are (usually) good at functioal testing, QA (usually) does non-functional testing better. I have not known any devs that test for GDPR compliance for example. (I am certain many devs do test for that, just stating my personal experience.)

Some points:

LLM oral exams can provide assessment in a student's native language. This can be very important in some scenarios!

Unlimited attempts won't work in the presented model. No matter how many cases you have, all will eventually find their way to the various cheating sites.

There is no silver bullet. There's no solution that works for all schools. Strategies that work well for M.I.T. with competitive enrollment and large budgets won't work for a small community college in an agricultural state, with large teaching loads per professor, no TAs, and about 15-25 hours of committee or other non-teaching work. That was my situation.

Teaching five courses and eight sections, 20-30 students per section, 10-20 office hours every week (and often more if the professor cared about the students), leaves little time for grading. In desperation I turned to weekly homework assignments, 4-6 programming projects, and multiple choice exams (containing code and questions about it). Not ideal by any means, just the best I could do.

So I smile now (I'm retired) when I hear about professors with several TAs each, explaining how they do assessment of 36 students at a school with competitive enrollment.

If it's not a breaking change, why would a unit test fail as a result, whether or not using mocks/fakes for the code not under test? Unit tests should test the contract of a unit of code. Testing implementation details is better handled with assertions, right?

If the code being mocked changes its invariants the code under test that depends on that needs to be carefully re-examined. A failing unit test will alert one to that situation.

(I'm not being snarky, I don't understand your point and I want to.)