How to piss off a geek

Make me waste 45 minutes to do 10 minutes of work when I'm trying to get everything sorted *promptly*, in order to minimise the number of things that can go wrong tomorrow.

That and generating a splitting headache in the process.

This makes me think of my grandfather

Thanks Malty :-).

So many zombies later

I'm thinking about writing a short/moderate length survival guide for Left 4 Dead 2. Haven't been playing much of anything lately, but after like 60 hours into the game, I've become extremely competent at it. When I do play, I'm still a lethally proficent team member.

Unlike some people, I also have a rather strong aversion to leaving fallen teammates behind, except for bots, hehe. That means I can drop more than my fair share of zombies in a hurry!

Stopped off at the library to return last weeks book (one of Shakespeare's comedies), and checked out two more: one on sewing and one on fishing. The latter, obviously because I haven't gone fishing in years and years! The former, both because I've always been interested in how things are sewn by hand, and because I've had an interesting idea.

Since I'm now 'issued' my mothers cell phone whenever I'm out without her (if I wanted a chaperone in the car, I would go courting, not driving around), it would be easier to carry if my jeans had leg pockets instead of the usual waist pockets. Some what like a pair of military trousers have, well American ones anyway. Possessing both a frugal mind and an engineers heart, of course rather than buy new pants meeting that criteria, my first query is to figure out whether it's practical to use some old jeans for raw materials and graft such pockets onto the pairs I use, lol. I know I can figure out enough to do such a thing eventually, the question is how to do it properly by hand with the material involved. Having to answer my mothers "Where the **** are you?" call today while I was sitting in traffic at a red light, is a prime example of why such a modification is worth scouting out. I would likely be cussed at if I don't answer, even if it's not easily fished out of a waste pocket when you're behind a wheel, let along that I refuse to chatter on a cell phone while actively driving. Period. Whenever my mother's involved, you can bet it is a lose, lose situation for me \o/.


My main interest for the day however was checking out a certain fishing spot. I found 4 points of interest. One is within 15km of here, another (but very costly) one is about 65km away. Been there before, years ago. The other two are Georgia state parks, on the other flank (approx 20~30km SE of) Atlanta that it would never get past HRP. I purposely avoid locations near Atlanta because of her paranoia. The other is almost a good 100km to the south of here.

Today I wanted to check out the nearest one, since it's located between the city limits and a neighbouring town. Someday I would like to check out that park to the south and go exploring, as well as see how it is on the fishing pier. Being in the opposite direction from Atlanta is a plus for getting permission to use the car, the downside is it's far enough that I'll need to buy gas to replace what's used on such a trip—I'm not the kind to leave her with next to nil gas. I am the reasonable one here...


Since just getting use of the car for the afternoon was an argument of it's own! I was so preoccupied over  whether it would be a driving or a walking mission, that I didn't have time to plan the trip properly; so I ended up getting lost instead of finding my destination. To make it worse the gas station didn't have any Twinkies! For some reason watching Tallahassee's quest for the snacks throughout Zombieland has got twinkies on my brain for the first time in years :-/. Since it was my fault for not mapping it out, I replaced the petrol wasted and filled the tank while I was at it. Never mind that I would've planned correctly if I would not have to push just to get that far.

Personally I hate highway travel. The higher speeds burn gas much faster than local travel speeds (it's an old ford)  and the windows need to be shut or fuel efficiency suffers even more; ma also has a standing (near 20 year long) order that the A/C is not to be used. Never mind that at GA highway speeds, it's actually the most budget friendly way not to drive in a '93 oven and arrive feeling like a drenched goat.

Spent some time exploring the local sporting goods store: despite what some have said, it actually has very good prices. My main interests being to grep the huntin' fishing sector, and conclude some other 'research' on the way out. I expect what tackle I have stored will do, and my rod/wheel seems to be viable despite it's lack of use; but it is always best to be prepared just in case.  Some how all that trip through the tackle only served to make me hungry, as odd as that sounds. Maybe I'm part fish? lol.

My research there was more aimed at biking than fishing. Where as most of yesterday was spent on the fish and work situations: last night I took some time to check through the stores online portal. The local shop prices own their online listings. Seems the best choice in this berg too. More specificly my poi was in cycle, helmet, hydration, plus a few associated odds and ends. Can't know what the operating range is, but biking should be sufficient for my needs. Heck if I can walk like 30 klicks by foot and not get a heart attack, it shouldn't be hard to do a few miles worth of peddlin' a bicycle. An occasional snack bar and some water is cheaper than petrol anyway.

It would obviously be some what of a problem that I never learned to ride a bike growing up, kinda the apartment dwellers curse (no bikes, boards, skates, or anything else fun allowed). For the cost of human fuel and getting some much needed cardio-exercise, I'm not above breaking my neck in the figuring-it-out-the-hard-way, as there isn't any 'ideal' places to pactice. Economy matters. For what the future holds, I would consider the massive price gaps between bicycle, motorcycle, and automobile, strongly in favour of building muscle. You need a driver's license to get around in this freaking country, but you do not necessarily need a car to get around in.  It's a wonder people don't drink bath water more often; it's become that stupid in America. I'm fully open to alternatives to driving, even if it's likely to generate a few bruises.

That however is quite a fair ways off, it will take some measure of saving to afford that kind of kit anyway plans are sliced. It'll probably be one of the first things on my private list to fall, once I've got a steady income to work with that is. How far way reaching that point in time will be, however is largely at the bitch on wheels' mercy: because I'm not willing to work (locally or anywhere else in Georgia) unless it is proven, that I will have sufficient freedom with the car to be able to hold down a job without being screwed. It's the principal of the matter. You don't want to argue principals with a programmer, not even a totalitarian can win that debate. With a track record that can only breed my distrust, and the difference between road (35-55mph) travel speeds and foot (~3mph) travel speeds, even within comfortable walking distance: whether it's pissing distance or long distance to get to work or anywhere else, I am not willing to be constrained—especially not by my mothers pathological paranoias: and the only way to ensure that (she) doesn't come back to bite, is of course not having to rely on access to my mothers otherwise stationary vehicle. Reducing her costs would be one of the points of having a job anyway, including getting my own means of transport in the long haul. Which is obviously necessary for my long term plans.


Before heading home, I hit Walrus Country to search the sporting goods section in like wise fashion, and pick up a fishing license on my way out. Also had to pick something up that ma wanted. She almost owes me more money now than I have saved in my chequeing account lol. Fishing licenses are only needed off private property, but it's worth having! Stopped off on the way home at another gas station in hopes of finding a Twinkie but had to settle for a LD mini coffee cake and strawberry roll :-(.

Seriously, someone must have gotten to people about cholesterol or something. What kind of world are we living in when gas stations stop selling twinkies!!!!

Somehow I find it highly offensive, that I can't even go for a walk without being driven nuts; yet my mother is perfectly willing to enlist me to check on racket outside, instead of moving herself 8=).

What next, a lock and key?

I love a dictionary that keeps with the times.

The geniuses at Princeton have a lexical database of English, that in essence is a very terse, no frills dictionary; often one of the best sources for looking up the meaning of something. Today, I couldn't help but smile—because they've kept up with the times.

To tired to focus on code at the moment, yet much to awake to sleep \o/. Been tinkering with an old project: tpsh. Mostly I've been polishing the codebase and doing a bit of refactoring; there's no a debug mode, which reduces some of the cruft that's crept in from testing. Sometime I also need to import the test scripts lol.

One of the changes, is adding support for running off the Strawberry Perl distribution rather than ActiveStates Perl distrio for Windows. The downside is, most of tpsh biggest problems have to do with Perls portability, namely Windows quirks. Gotta love'em.

Since the merge of the "Code generator", tpsh has supported a very limited subset of sh script. Not very usefully however, since the shell doesn't have a real concept of $? yet. Likewise there needs to be some changes in the handling of environment variables. Most ideal IMHO, is a tied hash wrapping $ENV (a magicly tied hash of environment variables) with the ability to hook reads and writes, etc. Preferably in a user-exposabe way that can be extended by shell functions, rather than being limited to the scripts own Perl code.

It's the more general case however, of having to build up the language rather than use its building blocks. The problemo isn't in maintainability, but in portability and development time.

Having reactored a chunk of the shells initialization code,  I know that I'll have to retackle the readline stuff.  To say that I hate Term::ReadLine would be an understatement. I've no love for the GNU Readline API either (I would use linenoise), but the GRL C API isn't as nasty in practice as the plugable Term::ReadLine system Perl uses. The only good thing I can say is that there is a semi-useless stub version included. Licensing issues of just having a GRL backend aside >_>. In my experience, mileage varies quite a lot between Perl readline pacakges, even within the scope of the fscking manual. It's just a load of crap.

Actually if there's a way of accessing the API  functions needed for unix termios / windows console, I would be tempted to throw out the fucking thing and just write a Term::ReadLine::SANE module based on linenoise (A C library). I'm more familiar with the unix parts of that.

Tactical Zombie Hunting

There is just something so cool about employing fire and manoeuvre techniques against a horde of zombies, and on the fly to boot.

How do you survive? Team up, nut up, and shoot'em up!

Some how I could swear, the closer proximity I have to family, the worse my existence is.

The STAMAN Project: Phase IV,

Having thought of tasks and storage formats, it's now time to figure out an implementation language, i.e. what programming langauge am I going to write the task manager in.

O.K. based on what we've got so far, it is easy to infer the following is worth having:

• Portable between systems—a must for me ;)
• Easy access to SQLite—usually trivial.
• Better tools than gmtime().

That means this page is rather useful, for what languages can be ruled out. In my répertoire this means Go (aww), Scheme, AWK, and shell languages can be skipped. Reason being the portability of Scheme bindings in general, and the others lacking sufficient portability (for my taste) at this time. That still leaves about 13 languages, lol. PHP, Java, Lua, JavaScript, and X86 assembly are easy for me to rule out. Reasons for that can all be easily guessed; at least if you remember how much I enjoy Suns Java tools. JS/Lua are great choices but I don't want to screw with the bindings and stuff.

I'm not very interested in compiling SQLite in C/C++ on Windows, or the CLI binding everywhere. So this effectively makes the choice Perl, Python, or Ruby. Out of those three, none is perfect either: perl doesn't come with the required database code, it just has the definitive interface for databases everybody mimics. Python and Ruby on the other hand, come with SQLite bindings—which many distributions separate out into separate packages. It's just a lose, lose situation when you think about dependencies, but it does beat writing your own everything for every program. Sometimes. Setup with these three dynamic languages would be easy though, in so far as we've gotten with the above.

Time handling is another issue. Perl has fairly minimalist handling of time built in, but on the upside, if you need it, it's probably three abreast on CPAN. Time::Format and the core Time::Piece module each come to mind. What isn't built into Perl, often comes with it or can be added to it. Ruby provides a simple but effective Time class, that makes for more natural code than you may expect. More complex operations will require Googling for a Ruby gem, or hand coding it on demand. Python on the other hand provides a comprehensive datetime module, and supporting time and calendar modules, all out of the box! I would say Python takes the lead here.

Rule one of getting work done: know how to leverage libraries.


In terms of programming languages, Perl, Ruby, and Python are generally equal enough for most tasks, so long as you don't shoot yourself in the foot. Some subtle differences that personally irk me:

• Perls autovivification can be almost as much a miss-feature as it can be a convenience. You've just got to learn the damn language :-P.
• Ruby functions are not first class objects! Some things can also be weird if you're not used to Ruby.
• Python doesn't always stand up well to typos, especially if they involve indentation \o/.

Because of how many lines of code I've done in Python over the years, I am more familiar with it's set of "Irks" than Ruby's, like wise I know Sh, C, and Perl more intimately than other languages, so I really know their irks. For perl, it's mostly thin things that get in inconvenient when combing the warnings pragmata with the nature of perl syntax. They spiritually conflict at times. Under Ruby, I mostly find gripes that have a bigger place in programmer culture. My issues with Python generally have to do with trade-offs that I disagree with as a matter of my convenience, even if it usually results in a Good Thing overall. It comes from a C-oriented background meshed with a love for the Perl programming language.

This is a fact: you will always be irked by your programming language, if you use it enough. What can I say, nothing is perfect. Shoot!


For this particular application, there's some things worth noting also: language portability. If the machine doesn't run perl, it's not a real computer. Most systems you're likely to care about will run Ruby and Python, and there's probably a crusty old version of Python for those you don't (nor directly should). In contrast however, Perl is often a lower level of "Cross platform" behaviour than Ruby/Python. You'll find this highlighted well in the Camel book. One reason I use Python frequently, it always behaves as expected without so many subtle hiccups.


How much this pertains to the current matter, i.e. implementing STAMAN. Perl is the most universally available language, and I'm more prone to need such a feature than most people. A plus over Ruby is no crappy 1.8.x/1.9.x porting issues...! Of course however, I have a camel to ask about minor details, hehe. In my experience the Python 2k/3k thing is less issue than Ruby's for writing code yourself, more of an issue in leveraging existing code.


So I reckon, that means Perl or Ruby is best called for here. I exclude Python, because I just use the frick'n thing to often.

I think I'm more tired now than when I fell asleep, but at least Zombieland is on :-/.

The STAMAN Project: Phase III, of tasks and storage formats

At least, for me, there are only two pieces to STAMAN that are not trivial to work out before writing the code: choosing the storage format and implementation language.  Both also happen to be areas where experience strongly augments ones intrusion, more so than the rest of the app'.

In the design outline, I noted that YAML would work quite nicely, yet an exposition of the outline suggests that something closer to SQL could better serve the applications design. The reasons behind it should be fairly obvious, if you've ever worked with textual data before.

During Phase I, I concentrated on the data involved with task management. It's not hard to implement an SQL schema capable of representing that. Even better, most dialects offer useful features for handling times/dates. Virtually every programming language has a way of interfacing with such an SQL database, either through natural bindings or calling out to scriptable client programs. SQLite, MySQL, and PostgreSQL in fact provide both means, I'm not familiar with MSSQL. So that's a big set of pluses all the way around. We even get a reusable DSL to help without having to write it!

The problem however, becomes one of migration paths: what happens if you need to change the data structures, perhaps heavily? That means having a lot more work whenever restructuring is needed, and it's IMHO, less scriptable than a little perl golf: sufficiently so that I'm not going to screw with it. Insert shameless plug for Ruby on Rails here ;).

