grahamlee

This nil-swallowing behaviour works really well with the "out error parameter" pattern of Cocoa methods. In short, methods that can fail have a signature like:

- (id)thingThatSometimesWorks:(NSError *)error;

You can chain these to your heart's content. The one that fails sets the error and returns nil; following messages are sent to nil which does nothing and a particular characteristic of doing nothing is that it doesn't overwrite the error that was set. So you still get to see the error when the workflow finishes.

As an objective-C programmer, I also have a tool in my toolbox which gives NSNull the same message-swallowing behaviour as nil.

@implementation NSNull(GJLNilReceiver)

- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector { return [super methodSignatureForSelector:aSelector] ?: [NSMethodSignature signatureWithObjCTypes:"@@:"]; }

- (void)forwardInvocation:(NSInvocation *)anInvocation { [anInvocation invokeWithTarget:nil]; }

@end

Apple's documentation for the XNU kernel describes the scheduler implementation. https://github.com/apple-oss-distributions/xnu/blob/xnu-8019...

There's a lot of "Apple business model" answers in other threads, but I think that's at best a partial answer if it's an answer at all. To the extent that you can draw a line to "move the revenue numbers by tens of billions of dollars per quarter" from "choose whether to support this open standard API or create our own", which I think is a large extent, I think that line goes through performance. Apple now sell 120fps as a marketing feature. OpenGL ES was holding back performance of the graphics stack by not really being what people wanted to do with the GPUs and also not really what the GPUs were good at. Apple design the GPUs and the image/video frameworks, they know what APIs they can provide to get high-performance access to the types of task they need to be able to do.

interestingly, no. Temperature can become infinitely high, and you can still add heat, at which point it becomes infinitely low. You can carry on adding heat, and the temperature will get back to absolute 0. https://chemistry.stackexchange.com/questions/36885/how-is-n...

Before Sun Microsystems got very into GPLing their entire estate, Scott McNealy had a phrase that free software was “free as in puppies” in that you might get them for free but you’re paying every day after. Our author here doubles down on free as in puppies.

