09
Oct
08

Forgive the geekiness

I realize that this blog is mostly about politics, economics and gender issues with a bit of business creation thrown in, but this post is going to be geeky as hell. You see, in my day job I am a programmer and I have been since around 1994.

This post is going to be about abstraction… the process that is so popular in programming these days of breaking code into small, small pieces that interact with other small pieces, and some of the standard practices that are around that are just stupid ideas.

Lets start with databases… maybe it’s because so many of the people I work with weren’t around in the early nineties, and they were introduced to the industry after SQL became widespread that they don’t understand exactly what it is that they are doing when they write database abstraction classes that remove writing actual SQL from their code. See, back when I started out every database was accessed differently. You had to learn a specific language for that DB and often that meant you were programming in whatever flavour of the month you were using. In C and Assembly Language it was worse. You created the database and the access methods most of the time (only if you had a lot of money for the project could you use one of the SQL based DB’s). This meant that you had hundreds and hundreds of pieces of syntax floating around in your brain just to get the information your program needed to function. SQL ended all that. There were minor differences (this database supports limit, that one doesn’t, etc.) but for basic tasks like reading, updating, inserting and deleting simple data you were fine. This actually led to a lot of the web 2.0 revolution. Now that it was easy to figure out the database end of things and you could get a free database that did everything you needed, you were welcome to concentrate on the more important bits.

Now, everyone creates a class for accessing SQL. Some kind of Active Record beast that uses a custom syntax (instead of SELECT * you type findall… etc.) They object oriented methodologies to make it an object that has methods you can access. In the end it just means that you have to learn a unique syntax for every project you work on and you have hundreds of methods for accessing a database floating around in your head…

Another big guilty party is the whole idea of MVC and templating. Every MVC system I know of uses a templating system, often Mako templates, but maybe something else. Now, instead of learning the language you are using, you have to learn at least three languages. You have to know HTML because that is the main presentation language and if the content isn’t presented in HTML you are not going to be able to output to a web browser, and since most business programming does output to a web browser these days… of course you have to know that actual scripting language you are using (python in the case of my day job, sometimes c, sometimes php, etc.) and then you have to know Mako. Mako is a bad language. It is a cludge of a clusterfuck designed to abstract programming from the person building the page, but one that still supports variables, conditional branching, looping, basically all of the features that make a programming language a programming language. Technically you could make a Mako template that accepts no data from anywhere and have it actually be a program… although without something feeding it data it would always display the same thing as it is lacking any input methods. Hell, combine it with some JS and you could have a decent web app… oh yeah, make that four languages for a modern app. The worst ever offender for this is PHP using Smarty. PHP is a templating system folks, it isn’t even all that much more powerful than Mako… more functions and some actual input abilities, but at the base you could create a page that was identical to a Mako template in every way except that it used the slightly more elegant PHP coding where Mako has its cludged together crap-tacular coding (this is a real, honest to god, function call within a Mako template: ${h.form(h.url(action=’add’, method=’POST’))} and something that is the equivalent in PHP <?php form(url(‘add’,’POST’)); ?>, how in gods name does Mako add anything to that?)

Lets talk MVC. For the uninitiated, MVC stands for Model View Controller. It is a way of breaking program down into standardized blocks. The Model describes the data the program will use. It provides an access point to the database (for your incredibly awesome Ruby on Rails Active Record implementation). Just to be clear, this means that you have to define your database in two places, inside the actual DB and in your model… they match because your model takes care of creating the DB structure for you, but in reality that DB structure now exists twice. Then you have a view. A view is bits of code that feed data to Mako templates and decide which Mako templates to use (or some other template schema… but usually Mako). Again, you create memory variables which feed Mako memory variables. Finally, you have the controller. The controller takes data that the user supplies and data from the model, does various things to it (like summing up a bunch of numbers or deciding which names belong in a list of top customers) and feeds them to the view. It is yet another step in the ages long quest to turn programmers into assembly line workers. All of them doing the same thing at the same speed. In the end it produces code that can only be read if you are using an Integrated Design Environment that will find where something is actually declared for you, because you can’t possibly decipher the damn program yourself. The argument has gone from VI vs. Emacs to Eclipse vs. Microsoft Visual Studio. VI took up a few kilobytes of memory, same with Emacs. Eclipse can take up hundreds of megs of memory. Even worse though, programmers are losing the ability to think. They are in fact becoming assembly line workers, the creative spark beaten out of the ones that possessed it.