In a commercial environment; i.e. oriented on making money off the program, XML would be more likely than any other textual format, but not very convenient for me. I also hate XML parsing with a passion. It is however sufficient for getting the job done, if a bit, ahem, jacking the amount of internal documentation you need to write (or later wish you had) several notches higher than it need be.

Someone might think of a simple Comma Separate Value (CSV) format, but CSV is any thing but simple. Don't believe me? Just think about data that may contain commas. That being said, the only good things I can say about CSV, from a programming perspective, is CPAN rocks. Unless you're munging address books or spreadsheet data around, and need a LCD: it is best to avoid CSV, period.

The best bet, in terms of structured text: but one sufficiently able to represent the data set, and be easily edited by hand. What is really needed is a dedicated format: enter YAML. It's basically a hierarchial way of recording data as sequences of elements and key/value mappings. Works excellently.


The SQL solution relinquishes fine control over the operations, where as the YAML method is assured to slurp up memory in proportion to the input. It's a lot more like DOM oriented XML, only the translation between the code and textural representation is a hell of a lot more natural. When working with program generated output, it also doesn't need to be fed through a pretty printer to be comprehensible, which can't be said of XML—without more pain for someone.

Pro YAML:

• Easily edited by hand (notepad) and many unix tools.
• So simple you can skip reading the spec⁰
• If you have to write your own parser, make it YAML and save grey hairs.
• It's easy to serialize/marshal data around, as easy as it gets without eval().
• More likely to benefit from compression.