“Us sticking to 8 bit bytes” is a consequence of having preferred BCD to octal in the past, so the causation is reversed (“12-bit words would have made a lot more sense if it was, say, octal.”) [Edited: actually 12 bit words would make sense in either case, as it's three BCD digits or four octal digits]

The Intel 4004 used four bits to manipulate a single BCD digit. The 8086 had BCD instructions. There were many reasons for preferring BCD when designing computer architectures, though my favourite which was already becoming less relevant at 8086-time was that it meant a full column on a punchcard wouldn’t be “all holes” and reduced the likelihood of the cards tearing.

I’m the post author. If people are deciding what the article is about based on its title (and the title is nothing more or less than the name of the article’s subject), they aren’t people I want as readers. The title stays as it is.

This is the blog post’s author. The books aren’t even new to me, just new to many of the readers.

They do exist, but I do wish for more. We’re only a couple of decades away from software construction being a hundred years old (and a few from software _engineering_ being a century old) and I think it’d be wonderful to have some encyclopaedia-like resource that says “here’s everything we tried for the first hundred years, and why we do things this way at the end of it”.

For my part, I try to contextualise the way I/my peers work now with the other things we tried over my career, and maybe the decade or two before that which contextualised _my_ junior experience. For example, I run a monthly magazine with a colleague, and in our devops issue we discuss how ideas in DevOps come from manufacturing, from Rapid Application Development, and other inspiration (https://deprogrammaticaipsum.com/play-it-again-sam/). I just recorded a podcast episode where I look at _what_ documentation was considered “comprehensive” at the time of the agile manifesto, and what docs are still useful despite the industry-wide tendency to eschew all prose (https://www.sicpers.info/podcast/episode-47-comprehensive-do...).

Hi, I’m a Research Software Engineer (a person who makes software that helps academics/researchers) at a university in the UK. My recommendation is that not only do you publish the code, you mint a DOI (digital object identifier, Zenodo is usually the go to place for that) for the specific version that was used in your paper and you associate them. And you include a citation file (GitHub supports them now: https://docs.github.com/en/repositories/managing-your-reposi...) in your software repo.

Benefits: people who want to reproduce your analysis can use exactly the right software, and people who want to build on your work can find the latest in your repo. Either know how to cite your work correctly.

In practice drive-by nitpicking over coding style is not that common, particularly in (some) science fields where the other coders are all other scientists who don’t have strong views on it. Nitpicks can be easily ignored anyway.

BTW should you choose to publish, the Turing Way has a section on software licenses written for researchers: https://the-turing-way.netlify.app/reproducible-research/lic...

Take a look at TruffleSqueak on the Graal VM.

> Can you cite some examples?

Alongside the other examples in this thread, Donald Trump lost at least $1b during the first two years of his term.

> If it were easy, presumably a lot of people have done it.

The easiest way to lose a billion is to start with more than a billion, and there aren't really a lot of people in that position.

Conveniently I gave a talk on exactly this a few years back :) https://youtu.be/_BbGxpiYFDg

It's interesting when the creators had a clear intention to shepherd people one way and the programming community went another. Both Objective-C and Java (which was informed by ObjC significantly, including having a few implementors hired from NeXT) clearly intend for low level, C-style imperative code to be isolated early behind a message-passing interface and for systems to be built out of message-passing between objects. This is most explicit in Brad Cox's book describing the ObjC way, "Object-Oriented Programming: an Evolutionary Approach". In practice, a lot of Objective-C software and quite a lot of Java software is designed as big C-style procedures which call into APIs using object methods.

Similarly, the OP describes Perl, which is designed using a postmodern philosophy: however you think about your problem, you can solve it that way! In practice as OP describes many people reach for regex.

Those are comments on the implementation patterns in the Gang of Four book, which are indeed historically situated in the period of the book’s publication and relate to common solutions to problems then encountered. And indeed many of the non-trivial ones are interchangeable: what is State but a Strategy for handling time? What is Abstract Factory but a Strategy for creating objects?

Underlying this is the idea of a Patterns Language for programming: the idea that specific problems can be categorised into general problem shapes, that a satisfactory solution that fits the shape can be named, and that communication is aided by discussion involving those names. The idea of the patterns language is still very much relevant today. Whenever a developer says “this can be a redux saga” or “we’ll use serverless for that”, they are naming a general solution that they believe fits the shape of their specific problem.

This happened to me when the small company that I worked at was acquired by a large company, too. Smallco's engineering definitely had some dysfunction that I was trying to work on: speeding up information from CI, increasing developer confidence, empowering juniors to make the smaller decisions independently, that sort of thing. Then on the acquisition we were told that the most important priority was to switch over to the largeco's infrastructure. Our product was a Linux desktop app, largeco didn't support desktop Linux. Smallco was on mercurial, largeco needed us to switch to git. Our CI would be switched off entirely on a given date.

I left to join another smallco (I admit that I was among the earliest smallco employees to leave post acquisition, but wasn't among the last). From what I hear, they did eventually finish the migration but didn't do anything about the other engineering problems, with the result that they took a significant hit on their already slow rate of executing on the roadmap and a competitor that was previously thought to be moribund is now at feature parity, and has gained enough share that bigco have to list it as a key part of the ecosystem that they support, right alongside the smallco software.

I do not know what lessons have been learned inside bigco about this situation. I do know that I was quite a dick about showing that we were focusing on the wrong problems and slowing the organisation down, and that this meant I wasn't effective in getting higher-up support for the necessary changes.

I really enjoy working with Smalltalk, particularly web projects in Seaside. It's very quick to be very productive, and there's a lot of fun in fixing a failed expectation in the debugger and continuing to run your software.

Like the person you replied to, I vastly prefer ObjC, I find the compiler pedantry in Swift to be annoying and to slow me down. ObjC is very fast to write and to iterate on, particularly in my style where everything that's an object gets typed as `id` so trying new ideas just means swapping out implementations.

There is a wayland backend for GNUstep.

I co-host a GNUstep developer stream at https://twitch.tv/objcretain (replays at https://replay.objc-retain.com). The motivation my co-host and I have for using GNUstep in 2021 and beyond is to provide a familiar environment for macOS developers and users who are not happy with Apple’s direction and would benefit from a free software alternative. To that end we mostly work on the basic desktop tools like calendar, mail, and addresses, and fix framework/dev tools bugs and missing parts as we find them.

Agreed. The Agile movement/manifesto/alliance is a product of history and should be situated in its historical context when taught.

Yeah, scrum is the “nobody got fired for buying an IBM” of 21st century project management systems.

[I'm the article author]

> I've read accounts of the 1980s-ish days at MS, Apple, VisiCalc, and other software companies. > So far I have yet to read one which used waterfall.

Indeed, even the Royce paper everyone cites to describe waterfall doesn't even use waterfall.

Windows 11 and WSL2 will finally deliver the year of Linux on the desktop.

And what level of surplus are you happy to have added to your tax bills?

Typically you would pay for it out of grant money. So Dr. Smith doesn’t pay the APC, Stanvard University doesn’t pay, the NSF pays. Or to cut a long story short, the taxpayer.

Nonetheless old capacitors degrade, despite predating the plague. It’s SOP among retro computer folks to recap 80s/90s micros to avoid electrolyte damaging the boards, and I’ve had 80s-era Unix workstations go pop when powered on.

For most things I’d expect there to be no difference between the value of a computer with original caps _and no damage_ and one with recaps _and no damage_, because the buyer is going to recap anyway. For this Apple I, which is a museum piece rather than a hobby piece, I really don’t know if that holds.

They work in clang and gcc when you enable it, and C is not C++, so they work just fine thank you.

The solution for internationalist C users who want their source to look the same for everyone is to write the newline character as ??/n.

The date code on the capacitor is 1976 so I’m guessing not.