Object Oriented Design was the beginning of this. The idea is that in the real world there are objects, each object is made up of smaller bits, other objects, that have the properties of the parent (oddly enough, that system of human classification breaks down very quickly under scrutiny, but is the reigning metaphor for software development). In practice it means that when I want to say, get the name of a user, I don’t type something like getUsers(‘bob”), instead I type something like function.users._user.getUsers(“bob”) and if I want to change what a user looks like I have to figure out where the hell the code actually is. Thankfully I have an IDE so I can right click on getUsers in my code and select goto definition, or whatever the equivalent of that action is in the IDE I am being forced to use at work this week. When I started, I would look at my include lines. One of them would be called something like “users.c” and I would open it. Then I would find (by quickly scanning this fairly small file that was just functions that dealt with users) the getUsers function. Then I would make the changes I needed to. See, I did object oriented design right before doing it wrong became the way of the world.

Bad programmers produce bad code, if it is object oriented code, they produce bad object oriented code. Good programmers produce either good code, or JAVA.

I didn’t realize I was this angry about this stuff until now.

Advertisements

4 Responses to “Forgive the geekiness”


  1. October 9, 2008 at 7:34 pm

    Sweet post.

    Being a big proponent of OO, MVC, ActiveRecord and all that crazy crap I see things differently.

    First of all, you have to think about corporate lame-o software development means. It means you have ten or twenty people working with each others’ code every day. As well, people aren’t emotionally invested in the code or the company to a strong degree so a developer could leave his job suddenly. Those who are left (and those who are newly hired) have to maintain buddy’s old code.

    Developer Alice goes in and writes users.py and defines getUsers to return a list of dictionaries where the keys are the fields in the user table. Developer Bob writes getWidgets and returns a list of indexed tuples whose positions are the fields in the table (keyed by some constants that map to integers). Developer Carl thinks the whole thing is dumb and refuses to write sprockets.py because it’s simpler to write queries in raw SQL. Who is right? They all are. Given context each approach is valid. And with today’s multicore multi-gigahertz holy-crap-it’s-fast processors each approach will be fast enough.

    So then Developer David walks in and he doesn’t know what to do. He’s got three completely different interfaces for business object things. He goes to Alice and she explains users. He goes to Bob and, well, Bob is in a lot of meetings and doesn’t have time to chat. And Carl, well, he moved to Mountain View and is working for Google. So David has to read all that code and try and figure out the mindset of the developers who wrote it. Then he has to memorize all the interfaces. Maybe then he can get some work done. Though a system with only three business objects is pretty unusual. How many exist in our current project? 20? 30? 50?

    The idea with OO, modularity, and libraries is that you don’t have to memorize as many interfaces for objects. You do, however, have to memorize those libraries but at least that documentation is collectively maintained across projects (assuming you’ve picked a project with good documentation. Like Pylons. Maybe not like Pylons. :\)

    Now, a good developer writing good code can write modular and useful code without any straightjacketing OO libraries. Fact, not everyone is a good coder. Fact, even good coders write terrible code sometimes. I know I’ve written lots of it. email me and I can give you a tour of my mistakes…

    Of course these OO libraries are straightjacketing. They DO try and turn programmers into asssembly line workers, because most companies need assembly line code. Most companies don’t even need good programmers, just acceptable programmers.

    What’s a good programmer in a corporate programming job to do? Try to find ways to tailor the straightjacket to not suck so much, and to reduce the ways of making mistakes. (Often OO libraries don’t prevent mistakes, they merely move them to another level– no more SQL syntax errors, but goofy object operations galore). If you think foo.bar.models.users.User.find is goofy, find a way to make it less crappy.

    I don’t know… I don’t think I’ve really argued very well here. Just throwing in a few ideas to muddy the waters.

  2. October 9, 2008 at 7:56 pm

    I actually know the arguments… but I just got a look at some Mako templates that were missing from my project and my brain snapped.
    To me, the biggest thing isn’t even the division between good and bad programmers it’s the division between types of programmers. I believe that there are conceptual programmers who are best at high concept work, and there are production programmers who are really good at the day to day function building and the like. Guess which category I would place myself in?
    Also, I believe that the answer will vary from company to company, situation to situation. When I am creating something from scratch I am actually very, very structured in the way I do it, but I create the structure to match the project.
    See, I hate the death of the art of programming and the rise of the business of programming. I know it is inevitable, and I know that MVC, OO, all of that is inevitable… doesn’t mean it doesn’t kill a bit of the anarchic, creative spirit in me every time I have to type class.method(options) or use a freaking Mako template (damn I hate Mako…)

  3. October 10, 2008 at 1:18 am

    How many projects have you tried to use PHP as the templating language? I’ve done a couple (partly based on the Mozilla project’s denouncement of Smarty, which I had previously been using, as one of the main performance problems behind an older version of addons.mozilla.org). After using 2 systems (Smarty, Cheetah), studying Blitz, HTML::Mason, and HTML::Template, and designing 3 or 4 myself (mostly in raw PHP), all I have to say is that templates are nigh impossible no matter how you slice it. I used print a few times when I was new to this Web stuff and could barely operate CGI.pm, too, but those days are long past.

    My main problem is that I want to keep template-specific CSS and JavaScript in with the HTML, yet render incrementally. That can’t happen unless you compile the templates or have a two-pass interpreter, because the stylesheets have to be linked to from the HEAD. Another problem that seems to trip up a lot of template languages is that they look down on the designers as “dumb” and/or try to completely separate “presentation” and “logic”. But presentation logic, although it is logic, still belongs in the presentation! It’s just something we don’t always see when we start designing a “lite” template system.

    The advantage of Smarty over PHP is that they’ve put in a bunch of conveniences, like (IIRC) the html_options function, and it’s easier to work with simple braces than the PHP open/close tags. But I’m convinced (through hard-earned experience) that trying to stuff all your variables into a cannon and blast them into a template in one shot is the wrong approach.

  4. October 10, 2008 at 3:44 am

    See, I prefer PHP on its own to any kind of templating I have used. The smarty braces really don’t seem to be an advantage to me.
    I used Smarty as the main presentation system for a major project on one job. Everything was smarty with Mako templates, and I never became convinced that there was a single advantage. PHP has incredible support for HTML when you dig a bit deeper. I have done… dozens? I don’t know exactly, for a period of about five years I was a PHP dev primarily, of projects that used PHP for the templating. Again, because I tend to be pretty rigorous I used PHP as the logic and the presentation but I didn’t use both in the same file. I broke things up pretty heavily. To me (and this is just my opinion) the reality of templating is simply learning more syntax. I have never dealt with a graphic designer who actually changes that code… they create a design in photoshop and then hand it to the programmer to build. I used to be that programmer often (I worked for a bunch of design agencies). I really like the flexibility of PHP for light web apps (I actually think printing your HTML is better than templating… both use the same resources but one of them at least removes a layer of syntax and complexity from the project).
    My other big issue is very simple… I think all this crap we add into projects actually makes them harder to work with. It turns out that this point of view seems to have at least some basis there have been a couple of studies that show that more abstracted projects, in addition to having more lines of code, take longer to maintain than well coded projects with less abstraction. It turns out that a lot of people find it easier to work with more concrete concepts. A query return a simple array in PHP, an object returns some sort of structure created by the programmer of that piece. If the programmer left good documentation and it is easy to find the code that contains the documentation… great, otherwise it could take a lot more effort to track down the actual data.
    Python has the same issue (although it is a tuple, not an array). Our quest for standardization has actually left us back at the mercy of an architects vision, but now we can’t even find the map to the vision…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: