Oh great, another new paradigm to get your head around
Concept Oriented Programming. Go figure. Spend more time coding and less time thinking about new ways of wasting time.
Concept Oriented Programming. Go figure. Spend more time coding and less time thinking about new ways of wasting time.
I’ve long held the belief that the only way way to learn is by doing. This is true of any craft or art form. You can’t learn how to paint pictures just be looking at other’s art, and you can’t feel the best technique for a dove-tail joint from a book. The same is true of coding. I’ve read a lot of books, and while they were (mostly) all (mostly) excellent tomes with (mostly) good examples, the best way to get your brain to understand things is by doing it.
I’ve been “learning” Python for quite a while. I say learning, more reading the tutorials and docs and then not having the time to use it for anything big I then forget what I’ve just learnt and curse myself. However, having finally started on a project on GAE I’ve learnt (and remembered) more in the 2 hours I’ve been knocking up my test app than I ever did by just skimming the docs. And that goes for GAE too.
“My language is better than yours at doing X!”
“Yeah, well mine’s better at doing Y!”
Yep, we’ve all been there, well most of us have I’m sure. Someone likes Perl. Someone else likes Ruby. Someone else likes Java (really? you sure?! just kidding
)
Here’s a classic example that popped up recently http://blog.obiefernandez.com/content/2009/04/my-reasoned-response-about-scala-at-twitter.html. The article itself is well readable, although it does come across quite critical of Alex Payne, and of the use of Scala at Twitter. But the comments are pure flame bait.
There are countless similar examples all over the Googles back yard (or the Internet as some call it). So why drives people to start flame wars? I’d hazard a guess it’s the same thing that drives all wars. Religion. Of course some people wouldn’t call it that. Think of it as belief in your a programming deity, where each language has its own deity, and belief system. Java followers pray towards the Sun HQ, Ruby devotees bend their knees towards Japan, and Perls acolytes simply grow longer beards and get on with the job at hand. But whatever faith/language you choose there are ways to piss off the other guys, the ones that don’t believe the same as you do.
And the sad part is that there is nothing to be gained from flame wars like this. I would very highly doubt that anyone from camp A has been persuaded to give up their language of choice and side with camp B just becuase they read a ranting post in a flame war thread. Have you? Seriously?
The fact of the matter is, in 99.999% of situations language A is going to work just as well as language B. Yes there are fringe cases. Yes there will always be ways you can make it look like language B is faster. An unbiased benchmark of all current major languages in every possible permutation is of course impossible. So how do you choose? Do you have to? Well, yes, I’m sure some of us do. Most of us will be forced into using a particular language via our job, via our experience. But for those projects where you can choose the language, how do you? How about this?:
That’s it. Simple, yes?. Good. Right, now stop writing incediary posts on blogs and twitter et all, and spend time sharpening your skills. Then when the time is right, and you really do need to argue why your language is better suited to a particular implementation you’ll know the ins and outs and gotchas of your language better than the other guy, because he won’t have read this and so he’ll still be starting flame wars that don’t matter.
Have fun!
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…
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
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.
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 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…
…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.
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.