Pro SQL:

• Less imperative-style code to be written.
• The hardest processing code is already in the database engine.
• Can focus on querying data, not parsing it.
• Languages/frameworks are more likely to ship SQLite bindings then a YAML parser.

Con' YAML: 

• It really is as simple as it looks.
• You have to write your own list/dictionary handling code.
• Scales less.

Con' SQL:

• You have to learn basic SQL.
• Not the most fun in some languages (C, C++, Java, and C#).
• Can't really get at the data, short of a database client.

Note that I haven't said anything about separating the data store from the client application: using an SQL server is just as viable as storing YAML files on a network drive. It really is that simple.

My personal view? SQLs virtues likely outweigh YAMLs here—unless you're going to be designing by exploration. I'm not in this case, and I am also competent enough not to shoot myself in the foot. If I was smart, I would make the application wide interface to the data store more abstract than writing SQL queries all over the place like an asshole. Yes, I can be that smart. Don't tell your neighbours.

0: I read the YAML specification the first time I used it for a project, which was for a rake based built system. How else could I expect to hand write my build spec's in YAML? :-).

Rules of Family Survival

• Learn to become solid and expressionless as stone.
• Don't take open and seething hatred filled tirades personally; wish you had better ear plugs instead!
• Remember you're not a slave at beck and call.
• Automatically disconnect yourself from being guilted over things you're not responsible for.
• Sometimes, you just need to duck...

Is it no surprise that most days are fucking miserable here?

Without a doubt, my mother is one of the worst creatures I know on earth, that hasn't filled an empty head with an associated MBA.

Somehow, I'm really not sure what is worse: the curse of experience or a gringo's rush.

Concept: tried Quassel IRC, didn't like it - good software but not my bag. Switched to ircII - love the interface, don't want to screw with hacking it. IRC clients are simple creatures but tend to be crap. While I could live with (or suitably script) ircII to my hearts content, I also want a more Windows usable client too.

Problem: When it comes to programming languages and what I want (something very ircII like, yet rather lisp like in a way). I can see all the pluses and minuses of any given implementation. If I was a nub, I would just pick a language, rush into it, and try and dig myself out.

Knowing so much can sometimes be a real let down \o/.


For those that don't know it, ircII is a very old school IRC client, even by the best CLI-whorish standards.

The typical IRC client is arranged as a text display area, for the current channel; a line edit for your messages; modern ones include a panel to list names in channel and some "Tab" like interface for marking the channels you're chatting in. Text mode IRC clients work this way too.

ircII on the other hand, routes everything into a central display area and places a line edit under a "Status line". Rather than jocking between tabs to see what's up in other channels—which is very wasteful, even when using keystrokes: in ircII you simply use a command to change your current channel. Exempli gratia:

Typical:

1. Click #chan1 tab
2. Read what's going on
3. Reply if desired
4. Change back to #chan0

Becomes:

1. See what's going on both in #chan0 and #chan1
2. Use /j #chan1 to make your subsequent messages go to #chan1 instead of #chan0 until the next /j[oin] command.

It's just more convenient for me than the 'modern' user interface. I like efficiency.


In terms of implementing something like this portably (unix/win), the issue is simply line editing. That's not a subject I enjoy. Having worked on a unix shell, I know it's a bitch of a subject. Colour support is another, but minor one. Cmd.exe doesn't understand what a DEC does.

I also want something dynamically reprogrammable on the fly, basically access to a REPL. O.K. so lisp spoils you. This makes dynamic languages more convenient; which is also it's own can of worms.


That's the fact of Programming, it's all a Kobayashi Maru problem: you've just got to deal with it.

One obvious down side to eating everything in site and coding the night away, it's 0400 and I'm not even drowsy yet... :-/

Reflections on C#

Lately, I've been trying to use C#. No sense in learning a language and never using it, ever, lol. Over the years, I have generally skipped getting into C# - to much like Java for my tastes. Some months ago I picked up the lang' as just a way of passing time. Found it interesting to note that C# was also about 3-4 times more complex than Java, syntactically. By contrast most of the complexity in Java comes from APIs or hoops you have to jump through to do xyz.

In putting my C# knowledge into practice, I've found that most of my linguistic gripes against learning it have been solved in .NET 3.0 / 3.5, and making portable code that works under Winows and Unix is just as easy as expected: in fact I test everything against the compilers from Microsoft and Mono. I've not had any troubles, and I am using like last years Mono version.  Although, I must admit that I think of Monos setup as the "Novell implementation" and .NET as Microsoft's >_>. The portability of C# is every bit as good as Java and dynamic languages. In fact, if it wasn't for the Mobile version (Java ME), I would say C# is more portable than Java these days.

C# already have features that are expected in Java 7 and C++0x, but everyone will be damned if they will get to use any time soon. To top it off given the blasted prevalence of Windows machines, just about everyone will have a liveable version of the .NET runtime that you can program to in a pinch. Between actually using the computer, newer Windows versions, just about all of them will have a modern version. Plus several popular unix applications (and parts of the Gnome software stack) are written in C#, so the same goes for many Linux distributions. Alas the same can't be said of getting various C/C++ libraries compiled....

Compared to Java, C# is a mixture of what Java should have evolved into as a business language, and a bit of C++ style. C# also goes to lengths to make somethings more explicit, in a way that can only be viewed as Java or COBOL inspired. I'll try not to think about which. I think of professional Java and C# programming as our generations version of Common Business Oriented Language without the associated stigmatism.

The concept of "C++" style in C# however, is something of a moot point when we talk about Java too. Here's a short comparison to explain:

// C++ class
class Name : public OtherClass, public SomeInterface, public OtherInterface { /* contents */ };


// Java class
public class Name extends OtherClass implements SomeInterface, OtherInterface { /* contents */ }

// C# class
public class Name : OtherClass, SomeInterface, OtherInterface { /* contents */ }

It should be noted in the above example, that C++ trades the ease of control over class visibility for fine grained control over inheritance. AFAIK, Java/C# has no concept of private / protected / virtual {x} inheritance. Likewise C++ is multiple inheritance, while Java and C# are single inheritance. This all leads to a more verbose class syntax in C++. 

Now this one, is where you know how Java is run ;)

// C++ foreach, STL based
std::for_each(seq.end(), seq.begin(), func);

// C++ foreach, common technique
for (ClassName::iterator it = seq.begin(); it != seq.end(); ++it) /* contents */elementtype

// C++ foreach, to be added in the *future* standard (see below for disclaimer)
for (auto elem : seq) /* contents */

// Java foreach, <= 5.0
for (Iterator it = seq.iterator(); it.hasNext();) /* contents */

// Java foreach, >= 5.0
for (ElementType elem : seq) /* contents */

// C# foreach
for (var elem in seq) /* contents */

As you noticed, there's three different examples for C++. The first uses the for_each algorithm and leads to rather simple code; the second is the most common way; the third is being added in C++0x and I haven't bothered to read the details of it, since the version of GCC here doesn't support it.

C++ again gives very fine grained control here, the for_each algorithm and iterator methods are extremely useful once you learn how C++ really works. If you don't, than please don't program seriously in C++! The C++0x  syntax is +/- adding a foreach keyword, exactly what you would expect a foreach statement to look like, if C++ had one. Some things like Boost / Qt add a foreach macro that is mostly the same, but with a comma.

Java enhanced the for statement back in 2004, when Java 5 added a foreach like construct. Java hasn't changed much since then. When you compare the keyword happy syntax of Java to the punctuation happy syntax of C++, it becomes clear that Java's developers had decided doing it C++ style was worth more than adding any new keywords, like foreach and in. Guess they didn't think to steal perls foreach statement for ideas on how to naturally side step it.

