I think I can appreciate where you’re coming from, but in the context of the article it was legitimately necessary to address the topic somehow; it’s not like it was written apropos of nothing as a commentary on transsexuality. As a CIS person, I also have a “percieved gender” with which I identify.

Would “post-transition gender” be a more sensitive term, or less?

Let me know if you find one that uses AI to find groupings of my search terms in its catalogues instead of using AI to reduce my search to the nearest common searches made by others, over some arbitrary popularity threshold.

Theoretical search: “slip banana peel 1980s comedy movie”
Expected results in 2010: Pages about people slipping on banana peels, mostly in comedy movies, mostly from the 80s.
Expected results in 2024: More than I ever wanted to know about buying bananas online, the health impacts of eating too many or not enough bananas, and whatever “celebrities” have recently said something about them. Nothing about movies from the 80s.

It’s definitely bad design, but in a pinch it is readable in landscape mode for me. Alternatively, if your browser has a “force desktop mode” option, that often makes badly-written websites useable, if annoying.

That XKCD reminds me of the case a year or three ago where some solo dev that no-one had ever heard of was maintaining a library that a couple of other very popular and major libraries depended on. Something somewhere broke for some reason, and normally this guy would’ve been all over it before most people even realized there had been a problem, but he was in hospital or jail or something, so dozens of huge projects that indirectly relied on his library came crashing down.

What upset me most was reading the community discussion. I didn’t see a single person saying, “How can we make sure that some money gets to this guy and not just the more visible libraries that rely so heavily on his work?”, even though the issue was obliquely raised in several places, but I did see quite a few saying, “How can we wrest this code out of this guy’s hands against his will and make multiple other people maintain it (but not me, I’m too busy) so we don’t have a single point of failure?”

I’d argue that you do need to be good at math to be an effective programmer, it’s just that that doesn’t mean what a lot of people think it means. You don’t need to know all the ins and outs of quadratics, integrals, and advanced trigonometry, but I think you do need to have a really solid, gut-level understanding of basic algebra and a bit of set theory. If you’re the sort of person whose head starts to swim when you see “y=3x+2”, you’re going to find programming difficult at best.

Whatever it may have become in later years, Alan Kay, who is often called “The Father of Object-oriented Programming”, outlined the message-passing idea as the main concept he was driving at, originally.

He also says that he probably misnamed it.

Here’s a discussion in which the man himself makes a (small) appearance: https://softwareengineering.stackexchange.com/questions/46592/so-what-did-alan-kay-really-mean-by-the-term-object-oriented

I am currently working on a game for the Atari 2600, and you just gave a good outline of my code. And I love it.

I tend to agree. I think this attitude is something of a holdover from the early days of computer science, when of academics from all the other, existing fields, mathematicians were usually the best fit. Now that we have formal computer scientists, computer engineers, and software engineers, this is no longer the case.

In my experience, when someone from a purely mathematical background tries to program or explain something for programmers, they often (but not always, to be fair) insist vehemently on sticking to methods and algorithms that at best confuse the issue in a programming setting, and sometimes even run counter to how the computing hardware works, reducing performance. In these situations the rationale given is usually something along the lines of, “Listen, we mathematicians have been doing it this way for X hundred years, so that’s the way it should be done!”

I love low-level stuff and this still took me a little while to break down, so I’d like to share some notes on the author’s code snippet that might help someone else.

The function morse_decode is meant to be called iteratively by another routine, once per morse “character” c (dot, dash, or null) in a stream, while feeding its own output back into it as state. As long as the function returns a negative value, that value represents the next state of the machine, and the morse stream hasn’t yet been resolved into an output symbol. When the return value is positive, that represents the decoded letter, and the next call to morse_decode should use a state of 0. If the return value is 0, something has gone wrong with the decoding.

state is just a negated index into the array t, which is actually two arrays squeezed into one. The first 64 bytes are a binary heap of bytes in the format nnnnnnlr, each corresponding to one node in the morse code trie. l and r are single bits that represent the existence of a left or right child of the current node (i.e. reading a dot or dash in the current state leading to another valid state). nnnnnn is a 6-bit value that, when shifted appropriately and added to 63, becomes an index into the second part of the array, which is a list of UTF-8/ASCII codes for letters and numbers for the final output.

I thought that this was going to be a play on the phrase, “Don’t trust anyone over 30,” but it’s just a very short piece about Dunning-Kruger aimed specifically at some C++ concepts.

Assuming C/C++, dare we even ask what this teacher uses instead of switch statements? Or are her switch statements unreadable rat’s nests of extra conditions?

This is a good life lesson. We’re all idiots about certain things. Your teacher, me, and even you. It’s even possible to be a recognized expert in a field yet still be an idiot about some particular thing in that field.

Just because some people use a screwdriver as a hammer and risk injuring themselves and damaging their work, that’s not a good reason to insist that no-one should ever use a screwdriver under any circumstances, is it?

Use break statements when they’re appropriate. Don’t use them when they’re not. Learn the difference from code that many other people recommend, like popular open-source libraries and tutorials. If there’s a preponderance of break statements in your code, you may be using a suboptimal approach.

But unfortunately, for this course, your best bet is to nod, smile, and not use any break statements. Look at it as a personal learning experience; by forcing yourself sit down and reason out how you can do something without using break statements, you might find some situations where they weren’t actually the best solution. And when you can honestly look back and say that the solution with break statements is objectively better, you’ll be able to use that approach with greater confidence in the future.

I completely agree. And the video didn’t discuss how any of that actually happens, except to say that they send the update over radio, and to give a brief description of how the storage system on Voyager works (physically, not logically). That’s what I meant by “really nothing here”, “here” meaning “in the video”, not “in how the Voyager probe works and updates are carried out”.

That next line, “It turns out they they update the software by sending the update by radio,” was meant to be a bit sarcastic, but I know that isn’t obvious in text, so I’ve added a signifier.

This is a short, interesting video, but there’s really nothing here for any competent programmer, even a fresh graduate. It turns out they they update the software by sending the update by radio (/s). The video hardly goes any deeper than that, and also makes a couple of very minor layman-level flubs.

There is a preservation effort for the old NASA computing hardware from the missions in the 50s and 60s, and you can find videos about it on YouTube. They go into much more detail without requiring much prior knowledge about specific technologies from the period. Here’s one I watched recently about the ROM and RAM used in some Apollo missions: https://youtu.be/hckwxq8rnr0?si=EKiLO-ZpQnJa-TQn

One thing that struck me about the video was how the writers expressed surprise that it was still working and also so adaptable. And my thought was, “Well, yeah, it was designed by people who knew what they were doing, with a good budget, lead by managers whose goal was to make excellent equipment, rather than maximize short-term profits.”

Some of the things you mentioned seem to belong more properly in the development environment (e.g. code editor), and there are plenty of those that offer all kinds of customization and extensibilty. Some other things are kind of core to the language, and you’d really be better off switching languages than trying to shoehorn something in where it doesn’t fit.

As for the rest, GCC (and most C/C++ compilers) generates intermediate files at each of the steps that you mentioned. You can also have it perform those steps atomically. So, if you wanted to perform some extra processing at any point, you could create your own program to do so by working with those intermediate files, and automate the whole thing with a makefile.

You could be on to something here, but few people seem to take advantage of the possibilities that already exist, and combining that with the fact that most newer languages/compilers deliberately remove these intermediate steps, this suggests to me that whatever problems this situation causes may have other, existing solutions.

I don’t know much about them myself, but have you read about the LLVM toolchain or compiler-compilers like yacc? If you haven’t, it might answer some questions.

Drawing on Japanese, which is the only non-English language I have significant experience with, object.method(parameter) would feel more natural as object.(parameter)method, possibly even replacing the period separator with a Japanese grammatical construct (with no equivalent in English) that really suits this use case. Even the alternative function(self, parameter, ...) would mesh better with natural Japanese grammar as (self、parameter、〜)function. The majority of human languages have sentences which run Subject-Verb-Object, but a handful which includes Japanese run in the order Subject-Object-Verb.

I gave an example of an alternative for...in loop in another comment here, so I won’t rehash it here. But following the general flow of Japanese grammar, that for at the beginning of the statement would feel much more natural as a で (or “with”) at the end of the statement, since particles (somewhat similar to prepositions in English) go after the noun that they indicate, rather than before. And since semicolons don’t exist in Japanese either, even they might be replaced with a particle like “と”.

There aren’t any big problems here, but a plethora of little things that can slowly add up.

I’m no linguist, but I have some Japanese language ability, and Japanese seems to be pretty different, grammatically, from English, so I’ll draw on it for examples. I also had a quick look at some Japanese-centric programming languages created by native speakers and found that they were even more different than I’d imagined.

Here’s a first example, from an actual language, “Nadeshiko”. In pseudo-code, many of us would be used a statement like the following:

print "Hello"

Here’s a similar statement in Nadeshiko, taken from an official tutorial:

「こんにちは」と表示

A naive translation of the individual words (taking some liberties with English) might be:

"Hello" of displayment

I know, I know, “displayment” isn’t a real English word, but I wanted to make it clear that the function call here isn’t even dressed up as a verb, but a noun (of a type which is often used in verb phrases… it’s all very different from English, which is my point). And with a more English-like word order, it would actually be:

displayment of "Hello"

Here’s another code sample from the same tutorial:

「音が出ます！！」と表示。
1秒待つ。
「プログラミングは面白い」と話す。

And another naive translation:

"Sound comes out!!" of displayment.
1 second wait.
"Programming is interesting" of speak.

And finally, in a more English-like grammar:

displayment of "Sound comes out!!."
wait 1 second.
speak of "Programming is interesting".

And here’s a for…in loop, this time from my own imagination:

for foo in bar {  }

Becomes:

バーのフーで {  }

Naively:

Bar's Foo with {  }

More English-y:

with foo of bar {  }

You may have noticed that in all of these examples, the “Japanese” code has little whitespace. Natural written Japanese language doesn’t use spaces, and it makes sense that a coding grammar devised by native speakers wouldn’t need any either.

Now, do these differences affect the computer’s ability to compile/interpret and run the code? No, not at all. Is the imposition of English-like grammar onto popular programming languages an insurmountable barrier to entry for people who aren’t native English speakers? Obviously not, as plenty of people around the world already use these languages. But I think that it’s an interesting point, worth considering, in a community where people engage in holy wars over the superiority or inferiority of various programming languages which have more in common than many widely-spoken natural languages.

it shouldn’t matter that much what language the keywords are in

Another problem is that the grammars of many well-supported programming languages also mirror English/Romance language grammars. Unfortunately, dealing with that is more than just a matter of swapping out keywords.

EDIT: I may have been unclear; I wasn’t trying to imply that this problem is greater than or even equal to the lack of documentation, tutorials, libraries, etc. Just that it’s another issue, aside from the individual words themselves, which is often overlooked by monolingual people.

I think that it’s because a) the abstraction does solve a problem, and b) the idealized solutions aren’t actually all that simple.

But I still agree with the article because I also think that a) the problem solved by the added abstraction isn’t practical, but emotional, and b) the idealized solutions aren’t all that complex, either.

It seems to me that many devs reach immediately for a tool or library, rather than looking into how to create their own solution, due more to fear of the unknown than a real drive for efficiency. And while learning the actual nuts and bolts of the task is rarely going to be the faster or easier option, it’s frequently (IMO) not going to be much slower or more difficult than learning how to integrate someone else’s solution. But at the end of it you’ll have learned a lot more than you would’ve by using a tool or library.

Another problem in the commercial world is accountability to management.

Many decades ago there used to be a saying in tech: “No-one ever got fired for buying IBM.'” What that meant was that even if IBM’s solution was completely beaten by something offered by one of their competitors, you personally may still be better off overall going with IBM. The reason being, if you went with the competitor, and everything worked out, the less tech-savvy managers were just as likely to pat you on the back as to assert that the IBM solution would’ve been even better. If the competitor’s solution didn’t meet expectations, you’d be hauled over the coals for going with some cowboy outfit instead of good old reliable IBM. Conversely, if you went with IBM and everything worked, everyone would be happy. But if you chose IBM and the project failed, it’d be, “Well, it’s not your fault. Who could’ve predicted that IBM wouldn’t come through?”

In the modern era, replace “IBM” with the current tool-of-the-month, and your manager will be demanding to know why you’re wasting time reinventing the wheel on the company’s dime.

I think a part of it is how we look for information in the first place. If you search/ask “How do I do (task) in (environment)?”, you’re going to find out about various libraries/frameworks/whatever that abstract everything away for you. But if you instead look for information on “How do I do (task)?”, you’ll probably get more generalized information that you can take and use to write your own stuff from scratch. Try only to look for help related to your specific environment/language when you have a specific implementation issue, like how to access a file or get user input.

We also need a willingness to learn how things actually work. I see quite a few folks who seem to be so worried that they’ll never be able to understand some task that they unwittingly spend almost as much or even more time and effort learning all the ins and outs of someone else’s codebase as a way to avoid what they see as the scarier unknown.

Fortunately, I’ve seen an increase in the last year or two of people deliberately giving answers or writing tutorials that are “no-/low-library”, for people who want to know what’s actually going on in their programs.

I would never say to avoid all libraries or frameworks, because many of them are well-written (small, modular, stable) and can save us a lot of boilerplate coding. But there are at least as many libraries which suffer from “kitchen-sinkism”, where the authors want so much for their library to become the pre-eminent choice that it becomes a bloated tangle, trying to be all things to all people. This can be compounded by less-experienced coders including multiple huge libraries in one program, using only a fraction of each library’s features without realizing that there’s almost complete overlap. The cherry on top is when the end developer uses one of these libraries to do just one or two small tasks that could’ve been done in less than a dozen lines of standard code, if only someone had told them how, instead of sending them off to install yet another library.

My Hero isn’t actually Irish, but it does star Ardal O’Hanlon (Father Dougal) for almost its entire run, so it may scratch the itch.