February 17th, 2014
I bookmarked Mike Hoye's Citation Needed weeks ago but never got round to posting a link here. Unfortunately I've forgotten where I came across the link to this piece in the first place, but I can't let that stop me. If this is the sort of thing you like, you'll enjoy this a lot:
"Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration." – Stan Kelly-Bootle
Sometimes somebody says something to me, like a whisper of a hint of an echo of something half-forgotten, and it lands on me like an invocation. The mania sets in, and it isn't enough to believe; I have to know.
I've spent far more effort than is sensible this month crawling down a rabbit hole disguised, as they often are, as a straightforward question: why do programmers start counting at zero?
Now: stop right there. By now your peripheral vision should have convinced you that this is a long article, and I'm not here to waste your time. But if you're gearing up to tell me about efficient pointer arithmetic or binary addition or something, you're wrong. You don't think you're wrong and that's part of a much larger problem, but you're still wrong. [...]
December 26th, 2013
I'm always interested to read about the reasoning behind the decisions software developers make:
It took more than a year and three distinct attempts to get Google Docs in Basecamp … and still, the damn thing almost didn't get built. Why was it so hard?
We knew we needed it. Integration with Google Docs was a super-popular feature request, and usage in general is on the rise. Since Basecamp is a repository for everything project-related, it made sense to show the same love to Google Docs we show to any other type of file you can store in a Basecamp project.
Problem was, we don't really use Google Docs ourselves. [...]
November 17th, 2013
15 Sorting Algorithms in 6 Minutes. Be sure to turn the sound up – it's half the fun of watching how each algorithm works.
February 13th, 2013
It turns out that we might have a new culprit to whom we can apportion a share of the blame for the financial meltdown of 2007/8. After the investment banks, the credit ratings agencies, ineffective regulators, politicians who preferred to look the other way and a section of the public that was in thrall to the idea that living on credit was a good idea, bring on Microsoft, for making Excel so temptingly easy to use any time you need to juggle some numbers. James Kwak takes up the tale:
I spent the past two days at a financial regulation conference in Washington (where I saw more BlackBerries than I have seen in years – can't lawyers and lobbyists afford decent phones?). In his remarks on the final panel, Frank Partnoy mentioned something I missed when it came out a few weeks ago: the role of Microsoft Excel in the "London Whale" trading debacle.
The issue is described in the appendix to JPMorgan's internal investigative task force's report. To summarize: JPMorgan's Chief Investment Office needed a new value-at-risk (VaR) model for the synthetic credit portfolio (the one that blew up) and assigned a quantitative whiz ("a London-based quantitative expert, mathematician and model developer" who previously worked at a company that built analytical models) to create it. The new model "operated through a series of Excel spreadsheets, which had to be completed manually, by a process of copying and pasting data from one spreadsheet to another." The internal Model Review Group identified this problem as well as a few others, but approved the model, while saying that it should be automated and another significant flaw should be fixed. [...] After the London Whale trade blew up, the Model Review Group discovered that the model had not been automated and found several other errors. [...]
Truth be told, this isn't really Excel's fault. If Lotus 123 for Windows and the rest of the IBM/Lotus SmartSuite had won out in the early/mid 1990s against Microsoft's Office bundle, they'd be saying exactly the same thing about Lotus 123 in that report. The real issue is that spreadsheets by their very nature just beg to be used as a quick, interactive tool for iterating your way to a solution that's 'good enough'. As various commentators at the associated Hacker News thread explain, the difficulty is that – unlike a formal programming environment used by someone who has learned the hard way that all programs have bugs so you need to test for them – spreadsheets provide almost no real framework for testing and debugging unless the user (who as often as not knows nothing of programming beyond creating Excel spreadsheets and has a worryingly elevated view of their own competence) implements one for themselves.
The two articles are fascinating; I'm going to be following some of the links in that Hacker News thread for days to come. I had no idea there was such a thing as a European Spreadsheet Risks Interest Group, but there's no denying that there absolutely should be one.
[Via The Browser]
February 9th, 2013
I read not one but two pretty good pieces today on the practicalities of developing software. I'm not a software developer by any stretch of the imagination but I have just enough of a programmer's mindset to appreciate the amount of effort it takes to think through all the little bits and pieces that make a bit of software usable as well as functional:
- Hilton Lipschitz has made multiple posts exploring the decisions he made in designing his app TimeToCall. He covers the whole process, from his having the idea to write an app to help users arrange telephone conferences across time zones, right up to the point of polishing minor but important user interface details about translating the phrases used in the Japanese language localisation of the app without breaking his user interface.
- Mark Bernstein posted a piece describing the amount of thought that had to be put into adding a tab bar to Tinderbox. This is more focussed on a single user interface element than the Lipschitz piece: multiply the number of design considerations Bernstein describes for his one feature by the number of steps in the project Lipschitz recounts and you start to realise just how many decisions go into the making of even a comparatively simple application.
Neither article is aimed solely at programmers by any means – Lipschitz and Bernstein both explain in plain English the problems they're trying to resolve and the pros and cons of the different approaches they considered, so I think even people who've never written a line of code in their life will have no problem following either post.
One more, unrelated thing (courtesy of Hilton Lipschitz's Twitter feed). If you have access to a command line, go to it right now and type either tracert 22.214.171.124 (if you're running Windows) or traceroute 126.96.36.199 (for the rest of us.) Then watch and wait…
[Hilton Lipschitz posts via Brett Terpstra. I'm afraid I can't remember where I saw a link to Mark Bernstein's post.]
October 24th, 2012
A bit of programming language nostalgia, courtesy of a contribution from Rupert Baines to this Quora thread on describing programming languages in layman's terms:
Pascal. Your grade-school teacher. A bit prim, a bit prissy but at the time you thought she was the way everyone should be. Funnily enough, none of the grown-ups had the same high impressions and afterwards you can see why.
Modula – Pascal's daughter. Died young
Forth – she was a strange girl. Creative, idiosynratic, flexible (the things she did sometimes! WOW! It could blow your mind).
But a little bit Ayn Rand, a little bit survivalist: everything had to be self-reliant. None of this co-operation malarkey. Last you heard she was somewhere in Patagonia, where she'd built a complete city from first principles, using just the forest & natural resources, from her own unique design, her own energy and a lot of bloody-minded persistence.
That said, you still have a beautiful bracelet she made for you, from metals she smelted herself, from rocks she dug up in the woods & forests: "FORTH LOVE IF SMILE THEN !"
I have to admit to having had quite the schoolboy crush on Pascal back in the day. Forth, not so much.
August 5th, 2012
One for the MacOS X users: Brett Terpstra has come up with a neat little script for Launching your entire Dock at once.
And just like that, he solves one of those issues that's been nagging away at me for ages. I'd been thinking in terms of saving a plain text list of applications that I could point a script at, but his approach of extracting the list of applications from the Dock's .plist is so much more flexible.
July 22nd, 2012
Jeff Atwood's post about the response of Stack Overflow's users to a request for examples of New Programming Jargon includes some real doozies.
18. Common Law Feature
A bug in the application that has existed so long that it is now part of the expected functionality, and user support is required to actually fix it.
I have to admit that back when I was teaching myself Visual Basic for Applications, my work included multiple instances of Stringly Typed functions. Even now, I struggle against the temptation to leave Ninja Comments.
All in all, it's just as well that I'm not being paid to write code.
May 23rd, 2012
An Introduction to Objectivist-C:
Objectivist-C was invented by Russian-American programmer Ope Rand. Based on the principle of rational self-interest, Objectivist-C was influenced by Aristotle's laws of logic and Smalltalk. In an unorthodox move, Rand first wrote about the principles of Objectivist-C in bestselling novels, and only later set them down in non-fiction.
Here's what you need to know to program in Objectivist-C.
In Objectivist-C, there are not only properties, but also property rights. Consequently, all properties are @private; there is no @public property.
In Objectivist-C, each program is free to acquire as many resources as it can, without interference from the operating system.
April 11th, 2012
One for the geeks. PHP: a fractal of bad design is a positively epic evisceration of the design philosophy behind every geek's fifth- or sixth-favourite scripting language:
There is a whole lot of action at a distance. Consider this code, taken from the PHP docs somewhere.
What will it do?
- If PHP was compiled with --disable-url-fopen-wrapper, it won't work. (Docs don't say what "won't work" means; returns null, throws exception?) Note that this flag was removed in PHP 5.2.5.
- If allow_url_fopen is disabled in php.ini, this still won't work. (How? No idea.)
- Because of the @, the warning about the non-existent file won't be printed.
- But it will be printed if scream.enabled is set in php.ini.
- Or if scream.enabled is set manually with ini_set.
- But not if the right error_reporting level isn't set.
- If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.
I can't tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. And this is all built in behavior.
I only have cause to use PHP at all because it's what WordPress is built on, so I'm not in a position to evaluate how bad it can get when used to build entire projects. Python seems tidier and more manageable, but in truth I haven't had much call to play around with it beyond writing a couple of scripts last year to customise adding web browser tabs to Instapaper. Most of the programming I do these days involves either some combination of Applescript and shell scripts at home, or Visual Basic for Applications if I'm at work, so I'm not sure I'm that much better off than all the PHP jockeys out there.
[Via The Null Device]
January 30th, 2012
October 31st, 2011
Things That Turbo Pascal is Smaller Than:
Turbo Pascal 3 for MS-DOS was released in September 1986. [...]
The entire Turbo Pascal 3.02 executable–the compiler and IDE–was 39,731 bytes. How does that stack up in 2011 terms? Here are some things that Turbo Pascal is smaller than, as of October 30, 2011:
The minified version of jquery 1.6 (90,518 bytes).
The image of the white iPhone 4S at apple.com (190,157 bytes).
The Wikipedia page for C++ (214,251 bytes).
Not yet having made the switch to PCs at that point, I was probably still using HiSoft Pascal 4 on my ZX Spectrum, which was similarly minimalist by modern standards. But then, my Spectrum had 48 Kilobytes of RAM, so everything had to be distinctly minimalist.
[Insert standard "I feel so old!" lament here.]
[Via The Tao of Mac]
October 12th, 2011
"Reactive documents" is such a dull term: just go and play with the examples and you'll see how much fun could be had if your documents could act like spreadsheets.
[Via The Tao of Mac]
June 28th, 2011
Not a phrase you often hear used by IT support staff:
"Well," Rick sighed, "the user was right."
February 26th, 2011
A would-be developer for RIM's new Playbook tablet computer ends up having to jump through a few too many hoops on the way to getting RIM's software development kit installed and up and running:
You win. I concede defeat. I no longer want to attempt developing an app for the Playbook. Are you happy now? Surely you must be. Considering how terribly designed the entire process is, from the registration right through to loading an app into the simulator, I can only assume that you are trying to drive developers away by inconveniencing them as much as humanly possible. Just in case you've forgotten, let me give you a little recap of the process you've put together. [...]
The full post is well worth a read. Make sure you follow the story to the very end, where our budding developer gets a … surprising … email from RIM.
[Via Daring Fireball]
February 16th, 2011
Apple's Three Laws of Developers:
- A developer may not injure Apple or, through inaction, allow Apple to come to harm.
[Via The Tao of Mac]
January 31st, 2011
One for the geeks: PBS documentary Code Rush is now available for online viewing or for download under a Creative Commons license.
Jeff Atwood sets the scene:
Code Rush is a PBS documentary recorded at Netscape from 1998 – 1999, focusing on the open sourcing of the Netscape code. As the documentary makes painfully clear, this wasn't an act of strategy so much as an act of desperation. That's what happens when the company behind the world's most ubiquitous operating system decides a web browser should be a standard part of the operating system.
January 13th, 2011
Tackling your first significant programming project is invariably a learning experience:
About a decade ago, I landed my first grown-up job at a small IT shop. Not too long after I started, the company landed a project to develop an ecommerce website for a range of slimming products. Being that web development wasn't the company's specialist, they would subcontract these types of jobs to real web developers at our hosting company, and have folks like me coordinate the project work.
[I...] persuaded my boss that I was up to the task. Enticed by all the billable hours it'd bring in, he was happy to let me give it a shot and promoted me from general IT monkey to web programmer.
The project called for a shopping cart and, after reading a 30 minute "getting started" guide on SQL, I created my first database. I figured a Shopping Cart is a logical unit of data, and as such deserving of its own table. And since each Shopper had their own shopping cart, they should also have their own Shopping Cart table. [...]
Every paragraph reveals some fresh and hilarious hell. Wait until you see how he enhanced the security of his GUIDs.
There's a nice coda to the story; a reminder to anyone who has progressed beyond writing a program to print Hello World! that the important thing is to learn from your boneheaded programming decisions.
After a few more years a total cowboy programmer, I have since reformed my ways. Now I spend my time trying to help others in my organization steer clear of the mistakes I have made (though some people are determined to learn the hard way).
And for the record, the Bad Programming Karma I unleashed on the world has been paid back to me a thousand times over. I always have to remember: when judging others work, I shouldn't be the one to throw the first stone.