What to eat with my humble pie…?

Hmmm… well…. what to say, except “I was wrong”. At least from a certain view point

Having started some new projects from scratch I decided to give up and use one of the many available web frameworks (Perl/Catalyst MVC). And, well, it wasn’t as bad as I remember it being last time I did it. Although to be fair I did take over those projects part way through their development, and not have much time to learn the underlying frameworks before trying to complete the project on time and to spec. Anyway, that’s a poor excuse for not being objective enough in a previous post and declaring (rather dramatically) that all frameworks suck. It’s not true. Only some of them do (I’m looking at you Struts). Yeah, yeah, I’m biased against Java, so what?! I was forced into using it at work to support a project of a guy who left and did the worst job I’ve ever seen. Mostly by using EJBs to talk back to the same server to get data that could easily have been retrieved via sql.  Anyway, I’m floating off topic again.

MVC frameworks (and frameworks in general) do help save development time. Now that I’ve finally got my head around Catalyst (to some degree) and CDBI (to a greater degree) than I previously had, I can easily see how this is going to save me a lot of time on future projects. Granted the initial install (either via CPAN or other means) can be time consuming, but it’s a worthy one.

I’ve also just come across a nice comparison of frameworks (although it is over 2 years old so bear that in mind). Having read through the article and studied the graphs and data, I suddenly though, “Oh my God! I should have put that time into brushing up on Python and Django”. But having read through the comments, I realised my initial reaction was (one again) over the top. One particular comment struck a chord. The results in the article only show the finaly speed, and only in a limited scope (FastCGI), and also for a limited page build. A static page served via the frameworks is going to be less demanding than a dynamic page. And some frameworks are just always going to be faster. But what matters most (to me) is how easy it is to build a new page, or new functionality, or access a new database, not how quick the end app runs (although that does matter of course), but at the end of the day, the system admins can always help by putting my app on a faster server, or load balancing it, or adding better cacheing. If I can push a new app out the door in 30 days instead of 60 days, just by using a framwork, then I’m going to damn well do it. Speed is relative and really depends on your viewpoint.

We all want our apps to be the fastest. But development time, and correspondingly maintenance time and effort matter to. And at the end of the day, I know Perl, I’ve been using it for 12 years. I don’t claim to know everything about it, and I know I have a long way to go to learn everything I need to about Catalyst. So it doesn’t matter to me if Catalyst is slower to run on some random test, while I do appreciate the guys efforts to test and document the framework results, what matters is that I can build something quickly and effortlessly. At the end of the day that’s what frameworks are for, making my life easier…

The best post I’ve seen so far related to Chrome…!

Even though it’s got relatively little to do with agnostic coding practices I just wanted to point you to this excellent post related to the hype around Google’s new browser, Chrome. Deadly seriously post, but funny as well -> http://teddziuba.com/2008/09/a-web-os-are-you-dense.html

All frameworks suck!

By framework I mean the MVC crud (and I don’t mean crud as in MVC CRUD either), the stuff that other people spend ages writing that apparently speeds up your development process by a factor of infinity, but only until a) you want to write something that the framework doesn’t natively do, or b) you have a bug, and you can’t find it in your code and you suspect the framework, but hey why would the framework have a bug it’s being used by millions of people all over the world, surely?!, or c) well I can’t think of another reason but I’m sure there is one.

MVC frameworks are supposed to separate your logic, database, and purdy html code so that the poor developer(s) don’t get confused and start writing database queries inside html, or heaven forbid write anything where the framework designer said it shouldn’t be written. Godly delusions, that’s probably what leads people to write frameworks. Why would I want to use your 500,000 line framework when I can write my application in 500 lines, and make it a) work, and b) be quick, and c) scale it up without have to put the whole crudding framework on again and make sure I’ve got all of the 400+ dependancies installed and at the correct version?

Bah, just let me code.

Yes, of course algorithms matter!

