Programming

by

In looking closer at things, somehow I think that by cica GCC 5.0, either the GNU compiler will have imploded upon it’s own weight :-o, or it will become an impressively powerful compiler, in place of an impressively portable one.

The feature set being grown, may even give old MSVCs optimization setup a good run for it’s money someday, only the best tools with Visual C++ cost a few thousand dollars and GNUs is given away for free lol.

Me, I would just settle for a generally portable compiler that generates decent code, and complies with the bloody standards… So far I personally like pcc.

Jokes sometimes place the yoke on you

by

In writing a small module, that in part of it looks like this:

    switch(function parameter of some enum type) {
      case SomeEnumValue:
        handle it
        break;
      // done for each enumerated value
      default:

        // crash program? *evil grin*
        2/0;
     }

    // use the function parameter

This was written as a joke to allow me to test the function by forcing the compiler to pass an invalid integral value, which would trip the default label. Obviously the final code needs to do something besides float around oft’ undefined behaviour, but one has to have a little fun in idiot proofing your code ;).

The funny thing was instead of crashing, it continued on and triggered the (testing) assert() checking the function parameter, which then caused the program to terminate. Even more enjoyable was changing it to `int x = 2/0;`, causes the program to halt due to a floating point exception. Someday I need to thumb through the C++ standard and take a look.

Oh well, I had planned to throw something from stdexcept anyway, or carry on with reduced functionality; so it’s no real loss lol.

Why C++ is a failure

by

In reading through Scott Meyers book,  Effective C++, his expression that it should actually be viewed as a federation of languages, is actually a great way to look at it. He describes it in terms of C++ the C, Object-Oriented, Template, and STL groups (I would’ve skipped the STL) is fairly accurate.

The true gem however, I think is Item 19: Treat class design as type design. This IMHO, is more true in languages like C++, Java, and C#, than what some folks are accustomed to. You’re playing with the type system, so act like it.

He points out 12 issues involved with developing a new type or ‘class’, I’ll summarize them briefly:

  1. How should objects of your new type be created & destroyed?
  2. How should initialization differ from assignment?
  3. How should passing-by-value work with your type?
  4. What restrictions are their on legal values for your new type?
  5. How does inheritance effect your new type?
  6. What kind of type conversions should be allowed?
  7. What operators and functions make sense on it?
  8. What standard functions should be disallowed?
  9. Who should have access to its members?
  10. What kind of guarantees does it make?
  11. How general is it?
  12. Is a new type really what you need?

If anything, I would say rip out those pages of the book, and make it a required `check list`  of ground new programmers must cover before they are allowed to add a new type to the code base. The book gives excellent explanation of each point, so I won’t offer much deep exposition here on them: I’ve just tried to condense them. (Buy or borrow the book lol.)

If you’re going to be creating a new type; which you are effectively doing when creating a new class in C++, then these issues all apply to you. I would argue, that most of this applies to any language with user defined types and operator overloading; which is also most main stream language supporting OOP.

Points 2, 3, 4, 6, 7, and to an extent 8, all make sense in the domain of creating a new ‘type’. Personally, I tend to skip much of it unless for example, overloading certain operators offers serious savings on expressiveness, or the default copy constructor / assignment operators are insufficient. These points that the book outlines, really are the source of most complexity in developing C++ classes, perhaps because like C-strings and good ol’ malloc(), it exposes a lower level picture of things to the programmer. Everyone can program in C, but not everyone should.

Points 1, 5, and 9, are more unique to designing a class than the others are, at first glance. Simply put you can’t create a class without taking 1 and 5 into consideration, it’s just required. Although admittedly you can skimp a little on 5 in some cases but probably shouldn’t. If you know jack about OOP, let along designing software, you know the answer to 9 is the minimalist level of access required. I actually enjoy that Scott Meyers work demonstrates, that OOP goes a lot further than the class keyword! Abstraction, encapsulation, and modularity are an integral part of doing quality work, and object oriented programming is but a useful paradigm for modeling that, especially when polymorphic inheritance is applicable. Point 5 becomes a bit easier to live with as time goes on, although I still suggest favouring object composition over inheritance when a class hierarchy isn’t the most appropriate thing for solving the problem at hand (and minimizing the ruddy singletons).

