Skip to main content

Coding Sucks ... I Love It!

Well, I have been coding since 2002 ... not too long, yes, but in that time empires have risen and fallen, billions of lines of code have been written, and I have learned one thing:

Coding Sucks ... I Love It!

Seriously, I can't get enough of it... I have written projects in Java, Python, C, C++, PASCAL, assembly (win32) ... most recently JavaScript ... each language (or scripting language) has it's dizzying highs and abysmal lows, but one thing is consistent:

They all suck

Yes, that is a cruel statement, but let's face it - all languages suck in one way or the other, templates in C++, no-classes in C, the ease with which Python allows you to destroy your project ... the inane simplicity of PASCAL (and lack of true graphics support + hardware accel.) ... There are pitfalls to any language - and yet I have coded in many of them, for one simple reason....

The feeling of triumph when I accomplish a milestone...

Or better yet - that feeling of relief when I complete a project.

So, I might rant, and I might rave, but I have been coding for a long time - several of those years was as a Senior Developer at a software production firm, and I loved every second of the code - not the politics...

I am a programmer, and this is my blog.

Comments

Popular posts from this blog

A few thoughts on Game Development

For those of you who follow my blog, you'll notice that I talk about building games, but I never really release anything useful or fully playable. I'm more interested in studying the individual parts of game development, without really caring about building a game as a whole. Well, for the most part this is perfectly acceptable, as I'm not a game developer by trade, and my bread and butter comes from being a utility developer. I've defined utility developer as someone who codes a variety of things without specializing in any specific discipline. As a self-taught developer, it's been hard for me to pivot into a role where I'm classed as a game developer by trade. This is all good and well, but I still want to talk about game development as a whole - specifically how to get a game off the ground. If you've been following any blog about game development, or any programming course which walks you through the process, you've most likely heard of all the jar...

Finding a Game Engine is Hard

Well, if you're new here - congratulations on finding the most useless blog on the planet. If you're not new here, thanks for coming back to another installment of "And he just keeps moaning!", this weeks episode deals with how hard it is to select a Game Engine for your development needs. As I've mentioned in the past, there are many things to consider when developing a game: Storyboarding Specification document Game Engine Resources (art / sound / levels) Time constraints Return on Investment Since I've preached about the Specification Document all throughout my last post , I'll save you a little bit of reading by saying it's nearly the most important part of the entire process - nevermind having a compelling game - without the specification document, nothing gets built. Storyboarding is kind of like the specification document, but it allows you to draw little screens of the game as you imagine it to be, without too much detail....

On working with Python and Javascript .. and HTML and Ajax and SQLite

I have recently been creating a production management system. The system is not that complex, but it is taking an inordinate of time to write ... even though I am using rapid-prototyping languages - Python, SQLite3, HTML4/5, Javascript coupled with liberal Ajax sprinkles ... I simply don't understand - but I will try to get to the root cause. So far, I have constructed the tables and written a database backend wrapper - for the SQLITE3 DB which I manipulate on the server side using python cgi. I have created the concept of "sessions", but not in the MOD_PYTHON way, no, in the more traditional - hacky, store-it-in-the-window_name way ... By allowing the user to send an Ajaxlogin request, which generates a session token on the server side, which is then "kept" or "remembered" on the client side by storing the token in the window name browser object variable... It's probably the most rubbish way I can do it, but it works - survives page reloads ...