C# on the other hand, uses the kind of foreach statement that a Java programmer would have 'expected', one that actually blends in with the language rather than sticking out like a haemorrhoid. I might take a moment to note, that javac can be so damn slow compared to C++/C# compilers, that the lack of type inference in Java is probably a good thing!

In terms of syntax, Java is like C among it's OO peers: it's about as small and minimalist a syntax as you can get without being useless. I wish I could say the same about Java in general. Some interesting parts of C#, include properties and the out and ref keywords. 

Here's a comparison of properties in Java and C#:

class Java {

    private PropType prop;

    public PropType getProp() {
        return this.prop;
    }

    public void setProp(PropType prop) {
        this.prop = prop;
    }

    public void sample() {
        PropType old = getProp();
        setProp(new PropType());
    }
}

class CSharp {

    public PropType prop { get; set; }

    public void sample() {
        PropType old = prop;
        prop = new PropType();
    }
}

C# has a very sexy way of doing getter/setter like methods for properties. Personally I prefer the more C++ like style of just having a public field, unless you need to hook it (with a getter) or use a private setter. I like how C# can make it look like a field, when it's actually a getter/setter method like construct. That means you don't have to remember which fields are accessed directly and which need member function calls when writing code. Java convention is getter/setter bloat; C# convention is to use properties for anything non-private. I hope C# 5.0 or 6.0 will replace { get; set; } with just add a property keyword alongside the access modifier.

C++ is just as lame as Java in doing getter/setter methods, except you can (ab)use the pre processor for creating such basic accessors as the above, as well as any similar methods you need but don't want to copy/paste+edit around. Java and C# always make you write your own, unless they are the basic kind. Tricks involving Java annotations and subclassing can kiss my hairy ass. It's also worth noting that some Java projects can use an insane amount of getter/setter code. Come on guys. Using an external tool is not the right solution.


When we compare the age of these languages: C++ => 27 years old; Java => 15 years old; C# => 9 years old. It becomes obvious that C# is the only one that doesn't suck at the concept of "Properties" and getter/setters in general. Perl made love constructs that respect the programmers time more than the compiler writers: you should too.

To anyone who wants to dare note that Java IDEs can often auto-generate getter/setters for you, and dares to call that better than language level support, I can only say this: you're a fucking moron. Go look up an Abraham Lincoln quote about silence. Now if someone wants to be constructive and create another Java example equal to the C# example in the above listing, I'll be happy to add it: rules must be shorter than existing Java example, uses: no subclassing, no beans, no external programs or libraries. Be sure to note what Java version it requies. Cheers.