Points 10, 11, and 12 are true of most elements of composition within a program: from even for functions. Those kind issues get easier with experience, assuming you learned a slugs worth about software design in the first place. Some people never learn it, period.

Why based on those oh so true points, would I conclude that C++ is a failure? Because the “Average” slep is just not competent enough to deal with most of it as often as necessary. Heck, I still encounter code bases where the programmer can’t tell the fucking difference between signed and unsigned integers when designing their interface. There are some truly brilliant programmers out there, and many of them do use C++ quite heavily, but in the wider majority, as with most majorities: you’ll find more Homer J. Simpson’s than Sir Isaac Newtons in the crowd. This goes for just about every thing on earth :'(. We could use some more clones of Newton and a few less Apple and Fig Newtons walking around. So long as the average is sufficiently uneducated, and still allowed to (ab)use the language, I think it’s a failure; but hey, who ever said C++ was designed with the incompetent people in mind ;).

It is simply to much for the average Tom, Dick, and Harry to be able to consider it. Not that those proverbial average three bozos should be screwing with a complex system… half as often as they are found to be. Maybe I’m more inclined to make such statements, as I still know average adults who can’t understand a + b = b + a; yet, and I have met a whole lotta stupid people: without even counting programmers.

disclaimer: I drew this conclusion ages ago after reading EC++s item 19, that “C++ is a failure”, and was in a more stable state of mind at the time then the one used to finally type this out.

by

In reading through Steve Yegge’s old blog, I found a statement that perfectly summarises what selecting a programming language for a complex project is like:

So… the best way to compare programming languages is by analogy to cars. Lisp is a whole family of languages, and can be broken down approximately as follows:

  • Scheme is an exotic sports car. Fast. Manual transmission. No radio.
  • Emacs Lisp is a 1984 Subaru GL 4WD: “the car that’s always in front of you.”
  • Common Lisp is Howl’s Moving Castle.

This succinct yet completely accurate synopsis shows that all Lisps have their attractions, and yet each also has a niche. You can choose a Lisp for the busy person, a Lisp for someone without much time, or a Lisp for the dedicated hobbyist, and you’ll find that no matter which one you choose, it’s missing the library you need.

Except replace the lisp dialects with every language ever written, and factor in portability issues, and you now know what it’s like to be a multi-lingual programmer xD.

Conceptual: Stargellas Revenge

by
Premise

You take on the role of Stargella, a lonely star fighter pilot just returning home to the beautiful world of Freyja0 after a long patrol in deep space aboard the carrier ship Hofvarpnir1. Sadly in your absence, the evil Viekasiekian Empire has begun laying waste to your luscious planet! Deploying all fighters, as a group of imperial Triremes2 begin encircling the carrier,  the tides turn in the enemies favour. Soon you find yourself the sole survivor to reach Freyja alive, as all remaining hands go down with the Hofvarpnir.

Far from fearing a single star fighter in their midst, you must exploit that Viekasiek pride in order  to liberate your planet from the clutches of Emperor Zurick. Battling across the polar ice caps, over the sea, and into the forests of Freyja, you must push the Viekasiekian forces back into space: facing hordes of enemy fighters along the way. Among these include the heavy Ballista and Scuta, as well as lighter Velites3 and scout pods that make up the invasion force. Finally punching through the fleet in orbit, for a final show down against the emperor.

Game Play

The game is meant to be played in a 2D-esque top down point of view, utilising the mouse to manoeuvre across the screen. At it’s heart, is the intention to keep the action alive, blending an array of attachable/ejectable weapons and combat styles with a large amount of adversaries. My idea for a game, you can play additively as an arcade classic but with a pace that better befits the modern style. It’s aimed at folks like myself, who can still sit down and play Centipede or Tetris all day long with a grin, but would like a bit more spice.

It is meant to be more or less, ‘traditional’, in the sense that power ups drift across screen to be collected, and fairly simple on the graphical spectrum.

Current specs call for about 11 enemy craft and 3 more usable by the player5. The players ship is basically given a capacitance based on its size: larger equals more guns and harder to kill. Depending on the class of ship5, will also limit its ability to bring that heavier ordinance to bear upon the Viekasiekian slime.

  • The light fighter given at the start, being designed as a simple but agile craft, is meant to reflect an association with nature. It is obviously limited to only a few weapons because of its small size, but has a regenerative armour skin around a highly effective power plant, that makes for a long lasting craft with some serious skill. It gives extra advantage to players focused on not getting hit all the time, and favouring a few lasers backed by a heavier weapon for dispatched more powerful foes.
  • Medium class, being a more conventional ship of the line gained after a a certain amount of game play. Trading the lighter vessels regenerative skin, for a deflector shield and larger weapons bays, every hit on the shields will reduce the power available to laser weapons; thus off setting the greater capability to carry heavier missile and cannon than smaller craft. It’s meant to be a middle of the line way of playing, that rewards those who can balance its abilities during furious combat and still come out on top of the scrap heap.
  • Where as the heavy class, is basically the big bruiser of the bunch. It’s meant to be an unlock for scoring a good bit of points during the course of play, yet still balanced enough so that even the light fighter from the start can still stand a chance at winning the same fights as the heavy. Combing a large weapons payload with enough armour to last a while, it makes up for needing ‘armour patches’ during a long engagement, by being able to smash through anything that can’t kill it. Think about a dump truck turned into a war marchine lol.

 Weapons can be equipped when found, or jettisoned to make room for others. The hit list includes various strength of laser, that balance energy use to power consumption<6, as well as several class of heavier particle beam and ballistic cannon style weapons. My favourite being the missile types, hehe.

Each ship can only carry X slots in weapons with so much ammo, so one has to balance out what you have collected, when it’s fired, when it’s dropped, and do it all tactically during the regular course of game play. Weapons come in several principal varieties based on the kind of ammunition they utilise, making it simpler for the player to calculate a weapons value in the present situation.

  • Energy
    • Drains part of your energy gauge with every shot, but other wise never runs out of ammunition.
    • Types:
      • Blue Laser
        • Low output for short range combat, aimed to minimise energy drain whilst dealing with cannon fodder.
      • Green Laser
        • Typical energy weapon offering moderate damage to energy consumption. It’s a staple weapon but lacks serious punch.
      • Red Laser
        • Packs a hard punch but requires plenty of energy for each shot. Best suited for destroying targets that you can actually hit.
      • Particle Cannon
        • Fires a stream of charged paricles, consuming a large portion of energy in exchange for a solid knock down punch. It’s the plasma cannons younger brother ;).
      • Plasma Cannon
        • Very powerful but sucks up energy like a thirsty vampire. Ideal for quickly dispatching Viekasekian scum.
      • Overcharger
        • Drains all available energy and unleashes a devastating shock wave, dealing a proportionate level of damage to anything caught within the waves radius. A weapon of last resort!
  • Missiles
    • Uses up so much missile ammo per shot, but only a nominal amount of energy drain per firing. Some offer a form of lock, fire, and forget capability.
    • Types:
      • Micro Missiles
        • A small cluster of homing missiles, that gives chase to any craft in their line of fire. Not very powerful but amazingly handy in a brawl.
      • Heavy Missiles
        • Less intelligent than micro missiles, but capable of dealing strong damage to watever it manages to hit.
      • Spread Bombs
        • The tactical nuke of your arsenal. It fires straight ahead and explodes, dealing massive damage to anything within its corona. Best used as a weapon of last resort or against a tight group of enemies.
      • Zip Mines
        • Explodes a small zero point charge whenever a craft comes within a short radius of the “Zip” mine. They gradually float off screen, making it hazardous to player and enemy alike. This is your only rear firing weapon.
    • Shells
    • Requires “Shells” for ammunition and packs a strong wallop with low energy drain.
    • Types:
      • Auto Cannon (AC)
        • a
      • Rotary Cannon (RC)
        • A multi-barreled, large bore Gatling gun. Fires less powerful shells than the AC, but offers a more rapid rate of fire. Can quickly burn through smaller craft and shells alike, but it also jams with frequent use. Fire it in short bursts.
      • Cluster Cannon (CC)
        • In effect, a giant shotgun. Deals massive damage to anything up close but is practically useless for more distant targets.

Technical

Stargellas Revenge in it’s own right, is only the equal of about 6-12 months worth of coding, leaving most of the effort to graphics creation. An early prototype was built in C++, around SDL for graphics and Xerces for data serialisation tasks. Soon however, I realised that it would be worth my while to make it more general, so that much of the games insides could be redeployed for other game projects7.

