Musical chairs would indeed be a “fast paced and exciting” environment, but in the least desirable way.

I’ve personally witnessed the seventh entry to this meme: lines of code over 1000 columns wide.

I try to forget, but the horror never fades.

Does anyone want to even guess what time this clock is supposed to be indicating?

If only one side of the switch/points remain, depending on the type of crossing and condition of the wheels, there’s a chance that the trolley’s right side wheels can jump over the switch and continue straight forward, even as the switch is set to diverge onto the non-existent siding.

Or it could derail but continue barreling forward anyway. But trolleys don’t tend to be going that fast.

I did indeed have a chuckle, but also, this shouldn’t be too foreign compared to other, more-popular languages. The construction of func param1 param2 can be found in POSIX shell, with Bash scripts regularly using that construction to pass arguments around. And although wrapping that call with parenthesis would create a subshell, it should still work and thus you could have a Lisp-like invocation in your sh script. Although if you want one of those parameters to be evaluated, then you’re forced to use the $() construction, which adds the dollar symbol.

As for Lisp code that often looks like symbol soup, like (= 0 retcode), the equal-sign is just the name for the numerical equality function, which takes two numbers. The idea of using “=” as the function name should not be abnormal for Java or C++ programmers, because operator overload allows doing exactly that.

So although it does look kinda wonky for anyone that hasn’t seen Lisp in school, sufficient exposure to popular codebases and languages should impart an intuition as to how Lisp code is written. And one doesn’t even need to use an RPN calculator, although that also aids understanding of Lisp.

Addendum: perhaps in a century, contemporary programmers will find it bizarre that C used the equal-sign to mean assignment rather than equality, when the <= arrow would more accurately describe assignment, while also avoiding the common error of mixing up = and == in an if-conditional. What looks normal today will not necessarily be so obvious in hindsight.

Link to the blog post with the background on why this was made : https://ericwbailey.website/published/you-must-listen-to-rfc-2119/

Insofar as the skills hierarchy that software engineers develop well after learning to write in a programming language, I’m left wondering what scenarios or industries are the most “vibe coding” proof. That is to say, situations that absolutely require from day 1 a strong sense of design theory, creativity, and intimate knowledge of the available resources.

Musing out loud, history has given us examples of major feats of software engineering, from the Voyager spacecrafts, to retro console games squeezing every byte of ROM for value, to the successful virtualization of the x86 instruction set. In these scenarios, those charges with the task has to contend with outerworldly QA requirements and the reality that there would be no redo. Or with financial constraints where adding an extra PROM would cascade into requiring a wider memory bus, thus an upgraded CPU, and all sorts of other changes that would doom the console before its first sale. Or having to deal with the amazing-yet-arcane structure of Intel’s microchip development from the 80s and 90s.

It is under these extreme pressures that true diamonds of engineering emerge, conquering what must have appeared to be unimaginably complex, insurmountable obstacles. I think it’s fair to say that the likes of NASA, Sony and Nintendo, and VMWare could not possibly have gotten any traction with their endeavors had they used so-called “vibe coding”.

And looking forward, I can’t see how “vibe coding” could ever yield such “ugly”-yet-functional hacks like the fast inverse square root. A product of its time, that algorithm had its niche on systems that didn’t have hardware support for inverse square roots, and it is as effective as it is surprising. Nowadays, it’s easy to fuzz a space for approximations of any given mathematical function, but if LLMs were somehow available in the 90s, I still can’t see how “vibe coding” could produce such a crude, ugly, inspirating, and breathtaking algorithm. In the right light, though, those traits might make it elegant.

Perhaps my greatest concern is that so-called “vibe coding” presents the greatest departure from the enduring ethos of computer science, a young field not too tainted by airs of station. This field, I like to think, does not close its doors based on socioeconomic class, on the place of one’s birth, or upon the connections of one’s family. Rather, the field is so wide that all who endeavor for this space find room to grow into it. There is a rich history of folks from all sorts of prior occupations joining into the ranks of computer science and finding success. The field itself elevates them based on what they contribute and how they solve puzzles.

What strikes against this ideal is how so-called “vibe coding” elevates mediocrity, a simulacra of engineering that produces a result without the personal contribution or logic solving to back it up. It is akin to producing artwork that is divorced from the artist’s experience. It embodies nothing.

To be clear, the problem isn’t that taking shortcuts is bad. Quite the opposite, shortcuts can allow for going farther with the same initial effort. But the central premise of “vibe coding” is to give off the appearance of major engineering but with virtually no effort. It is, at its core, deceitful and dilutes from bona fide engineering effort and talent.

Circling back to the earlier question, in my personal opinion, something like the Linux kernel might fit the bill. It’s something that is now so colossally large, is contributed to by an enormous user and developer base, and fills such a sizable role in the industry, that it’s hard to see how “vibe coding” can meaningful compete in that space.

Yep, sometimes acetone will do that. But other times, another solvent like gasoline might do the trick. Or maybe a heat gun.

I see it as an engineering challenge, how to best remove intrusive logos from stuff. IMO, all this is part-and-parcel to the second part of: reduce, reuse, recycle. Also, sometimes certain logos can be clipped in very creative ways haha

It doesn’t work for backpacks that might have the company name embroidered on, but for cheaper print-on-demand items like hats and water bottles, acetone will cause the logo to dissolve or shift.