The ref and out keywords in C#, are actually kind of oddities, if you come from another main stream language. In C it is not uncommon to pass a variable (perhaps more correctly a block of memory, if you think about it) to a function: and have the function modify the variables value instead of returning it.

    /* Common if not enjoyable idiom in C */
    if (!do_something("some", "params", pData) {
        /* handle failure */
   }
   /* use pData */

In this case, pData is a pointer to some data type, likely a structure, to be filled out by the do_something function. The point is, it's intended as a mutable parameter. In C/C++, it's trivial to do this for any data type because of how pointers work. Java passes by value just like C and C++ do: you can modify non-primitive types because a reference is used, not the 'actual' value. Making it more like a reference than a value type, in CS speak. C# does the same thing.

    // Java pass by value
    public void test() {
        int x=10;
        Java r = new Java();

        r.setProp(PropType.OldValue);
        mutate(x, r);
        // x = 10; r.prop = PropType.NewValue
    }

    public void mutate(int x, Java r) {
        x = 20;
        r.setProp(PropType.NewValue;
    }

Now a little fun with the self documenting ref keyword in C#:

    public void test() {
        int x = 10;
        var r = new CSharp;

        r.prop = PropType.OldValue;
        mutate(ref x, r);
        // x = 20; r = PropType.NewValue
    }

    public void mutate(ref int x, CSharp r) {
        x = 20;
        r.prop = PropType.NewValue;
    }

The out/ref keywords are similar, the difference has to do with assignment; RTFM. The important thing is that it is a compiler error to pass the data without the ref/out keywords at the call site.  I'm both enough of a Python and C++ programmer to enjoy that. This explicitness helps catch a few typos, and helps document that it's meant to be passed by reference, not value. That's good because a lot of programmers suck at documentation and some also blow at naming parameters. I think the contractual post/pre conditions in Spec# are a good thing: by removing writing the handlers form the programmer, and not having to make the programmer rewrite the flibbin' things in prose somewhere in the documentation. Not to mention the classic "Oops" just waiting to happen in less DbC oriented syntaxes. Hate to say it but the ref/out keywords presence in vanilla C# are likely due to Win32 API documentation conventions \o/.



Where C# really rocks is in the CLI. Java has something good going for it, over the past 15 years the Java Virtual Machine (JVM) has been heavily tuned for performance, Mono and Hotspot also present quite an interesting set of options (that .NET lacks afaik). I assume that Microsoft's implementation has also been battle tested for performance as well.

The thing of that is, the JVM was originally designed to run JAVA, first and foremost at the end of the day, that is what it had to do. The Common Language stuff on the other hand was intended to run several different languages. Although admittedly languages native to CLI tend to be similar, but so are most languages in general. The interoperability between CLI languages is wonderful, and at least in native .NET languages tends to be "Natural" enough. By contrast things crammed into JVM bytecode tend to become rather ugly IMHO, when it comes to interfacing with Java. I'm not sure if that's due to the JVM or the language implementations I've seen, the changes coming in Java 7 make me guess it's the former. The CLI is likely the next best thing to making a group of languages compile down to native code (for performance) and share some form of common ABI. Fat chance that will ever happen again. I'm sure I want to ponder about VMS, but the whole CLI thing tends to work quite nice in practice The performance cost is worth it for the reduction in headaches.



I'm sure that in terms of performance that Java mops the floor with Mono in some areas, because of how much hacking has gone into it making it a cash cow. That the C# compilers seems to run ring around the defacto standard Java compiler, is what really catches my interest performance wise. Using the mono 2.4.4 and Java 1.6.0_18 compilers, on my very modest system mcs processes a minimal program about 30% faster than javac. In real opeartion it tends to kick ass. When you consider that each compiler is also implemented in the target language, Java really gets blown away. O.K. maybe I care more about compile times than many people, it's the virtue of using an older machine :-P. Combine that with how many slow, buggy, monstrosities have been written in Java—I'll salute C# first.  Another plus is less "Our tools demand you do it THIS WAY" than what Sun threw at everyone. Piss on javac and company.


What has hurt C# in my opinion is the Microsoft connection. The thing with Novell doesn't help either. That Java is not exactly an insanely popular language among hackers, so much as enterprises, is another. The things that have hurt Java, being so closed and being academics choice for stupifying students.


What's the upside to using Java over C#? Easier access to Java libraries, (J2ME) mobile phones, and more finger exercise from all that needless typing! Beyond that it's essentially a win, win in favour of C#.

The STAMAN Project: Phase II, version control

First thing is first: I created the project on my choice of hosting site, than prepped

terry@dixie$ cd ~/proj;git init STAMAN; cd STAMAN; touch README
Initialized empty Git repository in /home/terry/proj/STAMAN/.git/
terry@dixie$ ls
README
terry@dixie$ git add README
terry@dixie$ git commit -m 'first commit'
[master (root-commit) f012d8e] first commit
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README
terry@dixie$ git remote add origin path spec to the repo
terry@dixie$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 222 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To path spec to the repo
 * [new branch]      master -> master
terry@dixie$

In essence, create a new git repo in ~/proj/STAMAN, add a blank readme file and push it to the mirror. Simple.

If you're not using version control, you're brain damaged. It's that simple. 

I recommend Git and Mercurial, because I consider CVS, Subversion, and increasingly Bazaar as well, to be flawed models of doing version control. Git is what I use the most, so obviously I'm using it here :-P.

Much to tired to go into the sanity that is using version control, and using it rightly. Learn how to Google.

The STAMAN Project: Phase I, brain storming an outline

The first thing I did was sit down and spend about 5-10 minutes on brain storming, here's what I came up with on Monday:

terry@dixie$ cat ~/Dropbox/todo-structure.outline
todo's contain
        task short name
        task notes (raw data)
        location
        assoicated url's
        due date
        time estimate
        associated contacts?
        reminder preferences
        list
        project (tag)
        priority

Shebang! YAML would work WELL
terry@dixie$

I like to dive in when designing a program, try and get a good big picture understanding of it, and try to identify the lower level issues that might chop up. The latter gets easier with experience, particularly with your tools rather than the art/science. After writing that file, I took a few more minutes to focus on the implications of its contents.

The purpose of a task management program, is obviously to manage tasks. It is fairly obvious that it is a fairly data centric program; so it's a good place to start by thinking about what is the data. In this case, I took a couple minutes to think about what represents a task: what data it reflects. The short name being provided, as a convenience for listing tasks.

We can't know for sure what sort of tasks will have to be managed, so what data will need to be attached should be kept abstract: it could be anything from a simple cat > notefile like stream of text, or an uploaded doc or photo. The important thing, is not shooting off a foot by making it restrictive.  Since *I* am the principal user, I know the content will be quite variable. Excessively so, the more I utilise it. 

Tagging a task with data like a location, associated URLs and contact info would likely be a good thing. You can easily imagine that going somewhere, talking to someone, or referencing a file off the web are all things that might go hand in hand with reviewing and completing a task.

Another frequent issue is keeping track of when xyz needs to get done, how often it needs to be done, how long its expected to take, and being able to do per-task preferences about the "Nag me about it" problem. Come to think of it, a way to note the tasks progress is a good idea too. Changes like these, are one of the main reasons I want something custom, rather than continuing with my beloved RTM - more control over the tasking details.

Keeping a flexible outline of the project, helps you identify spots to grow and or change it 'in flight', just like that realisation about progress tacking. Of course that assumes you will have time to think about the project, not just write its code like a drone.

Next up to plate, is the issue of organising tasks. I've got so much shit piled into RTM, that I have to periodically triage my task lists, almost like sorting them into a Trove. Notions of lists, priorities, and "Projects" are useful: in order to more easily create ad-hoc hierarchial lists based on such criteria. This is somewhat analogous to what's possible using the SQL SELECT and JOIN statements. Database normalisation can actually be a good thing to learn about^link.  

SQL is not a general purpose programming language, rather it targets the narrower domain of querying and manipulating rows and tables in a database. Although less needed around non web applications, knowing about SQL it is worth it, much like the concept of relational algebra in general. Why I have mentioned Structured Query Language here, is because it's a useful train of thought to explore. Take some time and ponder about the possible formats, and what the code to manipulate it might.

A serious portion of programming is about solving problems, that's what we use our languages for. If changing the rules makes solving the problem easier, that's what we do. Knowing about various tidbits like declarative languages are valuable tools, if you remember to program more like Captain Kirk instead of a dry text book. Don't bend yourself to the language.... bend the language to your problem, or find a tool or architecture that can help fill the gap.


Data storage formats are potentiality a lengthy issue, so I'll go into that later.

With how often people have solicited my advice/opinions of programming matters and CS ed, I've been thinking about exposing the craft behind a project, and posting it as a journal entry. Well, the way my mother monkey wrenches things, I rarely have both the time, brain, and inclination to focus on detailing that much.

So instead, it's probably best that I either decide never to go into the details of creating a program, or just stream it through more haphazardly across my journal. I'll take a crack at the former, since I would like to work on the program.


One of the things on my "To roll own someday" list, is replacing my remember the milk with a local solution. The perks being that I can make custom changes without having to get hired by RTM \o/, as well as integrate it with my work flow more naturally. It's also a good series of mental exercises.


Since I'm not good at naming things, I'll just call it STAMAN—Spidey01's TAsk MANger. Which uniquely isn't far off from Stamina, exactly the rate limiting factor for getting shit done. Especially under my living conditions.

Legally licensed maniac^H^H^H^H^H^HGeorgia driver

At long freaking last.... !!!! I have my license. Murphy's presence also managed to remain fairly minimal. As per local SOP, I'm stuck with a piece of paper for the moment until the plastic arrives. I'm intending to scan the blasted thing for posterity. In 22 years on earth, I've never wanted something so damn bad.

This is bad, lately I'm craving junk food :-S

I've just managed to import my journal entries from October 2009, that should just leave the majority of September, than my transition from Live Journal to Blogger, should 'technically' be complete once and for all!

Give or take 10-20some entries, I would say I'm approaching 1800 posts since I started keeping a journal back in '06. Planning to celebrate my 2000th entry, if I ever notice it's passing :-o.


Also took some time to move one of my older projects to github. Really, it's kind of cool: I sat down and read about 1500 out of 2300+ lines of perl code and could still understand it nearly a year later. Paged through the remaining ~800LOC, which was mostly trivial elements. Someday I need to get the 'uncommitted' test suite committed and work on some cleanup, but it reads easily enough. I don't claim to be a genius, but hell, most of peoples maintainability comments about Perl are either due to Perl 4 experiences or shotty programmers if you ask me. Sure, I enjoy an occasional game of golf, but I like writing code that tends to explain itself.

Perl, the worst thing I can say about it is autovivification isn't all it's cracked up to be, and you quickly learn how to skip reading error messages and just go proof read your syntax. That's kind of a downside of perl, to track down errors in Perl code, you kind of need to learn proof reading ;).

I like using my brain more than a debugger, but kind of like compilers that report useful info. I ain't met many that actually do.

I could swear this dog is smarter than me... she's already got most of the bed, the best of the covers, and sprawled out with a "I know you're not going to move me stupid" look on her face >_>.

At least I got the laptop ;).

Meaning of "Pressured" in my world

Being nagged insessently whilst trying to concentrate, by some selfish, manipulative, royal bitch that's been operating on a certified "If I can't X, no one can Y...Z until" pattern for years — until you would like nothing better in the whole wide universe except to scrunch something in hand and rip it into a hunderttausend fragments.

--> 20+ years of exposure and still legally sane.

Apple Introduces Revolutionary New Laptop With No Keyboard

This demonstrates what is so wrong with our world.

A mind blowing thought

Among the numerous things ma has dumped my way in the "No where else to put but it's *not* allowed to be thrown out" pile, containing all sorts of stuff, was the owners manual to my fathers CB kit.

The shocker? The freaking thing goes as far as including schematics for the radios internal Printed Circuit Boards (PCBs).

I'm used to the typical modern electrical device manual: ya know, the kind that's written in 6 languages and tells you next to nothing interesting, other than silly warning labels.

I can't believe that I've spent most of the last 5-6 hours thinking about ML dialects (SML / F# / OCaml), Haskell, and Lisp :-/

The Band Perry - If I Die Young

This song is really growing on me.

If I die young bury me in satin
Lay me down on a bed of roses
Sink me in the river at dawn
Send me away with the words of a love song
oh oh oh oh

Lord make me a rainbow, I’ll shine down on my mother
She'll know I’m safe with you when she stands under my colors, oh and
Life ain't always what you think it ought to be, no
ain't even grey, but she buries her baby

The sharp knife of a short life, well
I’ve had just enough time

If I die young bury me in satin
Lay me down on a bed of roses
Sink me in the river at dawn
Send me away with the words of a love song

The sharp knife of a short life, well
I’ve had just enough time

And I’ll be wearing white when I come into your kingdom
I’m as green as the ring on my little cold finger
I’ve never known the lovin' of a man
But it sure felt nice when he was holding my hand
There’s a boy here in town says he’ll love me forever
Who would have thought forever could be severed by

The sharp knife of a short life, well
I’ve had just enough time

So put on your best boys and I’ll wear my pearls
What I never did is done

A penny for my thoughts, oh no I’ll sell them for a dollar
They're worth so much more after I’m a goner
And maybe then you’ll hear the words I been singin’
Funny when you're dead how people start listenin’

If I die young bury me in satin
Lay me down on a bed of roses
Sink me in the river at dawn
Send me away with the words of a love song
oh oh


The ballad of a dove
Go with peace and love
Gather up your tears, keep ‘em in your pocket
Save them for a time when your really gonna need 'em oh

The sharp knife of a short life, well
I’ve had just enough time

So put on your best boys and I’ll wear my pearls

If I Die Young—The Band Perry

Stupid, just stupid MS!

Another from the same Microsoftee publication:

Consider using events to allow users to customize the behavior of a framework without the need for the users to understand object orientation.

Now I ask you, what part of using an object oriented language to build an obviously object oriented assembly (the guide is on class libraries), in an environment almost universally thought by users to be object oriented, and on top of that in a language that uses object oriented programming techniques to implement event handling.

What next, telling the programmer to only use stack allocated data because relying on a garbage collector is too hard a concept to comprehend? Seriously, who the **** writes **** like this.

LEARN HOW TO ****ING PROGRAM **** IT!!!

Post Script: In the above quote from MSDN, I added the bold on 'understand' for emphasis: where as the MSDN library displays the entire message in bold.

Stupid Warning Sign for Programmer

Important! The term "protected" does not imply any security checking or caller validation. Protected members can be accessed simply by defining a derived class of the declaring type.

I do think that is the Object Oriented Programming version of a stupid warning sign . That quote above about protected members comes from Microsoft's design guideline for developing .NET class libraries. Which obviously means common language object oriented principals apply.... you would hope.

That has also got to be the stupidest cautionary message that I have ever seen in a document intended for programmers. What next, writing "May irritate eyes" on a can of pepper spray!?

Somehow I find it kind of sad, that over 50 years later, we still lack a programming language clearly more advanced than lisp. Either that or lisp just grows with the times better than most 0.o.o.0.

Shoot, between a seminole and a zombie slayer, now I'm craving hostess twinkees!

I missed my intended travel window for hitting the library, but on the upside, for the first time in a long time, I *really* enjoyed a good film—Zombieland!

The jist of it, is "Mad cow disease became mad person". It's also the first and only zombie flick I've seen that makes note, that the fatties got eaten first xD. Combine a hopeless idiot whose just lucky to be alive with a zombie killing machine searching for Twinkee's, and you've got a recipe of some kind. Add in two sister con artists heading for an amusement park and it gets better :-).

The thing that surprised me is Bill Murray showing up in the middle of it all. Just priceless!

A programmer programs,
A painter paints,
A pilot pilots,
A inventor invents,
A sculptor sculpts,
A writer writes,
A sailor sails

What do all these have in common? Each only needs the right to prefix their name with "Doctor" and point at a plaque on the wall, before they may philosophize before students and profess to doing anything in class!

Programming a computer is as much related to the business of developing software as piloting an air plane is to the business of dropping bombs. Uniquely so when you look at the typical software product :-o.

If the words noun, verb, and dictionary mean nothing and you happen to be an American, you seriously must have slacked off through the elementary school grades more than I did ^_^.

Poly want a quacker?

In my efforts to "Bury myself in code" rather than let this place get the better of me, I've been getting plenty done.

On the computing side, I've made around 25-30 commits between version control systems, including finally wrapping up a project that's been waiting weeks to get pushed out. Even crashed yet another compiler with a typo, but this time it was one I could file a bug report against ^_^.

Today alone, I've employed about 5 computer languages, plus my laptop is still displaying most things in German and google-chrome is set to English. Yesterday tack on Python, Ruby, and brain storming for something lispy of my 'own' on top of all that.

Sometime when I get around to it, I need to find time to acquire a few more languages lol.  I've an interest in picking up Haskell and ML, the former because I often encounter snippets of it and the later based on what MJDs written about it on the web.


Programs have no language, they are the language.

Woke up at 0600 just to get back to coding before work. Fell asleep trying to figure out the solution to a problem and dreamed of getting my eyes checked, ending up dizzy as heck. Woke up and fell asleep trying to figure out if the compiler is smart enough to tune the solution without my "Help". Then dreamed of chasing Escrt around a modified RvS game with iron sights, before falling down a 50~70m pit in the process lol.

It's true, reading around MSDN is that boring.