When you start a new project, how much time do you devote to choosing the right language to use? That discussion is a major part of a recent article, “What is Code?” by Paul Ford in Bloomberg Business Week.
Admittedly, you don’t always have a choice. Few projects start from the ground up. Many of them are, instead, new modules or changes to existing projects and end up needing to be done in the same language unless you have the budget and time to do a rip-and-replace.
“It’s often better to just keep working and shipping, even if the code starts to look ugly, even if there are nominally better solutions, even as the technical debt accrues around you, because in a few years everything will change,” Ford writes.
Which is why we still end up needing so many COBOL programmers.
But at some point, you do get to write new code, and at that point you need to consider what language is the best for your purposes. Several factors come into play.
How fast is it? While some people like to focus on this aspect, it doesn’t really matter that much unless the program is going to be executing millions or billions of times, Ford writes. That said, a program written in C is likely to be faster than one written in Python, because C lets you specify details for handling the hardware. On the other hand, Python is easier because it provides more abstractions for programmers to reuse, Ford writes. “It hides much of the weirdness of the computer and many details of how computation is performed.”
How easy is it to program? Unfortunately, the same features that make a language fast can make it hard to program. That’s why we aren’t all programming in C, Ford writes, but in Python and various offshoots of C that make developing component libraries easier. “C, people said in the 1980s and ‘90s, is a great language! An excellent language!” he writes. “But it doesn’t really let you organize things. You end up with all these functions. It’s a mess. C doesn’t have a consistent way to name things. Which means it’s hard to find them later.” This leads us to…
How easy is it to reuse functionality? An important way to save money by developing programs quickly is to take programs that have been written before—either by someone in your own company or in another company—and reuse them, Ford writes. “A programming language has at least two jobs, then,” he writes. “It needs to wrap up lots of algorithms so they can be reused. And it has to make it easy for programmers to wrap up new algorithms and routines into functions for reuse.”
How big is its library? If a language is good because it’s easy to reuse functionality, it’s even better if it has a lot of functions written already, Ford writes, noting that this is part of the reason why Java has been so successful. “A coder needs to be able to quickly examine and identify which giant, complex library is the one that’s the most recently and actively updated and the best match for his or her current needs,” he writes. Frameworks and development environments are other mechanisms to provide this kind of resource to programmers, he adds.
How many people use it? This is where you get to the problem with COBOL—with some languages, it’s hard to find programmers because they don’t find the language fun, or because they don’t see it helping them find better jobs in the future. This also makes it harder to find other people to talk to and other modules to reuse, Ford writes. “You pick a language not just on its technical merits, or its speediness, or the job opportunities it may present, but also on its culture,” he writes. For example, he likes Python because its culture includes many conferences, frequent updates, vibrant mailing lists, and shared code.
Ironically, what much of this discussion boils down to is that the most important part of coding isn’t necessarily writing the program itself, but knowing how to research what code is already available that can be used or modified. “It requires you to have a map in your head, to know where the good libraries, the best documentation, and the most helpful message boards are located,” Ford writes. “If you don’t know where those things are, you will spend all of your time searching, instead of building cool new things.”
The rest of the article is pretty interesting, too (though it has some critics). It’s intended to help explain to people who aren’t programmers just what it is programmers do all day. Bloomberg ended up devoting an entire 38,000-word print issue to it, including fascinating facts such as that there’s 11 million professional programmers in the world. The online version also includes on-screen animations that help demonstrate coding, and corrections to the article submitted by readers through the code repository GitHub. If you’ve got a couple of hours to spare, check it out.
Simplicity 2.0 is where we examine the intricate and transitory world of technology—through a Laserfiche lens. By keeping an eye on larger trends, we aim to make software that’s relevant to modern day workers, rather than build technology for technology’s sake.
Subscribe to Simplicity 2.0 and follow us on Twitter. If what we’re saying piques your interest, head over to Laserfiche.com where you’ll see how we apply the lessons learned on Simplicity 2.0 to our own processes, products and industry.