ajarmst

Looks like someone else mentioned PAIP. I’d add “The Art of the Metaobject Protocol” as well.

The author's about page reports that he is a former physicist with experience in automotives and law enforcement. It also contains the statement "I have a particular dislike of self-anointed 'experts';" with no apparent irony.

And my personal favourite: "People may think I’m fighting above my weight class, because many of the people I label as clowns are on television and in important newspapers, much like the stars of 'The Bachelor.' "

Uh huh.

If they're so easy and obvious, why hasn't the author done it, at least as a demo? The article also reeks of "this doesn't work for me, therefore it won't work for anyone" I doubt I'm the only one who absolutely does not concede that everything should have a GUI interface.

"Why does shit like DPDK exist?" I don't know, but I bet you could find out with a little investigation, which might make this sound more like a well-researched position and less like a tantrum.

"people who absolutely insist that the Church Turing thesis means muh computer is all-powerful simulator of everything". Yeaaah...we're done here.

Which episode has a crash that (1) they failed to find a primary cause for and (2) would have been solved had they had video?

Thanks for the clarification.

It would be less useful than you’d think. Pilots are trained to articulate what they are doing and generally follow very well-practiced procedures. Another pilot can quite accurately reproduce what a pilot is doing just from the transcript, and the warning horns and other indicators are quite expressive of other things. The audio is good enough to hear breakers opening. Anything a video camera could see out the window that would be relevant will be remarked upon by pilots.

There’s an interesting aside in that neither a CVR nor a FDR would have been helpful in figuring out the cause of the Comet disasters. The way they did was brilliant.

The article is interesting, but that lede is incoherent. Many mathematicians accept computer proofs the way chess grand masters accept computer players. Computer “assistants” that generate proofs that humans cannot follow or understand will always be controversial, and the proofs they generate, even though accepted as valid, will always be decorated with an asterisk.

When I teach coding, I used to have a similar lesson around commenting code: "don't tell me you're creating a variable. I can read the code. Tell me what the variable is for."