This makes the game much more time consuming, particularly when you consider its a ‘side’ project, but the advantages are worth the delay. One reason I like it, is it allows me to flesh out the systems resource, multiplayer, AI, and various other infrastructure tasks without having to do it while coding around a much more complex game.

Most likely, it’ll be the test bed for a custom rendering system8 focused on stressing the API. The overall design of the games internal, is designed to be pluggable9 enough to allow easy access to some very professional strength rendering technologies, as well as being able to hot swap as much of the componentry as needed. Thus allowing the graphical quality to be reduced on systems where the better tools, are sadly, unavailable… without having to give up on them where so available10. The main reason for this being, I want to be able to play Stargella on my laptop11, as well as the 3D games on my desktop!

Footnotes:
0 Freyja is a goddess in Norse mythology, associated with attributes appropriate for describing Stargellas home world.
1 Hófvarpnir another reference to Norse mythology.
2 The triremis being a type of Roman warship.
3 These are all references to Roman military weapons and armour. In particular watch out for the Celeres defending Zurick.
4 It’s a fairly consistent theme, that names of Viekasiekian fighters stem from the Roman military, where as those assoicated with Stargella, have roots in Norse and Germanic mythologies.

5 Will probably be named after Valkyries.
6 Blue = low drain / damage; Green = medium; Red = kick ass and slurp power.
8 Think W3D level of complexity rather than COD6 graphics, but than again, this is a game inspired by games built during the 1970s.
9 I only intend to do OpenGL for most things, doing an equalivulent in DirectX 9/11 is left as an exercise to another geek, or a bored weekend.
10 You can have very high quality graphics under Windows NT, GNU/Linux, and Apple stuff: but FreeBSD is rather lacking in ease of deployment for games :-(.
11 FreeBSD.

At long last

by

My forum account on www.sasclan.org is finally ready op! It was unsuspended a few days ago, once WIZ completed the usual procedures. Kicking the bigger system into obedience, +1 for [SAS] admin power. Last time, I had to respond to a chit chat post via private e-mail.

One thing that I do not miss about being in [SAS], is having to deal with the ‘magic’ behind it, any more than it takes to make a forum post. Although I know my way around blindfolded in spots… I ain’t never gonna miss that code base.

What exactly, ‘is’ my development environment?

by

I reckon this is something rather confusing these days, in most cases among younger folks, it will likely mean an Integrated Development Environment. To me, it just means the environment in which one develops stuff ;).