Why would anyone think otherwise. The algorithms are at the very heart of the language. The language wouldn’t exist without them, whatever the language is.  And the particular algorithms that a language uses in it’s core libraries will make or break the languages use, because if the core is slow, all dependencies are slow too. Therefore adoption is stunted, and the language dies into obscurity. It’s evolution of the programming language.

Unit Testing

Unit testing should always be on your mind while you’re coding. Some people prefer to write the unit tests before the code that’s being tested. However I prefer to write mine afterwards. It’s a personal preference and each to their own. But which ever way you feel, unit tests are good. Unit tests are your sanity check, and a direct link to the reason you’re writing the code. If you have no unit test for a particular piece of code, ask yourself if that piece of code is necessary. If not, discard it. If it is necessary, then why haven’t you written a unit test for it? Hmmm? Go write one now then, before you forget about it…

The use of external modules…

…is highly encouraged. Split code into external modules, but not too many otherwise you will reduce your own thought flow as you flick back and to between them. And reducing thought flow leads to reduced code flow. Be logical, be consistent in what you put external to the main core. The core should be as small as possible, but not at the sake of clarity. If a particular piece of code doesn’t get used very often then make it external to the core. If it get’s used a lot, but it’s function is highly abstract or hard to visualise then make it external to the core. Only keep code in the code when it’s necessary, and when it enhances flow by making the core into 1 easy to read and understand module.

Obfuscation vs clarity

There is a time and a place for obfuscation. But unless you’re writing hardware drivers, or embedded systems, and therefore have a need to write your code in the smallest amount of bytes possible, there’s really no need for it. Obfuscation reduces flow. The reader can not adequately grasp the obfuscated code as quickly as clear and concise code. Sure if it’s a quick throw away script, obfuscate to your hearts content if you want to. But if the code is ever going to be maintained by anyone, including yourself then never obfuscate. Flow comes from knowing what the code is doing and being able to see where the code as going. Without flow there is no understanding. And without understanding there is no knowledge. And knowledge will help a lot more in the long run than slightly less bytes being used.

As a side note compilers are extremely good at optimising code these days, significantly better than they were just a few years ago. As optimisation is often given as a reason for writing obfuscated code it’s clearer no longer needed in the majority of cases.

The way of Flow

Good flow is a product of good coding. A program should flow like a river, taking functions from external sources and bringing them together to form the final sea of code. But isn’t the sea too big to view all at once. Yes but even the sea follows a flow that can be easily followed.
Without a consistent flow the coder gets lost, and thereafter the flow loses its way. The flow must be followed constantly. Any deviation leads to chaos and confusion. Think about all the times you’ve looked through someones code and thought, “wow, that’s ugly code, what was the developer smoking when they wrote that”. That is the sign of loss of flow.

Flow doesn’t simply mean other people being able to follow your code. It’s more about the way the code is written. From proper flow comes proper understanding and maintainability of the code. So what is good flow. Unfortunately it’s hard to describe, which will no doubt make you think “Aha, another misguided coder, think’s he knows all but knows nothing”. But good flow really is hard to desribe, it’s like trying to describe a painting by van gogh to a blind person. How do yopu desribe the winderful use of colour, the subtle shades, the shadows, the over all effect of the aubject itself. Coding is an art form, it’s not disciplined like engineering, it’s not as rigirous as a science, it’s controlled by the will of the coder, his understanding of the language and the problem to be solved, and yet the beauty in the code comes from the heart of the gifted coder, transcending thelanguage, the tools, and becoming one with the code. That’s good, pure flow.

The use of Objects and OO techniques

One of the rules that new coders should learn as early as possible in their training is to not make objects unnecessarily. The over use of objects is one of the many downfalls of the modern coder. Over objectifying your code leads not to re-use (as you’d hope for) but for obfuscation. Objects have there place in the agnostic coders arsenal of tools. But as with all tools, their use is limited, and definitely should be limited to the part of the problem domain that the use of objects can solve.

