Jach

This is my objection as well. His talk last year on OOP was heavily focused purely on the style of OOP that led to C++'s version. It completely ignored everything else going on outside that historical thread. As history it was interesting but doesn't inform much outside of a C++ view of the world and it missed so much relevant history about OOP more generally.

While I suspect he could do research, he also just isn't personally experienced in large tracts of SWE culture as others. Others have worked a far larger variety of jobs in the software industry and thus tend to have a broader idea of the cultures and how they've evolved. In a recent clip I saw of him and others discussing how BS are various phrases engineers say (the root of all evil phrase being one of them), he hadn't heard of the YAGNI acronym/idea before. That's no fault on him, programmers live in different worlds. But regardless of one's feelings about such ideas, or whether they've heard of them or not, a history of SWE would have to cover them and the schools of thought that originated them. And this is just one minor thing in living memory and recent careers, there is so much from before he was born that has to be researched and if possible also talked about with the older practitioners who are still around and remember things. If you don't already have some awareness of things that should be covered in a history, whether from personal experience or just general curiosity about history that has led you to see such things before somewhere, the only hope is further research uncovering them, and I don't trust his researching that much.

Reading The Psychology of Computer Programming from the 70s was such an interesting read for me from a historical perspective as well as being able to see how some ideas they were thinking about back then came to fruition in some way or another. (e.g. Stack Overflow.) It's just one small part of history. A "complete" history as the top comment suggests would be better as a multi-author endeavor, would probably need many books, and that's if it could be done at all. In the meantime at least one can always go read primary sources and develop an idea of the history on one's own.

There's a selection effect here in that smart-enough users won't bother contacting support if they work around an issue on their own, or if something is actually a non-issue for 99%+ of the user base. The ratio of usage and support contacts can be monitored. I fear a lot of devs develop unproductive mental models of the user purely from a minority sample.

Watching bits of videos from this guy's series on beating every N64 game (including JP-only releases) is a fun way to find out about interesting games I missed from back then. https://www.youtube.com/playlist?list=PLrwJXOVKrLbIDAiT9b4Lk...

Ars article about it: https://arstechnica.com/gaming/2026/08/new-bootloader-lets-y...

I haven't yet attempted to run it on my old Quest.