I still mostly abide by that, but I've had an opportunity to write some larger programs for the first time in a few years (a hazard of teaching programming is you find yourself working with pretty small programs), and noticed that the comments started become a part of my conversation with myself. I'd drop in quick reminders for what I intended to do in a function before going moving on to something else. When I came back and then wrote the code corresponding to the comments: well now it's redundant, but it wasn't. I stopped cleaning that stuff up (I'd clean it if I had to present or publish it, of course). The comments kept some context of my thinking when I wrote it, what order I did things in, etc. It would be gibberish for another, but it wasn't for me, especially after a few days, or even longer. (Note: I'm a pretty fast touch-typist, so muttering to myself doesn't invoke much of a productivity cost. I also note that commit messages are another great place to capture that sort of context for yourself, and not using that opportunity is a sin.)

So, I've changed some of my greybeard aphorisms around commenting: "When commenting code, consider the needs of the person who will be maintaining this code. Who will probably be you. Be nice to future you."

Felleisen is an ACM Fellow with a senior tenured position at Rice. American, white, middle-aged. Doesn't have a presence in social media. He'll be fine.

That seemed like an awful lot of words to describe the entirely predictable fact that the job market will pick up significantly as we shed pandemic restrictions and that workers in low-wage service jobs tend to quit a lot. A few anecdotes about people liking WFH doesn’t make the trend any more mysterious or novel.

Why would I use this and not Pandoc?

"nor are the skills of writing good documentation even vaguely similar to those for writing good code". I disagree. Vehemently.

I always liked the way he responded when asked (many years later) why he did it. Paraphrased, it was along the lines of "It was so obviously the right thing to do, but it would have been nearly impossible to push through the bureaucracy, so I just went ahead and did it myself." He did something so profoundly good that we are compelled to wish we could live up to such an example, and the reason he did it? He didn't really have one. It just never occurred to him not to do it. Which is as good a definition of "hero" as you're likely to run across. "Righteous among nations" indeed.

The only problem here is that the author perceives a need to apologize, or to even feel regret. If the only compensation for starting and maintaining an open source project is the work itself or personal use of the product, then you are your only customer. The moment it stops being fun or worth the effort, you have every right to just stop without feeling a tiny bit of guilt or remorse.

You have a bug they want to fix or a feature they want to add and the author/maintainer is not doing it fast enough? Fork away! Submit a pull request! Oh, you don't have the skills/time to do that? Wow, that's too bad. Offer to pay the author! Post a message to the project list or bug reporting tool offering to pay someone to do it for you. Oh, you want it for free? Immediately? You built critical infrastructure around a tool you don't understand and don't have the skills or resources to maintain? You're a parasite, and can be safely muted and ignored.

This is the important bit: If you're afraid the person maintaining your key infrastructure for free might suddenly stop doing that, just take some time to send them a nice note thanking them. Periodically getting one of those in your inbox is remarkably effective in maintaining passion for a project. Find a way to give them a gift. Do they have Venmo/Patreon/Amazon wish list? Use it. Are you a developer or do you employ some? Fix a bug. Say nice things about them in social media. Offer to help pay for the resources to host the project. Send them an effing Starbuck's card with your sincere thanks.

"No one would go to a restaurant where each dish requires a paragraph of text to really appreciate the taste and texture..." One assumes that you've never eaten with a 'foodie' or attended a wine tasting.

The author has a pretty good CV, but as his Wikipedia entry notes, there is a concerning history to some of his publications. The WP entry cites several expressions of concern, which are worth a read. See, in particular, the note at the link below from Retraction Watch (one of the better sources for checking a researcher's bona fides):

Researcher who threatened Retraction Watch with lawsuit corrects funding source for several papers (https://retractionwatch.com/2013/10/17/researcher-who-threat...)

The argument made in the article seems well-supported, but I'm not competent to evaluate it. Given that this is an un-reviewed letter to the editor from a single (albeit apparently quite well-qualified) researcher, I'm going to wait for more (peer-reviewed) evidence before trying to form an opinion.

I bet you hate Elizabeth Holmes. I wish your sex wasn't relevant, but unfortunately it still is. I genuinely wish you well. We've seriously needed more (hell, any) diversity in our leaders and decision makers for a very long time.

The part I found interesting was that the author notes that it is well-known that the quality of the work has little to do with its odds of acceptance even when the system is 'functioning' as designed. Is it cheating to game a system that is already fundamentally broken? If the quality of your work is inadequate to secure publication and your career depends on it, it wouldn't be very hard to convince yourself that you can't cheat a rigged game. What 'integrity' is actually being threatened? Perhaps some of the energy devoted to identifying these collusion rings would be better spent developing a review process that is at least somewhat biased in favour of good research rather than the density of the authors' professional network. Or at least in mitigating the poisonous 'publish or perish' rules that lead to this sort of phenomena.

However, his Doctorate is in Chemical Engineering and what field and area for his postdoc research isn't identified. A postdoc Chemical Engineer wouldn't normally be working on the theoretical foundations of quantum mechanics. I also have to assume that the claim that he is retired after a "[p]rofessional career in the industry" means that he is a retired Chemical Engineer, not a postdoc researcher in quantum mechanics, despite identifying his alma maters as his research affiliation with only a tiny footnote disclosing that he is 'retired'. This is also the latest of multiple attempts to publish this work over a period of years---and is apparently only the second paper he's written.

If he has indeed 'refuted' Bell's Theorem (and thus undermined the foundations of large swaths of theoretical Quantum Mechanics), one might expect he'd have at least one collaborator, a current research affiliation, and the interest of a journal with an impact factor greater than 2. It's possible he is the mythical solitary untrained genius, shunned by the establishment and producing Nobel-prize caliber research in his basement. That's probably not the way to bet, though.

More evidence that, no matter what horror finally consumes us, we will thoroughly deserve it.

I don’t think you can meaningly disentangle “information” and its representation without doing violence to the underlying theory. Nor is a discussion of “symbols” coherent without a reference to the information encoded. Grounding the idea of information in the logical and physical limitations of representation is part of the genius of the theory, not an unfortunate epiphenomenon.

I was a backer for their previous project: Turing Tumble. It was a very positive experience, with timely informative updates and ultimately a high quality product.

The link to the cm-unicode project cited in the article is broken. Interested browsers can find it at https://cm-unicode.sourceforge.io/

Well, now I’m embarrassed. I had been operating (apparently for decades) on the assumption that Hobb was male. Which is pretty bloody sexist on my part. I apologize to you and M. Hobb. (I interpreted the “he” correction as a reference to my use of the word spay, not bothering to confirm that it was made in earnest. The “identifies as” was meant as a weak joke. Which seems to have spectacularly failed. Again, sorry.

I believe Hobb identifies as male.

I’ve just been assuming that Sanderson will step up to finish those series when the original authors pass.

I’m waiting for the news that PETA activists have captured and euthanized Robin Hobb to end his suffering. After spaying him, of course.

I agree completely that you shouldn’t be digging into that stuff unless you have a reason to and possess the appropriate competence. But the reasons for doing that is the same everywhere: (1) complex systems are difficult and subtle, and (2) “premature optimization is the root of all evil”.

In fact, Knuth’s aphorism is a much better description of why one should avoid the complexity of this issue than a clearly incorrect argument proposing that the distinction between storage classes doesn’t exist, that 1975 programmers were ignorant of storage abstraction, and that this issue has become less complex over time. (Edit: corrected typo. Programmers in 1075 were definitely unfamiliar with storage abstractions.)

I find this to be a bit of an oversimplification. It's certainly not the case that there's only one type of storage, at least from a hardware perspective: there will always be storage that is faster than other storage, and managing that will always be required to optimize performance. I agree with the author that you should program against the simplest abstraction you can, but that's not always clear. Just because your environment is one in which you don't have to doesn't mean you can't or shouldn't in the right circumstances.

I'd argue that it's actually more complex now. I programmed in the early 1980s, and did have to worry about where my data physically resided inside the machine, but I never had to worry about whether it was in a different room on a different machine, or sitting on a hard drive in some Amazon Data Center a continent away.

As others here note, the idea of using the same abstraction for all storage is at least as old as MMUs and Multics (mid 1960s). What is different is that programmers in the 60s and (early) 70s were usually coding pretty close to the bare metal. Nowadays, Moore's law has allowed us sufficient power to permit programming on top of a big pile of abstractions that try very hard to hide the actual hardware from us.

That's a luxury afforded by the sheer power of what we're working with, but the people writing those abstraction layers still have to pay attention to the layer beneath them, and if you go down far enough, you'll find some code that needs to pay attention to what class of memory something is stored in and how to optimally move it around. It's just that work was probably done for you by someone else who wrote your operating system.

Just because your programming language doesn't require you to use pointers doesn't meant that indirection isn't being used. You just don't have to deal with it (until it rears up and reminds you it's still there). Joel Spolsky's Law of Leaky abstractions (https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...) is relevant here.