That says, I have personally removed embroidered logos from clothes before, when the product itself is excellent but aesthetically ruined by a logo. It’s very finnicky work with a seam ripper, and has gained me a lot of nice thrift store finds.

I’m reminded of Matt Parker demonstrating recursion in Microsoft PowerPoint:

https://www.youtube.com/watch?v=b-Fa6HtvGtQ

For timekeeping, you’re correct that timezones shouldn’t affect anything. But in some parts of law, the local time of a particular place (eg state capital, naval observatory, etc…) is what might control when a deadline has passed or not.

If we then have to reconcile that with high speed space travel, then there’s a possibility of ending up in a legal pickle even when the timekeeping aspect might be simple. But now we’re well into legal fanfiction, which is my favorite sort but we don’t have any guardrails ground rules to follow.

Up until the astronaut part, I was fully convinced that this is a law school theoretical question for an inheritance class, because that’s exactly where the vagaries of “is she my sister?” would also arise.

Then again, if we include time dilation due to near-lightspeed travel, we then have to deal with oddball inheritance cases like if your sister dies mid-travel but then you also die. The Uniform Simultaneous Death Act adopted by several US States would only apply if the difference in time-of-death is within 120 hours, but the Act is silent as to which reference plane will be used, especially if your sister is considered to be traveling “internationally” due to being in space, thus not being in the same US state or time zone as you might be in.

So maybe the entire question is a valid inheritance case study after all.

All it did was a lookup into a fairly sparse array. All the kerfuffle about it was unduly placed.

I once had the mispleasure to face a Bash script that was 35 lines tall but over 800 columns wide. The bulk of it was a two-dimensional array – or rather, a behemoth that behaved like an array of arrays – with way, way too many fields.

If that wasn’t bad enough, my code review to essentially rotate the table 90 degrees was rejected because – and I kid you not – the change was unreviewable in any of our tools and thus deemed too risky to change. /facepalm

The gall of some people.

I guess your nephew can start studying to become a network engineer now lol

In all seriousness, a 16 port managed switch exposes enough complexity to develop a detailed understanding of Ethernet and Layer 2 concepts, while not having to commit to learning illogical CLI commands to achieve basic functionality. 16 ports is also enough to wire up a non-trivial network, with ports to spare for exercising loop detection/protection or STP, but doesn’t consume a lot of electricity.

I would pair that switch with a copy of The All-New Switch Book, 2nd Edition to go over the networking theory. Yes, that book is a bit dated but networking fundamentals have not changed that much in 15 years. Plus, it can be found cheap, or on the high seas. It’s certainly not something to read cover-to-cover, since you can skip anything about ATM networks.

Then again, I think students might just simulate switch behaviors and topologies in something like GNS3, so no hardware needed at all.

Oh man, I forgot about that! Guess I have to go rewatch it now.

It’s a joke referencing: https://en.wikipedia.org/wiki/PC_LOAD_LETTER

I was once working on an embedded system which did not have segmented/paged memory and had to debug an issue where memory corruption preceded an uncommanded reboot. The root cause was a for-loop gone amok, intending to loop through a linked list for ever member of an array of somewhat-large structs. The terminating condition was faulty, so this loop would write a garbage byte or two, ever few hundred bytes in memory, right off the end of the 32 bit memory boundary, wrapping around to the start of memory.

But because the loop only overwrote a few bytes and then overflew large swaths of memory, the loop would continue passing through the entire address space over and over. But since the struct size wasn’t power-of-two aligned, eventually the garbage bytes would write over the crucial reset vector, which would finally reboot the system and end the misery.

Because the system wouldn’t be fatally wounded immediately, the memory corruption was observable on the system until it went down, limited only by the CPU’s memory bandwidth. That made it truly bizarre to diagnose, as the corruption wasn’t in any one feature and changed every time.

Fun times lol

I know this is c/programmerhumor but I’ll take a stab at the question. If I may broaden the question to include collectively the set of software engineers, programmers, and (from a mainframe era) operators – but will still use “programmers” for brevity – then we can find examples of all sorts of other roles being taken over by computers or subsumed as part of a different worker’s job description. So it shouldn’t really be surprising that the job of programmer would also be partially offloaded.

The classic example of computer-induced obsolescence is the job of typist, where a large organization would employ staff to operate typewriters to convert hand-written memos into typed documents. Helped by the availability of word processors – no, not the software but a standalone appliance – and then the personal computer, the expectation moved to where knowledge workers have to type their own documents.

If we look to some of the earliest analog computers, built to compute differential equations such as for weather and flow analysis, a small team of people would be needed to operate and interpret the results for the research staff. But nowadays, researchers are expected to crunch their own numbers, possibly aided by a statistics or data analyst expert, but they’re still working in R or Python, as opposed to a dedicated person or team that sets up the analysis program.

In that sense, the job of setting up tasks to run on a computer – that is, the old definition of “programming” the machine – has moved to the users. But alleviating the burden on programmers isn’t always going to be viewed as obsolescence. Otherwise, we’d say that tab-complete is making human-typing obsolete lol

If there were changes in 2020 to 2024 inclusive, then yes, I’d write it as 2020-2024. But if not inclusive, then I’d write 2021-2023.