Everything I believe. Rediscovered in the Snarkmarket archives.
Everything I believe. Rediscovered in the Snarkmarket archives.
By the smart Casey Johnston.
To the people proposing this:
You dumb bastards. You know who this’ll hurt? Not big media. Not on any significant scale.
No, the people this will really fuck over are the EXACT same people SOPA and PIPA would fuck: Creative professionals; small publishers; independent businesses.
I know many people who live and die with some of these shiny IDEs: nice fully-featured software to manage software projects. Design, code, compile, run, debug. Me, I distrust these great magnificient beasts. The good ones I’ve heard of work best when targetting certain platforms and languages, such as Xcode (for Mac and iOS software written mainly in Objective C), Eclipse (for Java software) and Microsoft Visual Studio (for C/C++/C# targetted at MS Windows). I’ve only worked with the latter, so bear with the gratuitous generality, but I’ve got the vibe that these IDEs feel cumbersome outside of their choice targets.
I’ve abandoned IDEs without looking back when I discovered the
bash shell and Vim. I have been fascinated with the ease by which complex tasks could be easily solved by snapping together a couple of Unix tools. Being a keyboard-loving touch typist, I found that a few scripts and Makefiles replace beneficially the GUI used for compiling and running software from IDEs. For the coding part, I fell in love with the multiplatform Vim editor. Two things are still done more easily in IDEs, though: interface design, of which I really don’t do much, and source navigation.
Now I have a nice trick for the latter.
Having just fallen in love with literate programming, I stumble on this hilarious piece. Not so sobering as just a reminder that not every problem is a nail. As I said earlier, literate programming is a tool to manage the complexity of a problem solved in software. However, when the solution is expressed concisely in a certain language or toolkit, it is thus a simple problem in this perspective. Therefore, there is no complexity to manage in its solution, hence no need for tools such as literate programming.
Also, good programmers are writers in disguise. Training to be a programmer? Take a good course or two in nonfiction writing. Thank me later when you have an edge in organizing discourse.
I will look like a complete Philistine, but this piece is my first serious exposition to literate programming. The times I had heard about this approach to software development, it had been derided as academical, unpragmatic and impractical — something that was of interest only to its pioneer, Donald Knuth. That that I can see it for myself, I think the ideas behind literate programming are utterly exciting.
Not that I think that the piece above got it completely right. Actually, its takeaway should be “do as I say, not as I do.” The author hits his mark when saying that the text segments between the code fragments should explain the why of the code, not the what. Explaining the what is repeating oneself, as the code is the what. Still, the author goes off and writes about the what of his code and not they why, so his whole program is a bit hard to read, in spite of being simple and fully documented.
The what is the code. The why lives as a second, third, nth degree within the code. What the text between the code should say is why some variable is made global. Why some functionality is spread between these three processes, these five functions. Why these things are coupled, when we know coupling is bad. Real-life code gets ugly, as programming is like packing one’s car trunk: you make decisions above decisions you’ve made previously from less information. It’s NP-hard!
Literate programming done in increments, supported by unit tests, should then document the decisions as they are taken. This documentation can drive future debugging and refactoring, avoiding contradiction and easing new developers trying to wrap their head around the growing code base. I feel that literate programming is a complementary way to manage the complexity bloom of software projects.
Its now a cliché that programs are parsed by computers, but read by people. I’ll add that if compilers have a right to complain that a program is unfit to be read, so should people. Programmers must communicate their ideas to people. They thus must be good writers. These days, we see many people embracing the functional programming languages and approaches that I had seen my coeds deride when we learned them in undergrad CS. FP is the old idea that’s become a good, fashionable idea. I feel that the next such concept to resurface will be literate programming.
Unsatisfied with what the author of the paper above has come up with, I have been checking out modern literate programming weavers-tanglers. Being a LaTeX afficionado, and wanting to experiment with multiple target languages, I’ve settled on nuweb for my initial experiments. Feel free to share your own experience with LP in the comments.
I have hacked together a simple personal wiki implementation in Vim, with the help of Exuberant ctags. I think the full implementation holds in less than 50 lines of configuration and Vim script code. Feel free to take a look at the project page. For the impatient, I might as well point to the GitHub page.
I am a member of the Vim cult. We hold no meetings, we don’t always know each other, we don’t all mock Emacs (at least I don’t), we just share an unlikely love for this lean and efficient text editor. Vim is like a good dog, it follows you everywhere you code, your faithful companion.
However, like a good dog, Vim requires some taming, some domestication (actually, Vim tames you — even out of soviet Russia). It has been said to have a steep learning curve, which I cannot deny. However, putting its commands at one’s fingers yields rewards of unexpected magnitude. Its bimodal approach to editing has been derided, but one does get used to it, and it then feels natural: now I’m reading, now I’m writing, and so on.
The steep learning curve, however, is best overcome in small steps. This is the main point of this great lesson in text editing by Vim’s original author and actual maintainer, Bram Moolenaar. Learn the basics, then learn the advanced features that allow you to be efficient in your own work. Practice until these new features have become second nature. Repeat as needed. As Vim only requires keyboard interaction and few chords, it enters easily in one’s muscle memory.
I’ve used Vim for more than ten years now. The next feature on my learning list: text objects. What’s yours?
Very honest piece. As a software developer of any walk or flavor, you work a market, so you have to sell something, to offer some value to someone. Making yourself hireable entails making this value explicit. So shine away.
Here’s a good quote out of the article that has prompted some bitter responses:
You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.
I get the bitterness, but I totally agree with the author. How do you think have computers become so important in this economy? They were born to run complicated and tedious calculations. However, they have taken so much market space because of automation: doing stuff that people use to do more reliably and more cheaply. Hence, putting people out of jobs.
I write some programs for my own uses. What for? Automating tedious tasks such as backups and data processing chains. I put myself out of these tedious jobs — good for me! But you know, ATMs were programmed by people like you and me, and because of these, you don’t get to speak to nice ladies when you withdraw a bit of the money you made doing so. Wherever we stand as software pros, be it developers, but also writers, teachers, executives of software companies or whatever, we all stand in favor of automation, some way or other, directly or indirectly, happily or sadly or blindly. What Patrick McKenzie says is that this shirt is mandatory dress code: if the collar chafes, you have got to change.
Back when I was working for my Ph.D., there was this post-doc in our lab who had this funny habit. He had this big roll of scotch tape by his computer screen. Every morning, as he sat down for work, he tore off a good length of that tape to bind his left-hand ring and pinky fingers together.