I use this pattern because then I can trust _everything_ in a collection. If an object, even an object that represents emptiness, receives a message, it will handle it and do something, even where that something represents emptiness.
706 karma · joined November 21, 2018
I use this pattern because then I can trust _everything_ in a collection. If an object, even an object that represents emptiness, receives a message, it will handle it and do something, even where that something represents emptiness.
- (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
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.
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...).
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...
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.
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.
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.
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'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.
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.