Being a lower level polyglot in terms of languages and tools, I generally keep a ‘pallet’ associated with each of my main languages, keeping things quite simple to work with:

  • Build Tools:
    • Some viable form of Make is required, generally I’ll use local brew if an extension is needed. I prefer GNU Make over BSD PMake, as I find it more reliably cross-platofrom.
    • CMake, while often little more than a poorly strung together bother, many projects now use CMake based build systems. It is actually a good tool but I don’t favour it for use outside of a single OS family.
    • SCons: powerful and effective, but often irksome to get a portable build. It’s usually worth having available.
    • Ant: you never know when you’re gonna need it.
    • Local brew of IDE and their background stuff, for example Visiual Studio for the vcbuild/msbuild modules and/or Code::Blocks. If I had a Mac, I’d likely have XCode handy.
  • Documentation Tools
    • Unix: troff/nroff and the usual macro packages. I actually like it.
    • DocBook and XML/XSLT processing utilities. LibXSLT comes in handy.
    • ReSTructured text and company
    • Any local language related tools (e.g. for Java, Perl, Python, and C#)
    • Doxygen: a multi-lingual documentation generator.
    • Exuberant CTags: improved and vastly multi-lingual upgrade over ctags.
    • TeX and LaTeX setups. I like TeXLive.
  • Source Code Management / Version Control Systems
    • Git — must have!
    • Anything I need to be handy with:
      • CVS
      • Subversion/SVN
      • Bazaar/BZR
      • Mercurial/HG
  • C/C++
    • I generally setup and maintain several compilers, multiple versions being welcomed. Generally I try to hang onto a member of the GCC 3 and 4 branches, and a fairly recent version of Microsoft Visual C++. Under unix-like and Windows systems respectively, I also tend to carry about a copy of PCC and Watcom.
  • Java
    • A suitable JDK, or a complete software development kit where appropriate.
    • The GNU Compiler for Java can be useful.
  • C#
    • Mono and preferably the full stack of technology.
    • Under Windows: several versions of the .NET framework and at least a workable version of Microsoft Visual C#.
  • Python
    • A copy of CPython, preferably both modern versions of 2.x and 3.x releases.
    • The usual parts of CPython that some distrios strip out, like SQLite3 or Tk bindings.
    • Another implementation for testing (e.g. IronPython) is appreciable.
  • Perl
    • A standard perl distribution, preferably the current major version or the one before it.
    • Common perl modules one is actually likely to use someday.
  • Lisp
    • CLISP for general use, i.e. common lisp
    • Armed Bear Common Lisp (ABCL) in case it eases deployment issues
    • GNU Guile: my normal way to use scheme.
    • Bigloo: a scheme compiler that’s worth poking around
    • Some other readily available Scheme implementation available, preferably one that is at least moderately R5RS compliant
  • PHP
    • Fairly recent version of PHP setup with
      • Command line interp.
      • Suitable Apache modules
      • The CGI/FastCGI friendly thingy
  • Ruby
    • Current local-main line version.
    • Rake build tool.
    • A collection of handy modules
  • UNIX shell scripting
    • Something fairly portable, ash/dash based is nice.
    • GNU BASH.
    • Real and public domain versions of the Korn Shell.
    • ZSH, my favourite.
  • Go
    • Standard distribution compiled from source.
GUI and Console versions of Vi IMproved being a very obvious requirement ;). I also tend to keep versions of Emacs, some flavour of MicroEMACS, and SciTE available in a pinch.  I like having ed available.
Generally some form of webserver, be it a quick tester (ala Python) or dedicated (I like nginx and Apache), is usually required: plus a decent web browser with javascript support.
Profiling, code generation, analysis, and debugging tools are almost universally welcome. I in particular like to keep Valgrind and GDB handy for a rainy day.
Like wise I prefer having certain libraries fully integrated into that stack, i.e. where appropriate having interfaces the common GNU/Gnome libraries (GTK+/cie), Qt3 and Qt4 libraries, bindings for SQLite3 and a major player (MySQL, MSSQL, etc), OpenGL, and so on and so forth. I tend to leverage both languages and tools whenever possible.
Someday I’ll likely incorporate Lua, and dialects of Forth and ML into the mixture. Like wise I prefer a reasonably NAWK friendly version of AWK to be available. I also have interests in picking up Prolog, Haskell, Erlang, Ada, and a few lesser known languages, but just don’t have the time to screw with such things a lot these days :'(. 
Simply put, where I go, a whole freaking lot of development tools go with me!
by

Lately in my spare time, as one might guess: I’ve been picking up C#. That, and reading about electrical wiring and stuff, but I always new I’d light myself up one day xD.

Before bed, I was experimenting with building and structuring assemblies. Being my typical self, this of course means playing with the command line csc (MS) and mcs/gmcs (Mono) compilers, as well as their associated tools. IDE wise, I experimented with MonoDevelop under FreeBSD and the express edition of Visual C# 2010 under XP.  I must admit that as far as IDEs go, MonoDevelop is a pretty good one: the only negative things that I can say about it, being the vi mode is very minimalist (G doesn’t even take a count), and it’s not the most responsive program when the computers under heavy load: but still knocks Mozillas socks off by 9 warp factors :-P. Visual C# on the other hand, I can’t say how the 2010 version differs from the 2008 one: only that it’s not nice. To be honest, my first encounters with the express editions for Visual Studio 2010, shows me that Microshaft seems to have a policy of (yet again) hiding much of the tools from the user. Just starting Visual C# makes me remember how long Windows has hidden file permissions from the user by default. Perhaps most Windows users are to damn stupid to understand the concept of “Privacy”, but any jackinape permitted to touch source code, should at least be made to understand the concept of debug and release builds (a heck of a lot better then VS’s new defaults).

In my experiments using MonoDevelop and Visual C#, it only took a few seconds before I became glad that Vi IMproved doesn’t emulate Intellisense; but it is fair to say that I’m a freak: my customised vim setup even disables syntax highlighting lololol.

And considering how much this build of Firefox has Flash burning through CPU cycles, I think my laptop is going to heat, if I don’t call this a morning :-S.