Strong opinions, weakly held

Tag: programming

So if your answer started with “because in C…”, you’ve been repeating a good story you heard one time, without ever asking yourself if it’s true.

Mike Hoye digs into the history of zero-indexed arrays in Citation Needed. Fantastic walk through the history of computing, and a fun reminder of how comfortable it is to leave our beliefs unexamined.

The near future of JavaScript

If you are a Web developer, you should check out Brendan Eich’s Strange Loop presentation on The State of JavaScript. JavaScript was supposed to be my 2011 skill of the year, but I really didn’t make any progress toward that goal and wound up learning other things instead. This year I’ve learned a ton of things, but not much JavaScript. In the meantime, JavaScript has become an even more essential skill for developers. As it turns out, I have managed to learn a fair amount of Scala and Hadoop since I wrote that post, and I’m learning Python right now as well. Maybe in 2013 I’ll get back to JavaScript.

Mark Chu-Carroll on the nature of computer programming

Everyone should program, or Programming is Hard? Both!

Mark Chu-Carroll explains the nature of computer programming in response to the general criticism that programming is difficult because it requires people to understand too much about how computers work. That’s not a great summary, so I’ll encourage you to just click on the link and read the article instead.

Life, the good parts

JavaScript: The Good Parts is one of my favorite computer books ever written, not just because it’s an excellent primer on JavaScript, but also because the title alone provides guidance to a way of living that’s worth pondering.

This week, PHP: a fractal of bad design is making the rounds. It’s a lengthy list of thoughtful criticism of PHP as a programming language (and Web development platform). The PHP core team should read it, although the truth is that most of the problems can’t be addressed without breaking old PHP applications, and the PHP folks are generally reluctant to make those kinds of changes. PHP has a massive installed base on shared hosting servers — breaking old applications reduces the adoption rate of new versions.

Here’s the deal, though. For all of the complaints about PHP, thousands of businesses rely on it, and millions of people use it with varying degrees of expertise. I personally have spent thousands of hours hacking on PHP applications, sometimes with much frustration. None of the problems listed in that blog post have prevented me from getting my work done in that time.

The secret to using PHP effectively is the same as it is for JavaScript … focus on the good parts. It turns out that works out for most everything in life. When I eat at a restaurant, I don’t have to like everything on the menu, there just has to be one dish that I enjoy. The number of bad dishes on the menu don’t really matter, what counts are the good dishes, at least if you willing to be an educated consumer.

We all choose the set of tradeoffs we’re willing to accept. I’m happy to take advantage of the opportunities working with PHP provides and do my best to stick to the good parts.

Writing readable boolean expressions

Fairly often I find myself writing complex boolean expressions. For example, let’s say I’m writing a function in a controller that renders a page, and I want to check whether the current user is authorized to view that page. Here’s some code:

if ((!($a || $b)) && $c != $d) || !$e) {
    // Do something.

Aside from the variable names, that’s real code. There are two things about that code that to me greatly hinder readability. I rewrote it as essentially the following:

if ($x != $y || !$z || !$w) {
    // Do something.

The second code has two advantages. First, no internal parentheses are needed, and second, there’s no mixture of “and” and “or”. Whenever I can, I like to use only one boolean operator in a complex boolean expression, because sorting out different operators can be confusing. In the second example, I know that if any of the expressions evaluates as true, then the code in the block will be invoked. When you mix operators, things aren’t so straightforward. And not requiring parentheses is related. When you mix operators, precedence comes into play, and you can use parentheses to manage precedence. So as soon as you bring either of them to the party, you can no longer read your expressions from right to left.

This just occurred to me so there’s probably something I’m missing, but for the time being, I’m going to try to be disciplined about sticking to one boolean operator at a time in cases like this. (And yes, I’m not counting the “nots”.)

Links for April 14

Links from March 14th

© 2024 rc3.org

Theme by Anders NorenUp ↑