To take an example, the Java main function is an object. It has to be, the language demands it. But it doesn’t need to be that way. I’m not just picking on Java, but it’s the easiest example to take it’s needed for the simple “hello, world” that every text book will take you through.

But of course this isn’t restricted to Java, other OO languages are the same. But others are not. Take Python for example, a simple example is ‘print “hello world”‘, not complicated is it? And yet it’s in a language whose whole structure is OO based. So clearly using the best tool for the job is of paramount importance.

Most dynamic/scripting languages give you the option of pure OO or pure procedural, or a mix of both. Then again you can code like that in C++ too, so it’s really a matter of choice, which is one of the basic tenets of the agnostic way.

However, as long as you’re using objects for a reason, and that reason relates directly to the problem at hand, then use them, they are there for a reason, to be used. Just make sure you have a reason to use them, just like every other piece of code you build. If it’s not needed, dump it.

It’s hard to choose something…

.. as important as a programming language. So why bother? The agnostic coder doesn’t need to choose. He is at one with all languages, algorithms, and paradigms. Why? Because very few of these things actually matter. The language used is irrelevant. The paradigms shift and change like the seasons. The algorithms can always be improved, even if the mathematicians would have you believe otherwise.

So what is left?

What’s left is knowing what tool to use and when to use it. Knowing the right algorithm to use and why you’re using it. These two things are what matter most. They transcend the paradigms. They exist in each new language that is created, because they are ingrained into all languages. And yet no language encompasses all that you need to know about these two things.

Why do they matter?

The right algorithm to use is always going to be one of personal choice. “What?”, i hear you cry, “Surely the best algorithm is the one that works quickest”. Not so my impatient friend, not so. The right algorithm is the one that fits into the program neatly. It fits like a jigsaw piece. It makes the code around it feel complete, not forced due to speed or efficiency. Flow matters. And the right algorithm does not impede the flow, but gently helps the flow continue, never hurrying, never waivering, never stopping it.

“The right tool for the right job” is a truism is all professions, from the humblest of plumbers to the loftiest scientists. But what is the right tool for coding. That depends on the code to be written. But do not fall into the trap of the inexperienced coder. Examine the task first, then choose the tool. A carpenter who wants to carve a table leg has to know what chisel and mallet to use, but he needs to know what the finished table leg will look like first, lest the table leg become a matchstick.

Choose your environment well. Ask others what they would choose. But don’t be afraid of making the wrong choice. Good choices come from experience. Just like the experienced carpenter will better know which saw to choose, the inexperienced carpenter has to learn.

Only after you know what you’re going to build can you choose your language. However, the choice of language is not as important as how expressive the language will let you be. An artist could easily paint a blue sky on his picture with a painters roller, but he’ll be more expressive with a much smaller brush. Some languages are restrictive, other not. However you can only be expressive in a language you are comfortable with. If you’re comfortable with a restrictive language then use it, if not choose a less restrictive one, a scripting language, or whatever you feel happy with. Whatever you choose do not fall into the two most common traps. 1) Languages wars. 2) Using the same language for everything. Each language has it’s own merits. It’s own set of good and bad. It’s own idiosyncrasies. Some are well known, others not. Use each language for what it’s good at.

Do not fall for hype about a new language. The success of a hyped language is always outweighed by it’s inability to deliver on hyped promises in a few years time.

Each language is good in it’s own problem domain. Make sure you know your problem domain before choosing a language, and play to that language’s strengths. But embrace the weaknesses as well. Get to know the weaknesses of every language you can. This will help you decide which language to use much more successfully than believing you know what a language is good at.

In essence, be patient, know your problem, and choose your tools carefully. But remember that a rusty chisel is sometimes better that no chisel at all, but if you’d thought about it beforehand you’d have gone and bought a new chisel wouldn’t you?