I treat the Amazon Prime membership as the "card fee". The cash back accumulation per year is always greater than the membership fee for me. (The original main benefit of savings on shipping is of course also nice, though if I'm honest with myself I'd say the majority of my purchases didn't actually need 2-day/1-day/same-day shipping. Very nice luxury however.)

This is untrue. Chrome's "acceptance rates" for proceeding through its bad SSL cert warnings used to be pretty high, but with a redesign they basically flipped the numbers so most people didn't proceed to connect to the site. Similarly with cookie banners, where making it more difficult to say no (by e.g. moving a decline button to a second interaction layer) meaningfully raises acceptance rates; if users were just blindly accepting everything, then there'd be no reason to make it harder to say no. Apple's App Tracking Transparency (ATT) prompt has users overwhelmingly answering no even years after introduction (though of course opt-in is increasing). A study on permission prompts in Android found that the main factor in first-use denial rates was whether users thought the app needed the permission it was requesting or not, showing some actual comprehension of what they're being asked. Another found higher denial rates if the frequency of the prompt was on every access instead of once, rather than apathetic blanket acceptance.

Design prompts for potentially dangerous actions so refusal is easy and what's being asked is legible, and people will refuse plenty.

I live in Bellevue so by supporting Amazon I'm supporting a local business. It's hard to imagine replacing most of the things I get from the site with someplace else. (Though it'd be nice to have a Micro Center.) I've even started getting more grocery products as Safeway/QFC/Fred Meyer up their prices, and the Redmond Fred Meyer closed which had the best produce. Etsy is mainly useful to me for the occasional copyright-infringing merch.

I don't like its default look, but the screenshot they linked was non-default and what I do like, so I'm wondering why they find it sloppy/bad. Perhaps they would like Gimp's default more? Here's a representative shot from 2020: https://www.lifewire.com/thmb/H9QCFUVFrU035srbCoZ5erwS20Q=/1... Not even the +/- buttons another comment complains about are in this one.

Also curious what you dislike so much. And how does Photoshop compare? https://i.ytimg.com/vi/_ghez_hKxeo/hq720.jpg I like the way Gimp has looked more and disliked many of their experiments changing things. The screenshot you linked isn't even the default look anymore, they've got a dreadful dark mode if you like that sort of thing. The first thing I do on a new install is restore the light mode and color icons it has, and make all the tool icons visible at once.

I really enjoyed reading your comment. I was reminded of a perspective from Patterns of Software, a collection of essays from the 90s by Richard Gabriel. The very first one talks about the ideal of "reuse".

"A similar idea [to libraries] is the Collected Algorithms published by ACM years ago in an ALGOL-like publication language. I remember when I was a kid in 1968 looking up algorithms for sorting and searching in my first programming job. However, what every manager learns is that reuse under these circumstances requires a process of reuse or at least a policy. First, you need to have a central repository of code. ... Second, there has to be a means of locating the right piece of code ... It does no good to have the right piece of code if no one can find it. Classification in the world of books, reports, magazines, and the like is a profession, called cataloging. Librarians help people find the book. But few software organizations can afford a software cataloger, let alone a librarian to help find the software for its developers. This is because when a developer manager has the choice of hiring another developer or a software librarian, the manager will always hire the developer."

He talks about a few reasons for why this is, one of them being simply that plenty of code for your project will just have to be new / different enough from existing code, so there's not much reuse benefit there. He qualifies that with performance concerns, but that's just one reason why it would have to be different.

Another thing I was reminded of, from the intro of Etudes for Programmers:

"Programming is a craft, and programmers must attain a standard of craftsmanship. Much programming is done in cottage shops -- that is, in small shops with meager tools, much work done by hand, and learning attained from other laborers, by chance, and often not at all. ... the academics have also discovered that a craft cannot be taught well by teachers alone; the guild apprenticeships had considerable merit. In a classic apprenticeship the candidate spent many years doing menial tasks while absorbing fundamental techniques of the trade from more experienced workers in the shop. Gradually the apprentice was given more technical responsibility and, after a formal test of skills, eventually became a journeyman certified competent for all ordinary jobs in the trade. The journeyman traveled the world and, if the muses allowed, one day presented a masterpiece to the guild and became a craftsman of the highest rank -- a master of the guild."

Seeking for the average to be that of journeyman, rather than apprentice, seems like a worthwhile goal for the industry. You sound like a journeyman to me, and I can generally trust other journeyman programmers. We don't all need to be masters to have an industry, and that's probably not possible anyway. You say you can't implement TCP congestion control -- but you can build networked applications. Building networked applications is an ordinary job of the trade, and I'm sure you know how to do it in a number of ways. I also suspect that if you had to create some custom UDP protocol for something, you would be able to implement some form of congestion control for it in not too much time -- even if that involves searching for and copying a known algorithm, or if you're lucky finding and using a pre-built library flexible enough for your custom needs. That highlights two more reasons for why we don't hire librarians over developers. First is that, if you're at a journeyman level, then you can be trusted to handle the rather common scenarios where you have to do something for which there's no perfect matching library or framework or SDK you can just use. Whether you have to roll up your sleeves and go low level, relying on very little, or just need to be able to tie enough separate preexisting things together with some minimal glue to handle the new/different stuff, they're both activities that require a programmer rather than a librarian. (I guess this is just further elaboration of the already mentioned "there will be custom code not eligible for replacement by something reusable" reason.) Second, the task of a librarian to find software has been made much easier since the 90s with things like search engines, massive communication channels to share and find out about stuff, and massive open source repositories. It's so easy now that developers themselves can do a decent job at it among their other duties.

We've also seen decades of effort, much of it successful, aimed at making it easier. Programming used to be harder. (Difficulty alone doesn't account for high salaries.) If it was never "the hard part", what motivation for all that effort? Books, pedagogy, tooling, languages, even the notion of publishing a library is an attempt to make coding a related task easier for others. There's been comparatively less effort in making "the other parts" easier. Though certainly things like software development methodologies count.

I'm beginning to wonder if a lot of commenters have forgotten that waterfall is a failed methodology in part because you can't always just gather requirements by say introspection or interrogating the customer for them. In order to reveal the true, accurate requirements, you often need to write code. Not always, sure, just like some code is relatively easy to write, some requirements are easy to both accurately specify ahead of time and even satisfy. (An old XKCD hinting at this distinction: https://xkcd.com/1425/ Only nowadays we actually can easily satisfy a lot more of those old easy-to-specify-difficult-if-not-impossible-to-satisfy requirements. That's the way progress in the field often goes.) Decades of startups support the iterative approach, along with pivoting, the successful ones learning the lessons of writing less committal code and discovering requirements iteratively. And it's hard to actually pull that off -- so many companies have gone under or lost out significantly to competitors because they couldn't write code fast enough, or change code fast enough, either with the goal of discovering the real requirements or adequately satisfying those requirements once known. Code is hard in general.

Thanks for giving me a laugh, I was just imagining https://programming-motherfucker.com/ as an absurd "Hat-wearing, motherfucker" site instead.

That patio11 post was good but you're overstating its relevance here by suggesting the thread's central topic is missing the point. The fizzbuzz part even undermines the "Code was never the hard part" message. If code was never hard, why has it always been so difficult to find talent that can do the most basic of tasks with code? Why was it considered a good average for programmers to only bang out 1000-2000 lines of code per year, measured by observing a team over 15 years, when it was well known even back in those days that skilled programmers could produce a lot more, and deliver even more business value quicker?

Besides, there was a whole back-and-forth among multiple bloggers and comment sites (including here: https://news.ycombinator.com/item?id=3170766) from back then in response that agreed or disagreed with that patio11 post. Here's one: https://web.archive.org/web/20111126183459/http://www.jacque... Here's another (though a couple years later): https://yosefk.com/blog/do-call-yourself-a-programmer-and-ot... From the second one's conclusion:

> When I introduce myself, I usually call myself a programmer, regardless of my current work on chip architecture and management and stuff. I got into programming for the money, so it's not like I'm overflowing with pride when uttering "programmer". I just think programming is a great career and the right thing to call myself for me.

> There's an alternative approach where you program, but you don't call it that, and you use programming as a starting point from which you transition to some form of being involved in business as directly as possible.

> It sounds a bit roundabout to me – why not just get an MBA instead? – but maybe it's the right path for some (especially considering that some prestigious MBA programs want you to have industry experience before you can even enroll.)

> The important thing is to choose the path that suits your preferences, follow it consistently, and realize where your approach is most likely to succeed. Because where I work, someone applying for a programming position and not calling himself a programmer will not make a good impression.

Sometimes calling yourself a "Software Engineer", or focusing on "$X company revenue definitely attributed to my efforts" rather than the technical details, is the right thing to do. Sometimes it's not. In any case I'll continue explaining to outsiders that "software engineer" is mostly just a fancy term for "programmer", and to programmers to call themselves whatever they think will best give them a chance at working where, on what, and for how much money they desire.

> the text as they present it doesn't seem to mark vowel length at all

I think most Latin text out there won't use diacritics at all. I only studied it for 3 years back in high school leading to the AP exam and I don't think I was ever taught about them or saw them once. This video https://www.youtube.com/watch?v=D3bmLi1bKI0 and wiki page https://en.wikipedia.org/wiki/Apex_%28diacritic%29 were interesting. I'd bet part of the reason is just a side-effect of teaching Latin as a dead language where you never speak it / pronunciation doesn't matter. I remember very little of the language, I believe also in part because of that.

Why are you always surprised, especially if it keeps happening?

Even discount beef has worse discounts. My grocery store changed out the 50% discount stickers for meat at its sell-by date to 30%.

Turns out that even with the limited self-curation power X gives you it's not too hard to customize an experience you'll mostly enjoy; some people enjoy being miserable though. A large fraction of my "For you" feed is just neat artwork/fan artwork, which is peaceful. HN gets in "moods" with what gets to the top and I end up ignoring it for a while. Maybe one of these days I'll try one of the wrappers around HN that try to let you self-curate more. But despite that, for topics I do feel like engaging with, HN still wins by many miles. The "censorship" here is also very light-handed, whether from the staff or from fellow users; downvotes signal to authors that maybe their point of view is unwelcome and they'll be less inclined to post similarly, but they aren't outright removed even if downvoted/flagged to death. I've always had showdead on. I can also easily find stuff that's many years old, and read discussions from many years back that aren't full of "[deleted]" or other nonsense. (I got in the habit with old twitter to automate saving copies of images I've "liked", just like I save copies of videos on youtube I put in a "likes" playlist, because I hate it when things disappear out from under me.)

I have been disappointed that "Not interested" seems to have very little influence over anything on X, it does add some friction on shaping the experience to be what you make it. I pretty much never used the block (or mute) function pre-X, and now I've used it so much. Not just for the never-ending bots or blue-check click farmers either, sometimes it's just "that was such a stupid comment about Y; I'd prefer to deprioritize showing things related to Y, but at least by blocking I can ensure I won't see further remarks about Y from this person, or further dumb remarks from this person about some future Z". I have a little Tampermonkey script for HN that gives me similar functionality, "blocking" (more precisely muting) by username those I've decided I'd just rather not see comments from again for a variety of reasons. I never needed/wanted it before [insert date] but the HN decline has been real. (It just replaces the comment content with an "[unblock]" clickable, so it's cheap for me to give them an nth-chance to see some particular comment, and re-block if as usual it was also undesirable.) Staying out of certain HN threads entirely is the best self-curation one can do anyway, there are topics that just don't get reasonably discussed here yet keep being brought up.

News to me about FIFA. SA has been trying to gain "influence" in sports overall, and their video game endeavors also seem focused on "e-sports" more than gaming as a whole. I frequently hear complaints about them in fighting game circles, which is a more niche segment of "e-sports". EA is a big step up even if it's not DOTA/LoL levels.

It's more sad to me that it's usually just a second layer to the scam. People's empathy can be exploited just as easily if not more so than their intellect.

Like I ever answer my door lol. But they can leave something in the mailbox, and I'll at least see the envelope in 1-30 days.

Last week I finally had an onslaught of spam voicemails, several in an hour, that caused me to disable voicemail notifications altogether. I'll just check them when I'm expecting something now, similar to mail. My phone app was successfully filtering the calls so I wouldn't see them, but it still got routed to voicemail which then created a notification.

There is a correlation, though it can be weak (see for within-the-US: low-income parts in Appalachia). But even if it was as strong as, say, the correlations with IQ and Big-5-trait Conscientiousness on various life outcomes, it would still be factually wrong to state something as absolute as: "Ethics, morals and whatever people call only exists if economy is stable."

Maybe that's truer in other industries, but the history of Silicon Valley is at great odds with such a claim.

Some people predicted it and related things (like less writing output) after his Dwarkesh interview, especially with his flirtations with moving to SF and ever-increasing frequency of visits.

I believe that's what the first chapter is for. Kind of a hard problem in deciding what the sample should be, since if it was the first chapter those already familiar with the rules will be disappointed since they want to see applications, but those who don't know the logic rules will have trouble following the applications.

The limits of the team, even insisting on >1 person being able to fix any code written by the team, are probably much higher than the average of the team. Furthermore, the average isn't going to improve much if code is never written above it. This isn't to say go all out with the most clever code possible, or make things difficult for the sake of difficulty, but consider that it's possible to help upskill your team by showing them better ways (even if sometimes technically "cleverer ways") to write code. It's ok if something isn't as familiar to everyone initially -- exposure helps that. Do better code reviews, code walkthroughs, lunch & learns, book clubs, consultants to come in and teach something, there's lots of ways to improve as a team.

You can use most of the popular GUI libs, there's a couple Lisp-specific ones but they're not nearly as featureful. https://lispcookbook.github.io/cl-cookbook/gui.html collects most of them; though for gtk4 I'd recommend https://github.com/crategus/cl-cffi-gtk4/ But no matter what you use I think the experience is going to be a bit rough. CLOG is probably the most interesting non-traditional framework but you do have to accept some web idioms.

I'm confused by the GP's assertion that backends aren't a good fit because of the threading model, to me they're one of the best fits. The 10k problem isn't a concern for most software, and in any case there are ways around it. (I don't know what Google Flights does but even at their scale they haven't moved off SBCL. And Hacker News itself runs fine on SBCL, though there probably aren't 10k concurrent connections.) In the ecosystem, there's the https://github.com/fukamachi/woo webserver which binds to libev to handle similar scale as Go was advertising about 10 years ago. And besides some work going on recently on the SBCL dev mailing list to add native fibers/green-threads, there's been non-native versions of them before, and basically any concurrency model you can think of has been built on top of SBCL by someone. (STM, actors, async (one even built on libuv), channels, promises/futures...)

SICP, as beautiful and good as it is, is probably responsible for a large amount of the misconceptions and negative thoughts about Lisp. SICP isn't a Lisp book, it's a Scheme book, and the Scheme culture is at least as different to Lisp (Common Lisp and its ancestors all the way back to McCarthy) as Java is to Python.

Indeed. The behavior of arenas shared by multiple threads is important as well, and the proper use of destroy-arena vs. rewind-arena. Without care it's easy to create a leak in the unmanaged memory and the OOM Killer will come for your process eventually.

One should not read or pay much attention to anything Gould wrote or said. (http://cogweb.ucla.edu/Debate/CEP_Gould.html) The amount of damage Gould has done offsets any positives. It's not just even being wrong, indeed you can charitably read that quote as being almost correct (the phrase is "anatomically modern human"); the worst thing he's done is probably to mischaracterize the rest of the field as scientists believing things they don't (or haven't for many decades before he ever tried to address them).