Yes, I am working on a little something. Something very special. Unfortunately, it takes quite a lot of code. Watch this space…
A while back I wrote a backup application which allows you to compare folder structures on different disks. I still use it, and it’s useful for keeping Dropbox folders, USB keys etc. in sync.
I haven’t written much documentation for it, so you’ll just have to try it carefully. Best to have a go with some files that aren’t utterly vital, as it’s perfectly possible to delete lots of stuff. 32 bit MSI, and 64 bit MSI available for download.
It’s always important to distinguish the genuinely new from the repacked and reinvented. Large companies with lots of manpower are awfully good at taking an existing technology, putting a new spin on it, and then releasing at as something “new”. (The old new thing?). This then puts the competitors in the situation where they need to catch-up to the new API / gizmo / widget / whatever.
Know where you are leading, and where you are following. From a commercial, time and cost standpoint, API chasing is a bad thing.
Why does it take so long to write really good software? Unfortunately, it seems that the devil is always in the detail, and things take longer than expected. I’m definitely not the only software developer where I have a bright idea, and I can conceptually see exactly what I want the software to do, but actually getting it to do that turns out to be a long and arduous battle.
Unfortunately, software is not a forgiving medium: for every situation where you can see roughly what you want, you then have to describe it in precise and excruciating detail to a CPU that has no intelligence whatsoever.
Another thing is writers block. If I’m enthused about something, then I can just code and code and code, but tricky details being what they are, sometimes, you have hours or days when the old grey cells don’t quite want to get themselves round the problem.
Another productivity issue is the extent to which you want to reuse code. Some people like being “hobby kit” programmers: they are very happy to take freely available bits of code off the web, and them sew them, patchwork quilt wise, into a product. The catch is of course that when it comes to code licensing, it’s not necessarily all theirs, and although it’s invisible to the end user, some of the hacks that get written to get unrelated modules of code to co-operate can be just plain ugly. A quicker way to get a product, but down the line, the developers start muttering, ewww. yuck!
Me, I tend to be a bit of a perfectionist, and I can write the code myself, I will. The downside with that is that after a decent software engineering degree, with the exception of things requiring specialist knowledge, I should be able to write the code for most things. Which means of course, that my default attitude seems to be “oh, I’ll just write a few more thousand lines, and it’ll be there.” Streaming systems, no problem, Object hierarchies, no problem, parsers, no problem, vector and matrix math, no problem, database persistence systems, no problem, interpreters, no problem…….
The problem is that when you want to write everything exactly the way you like it to be, it takes absolutely ages. It used to be that by the time I’d written five or six thousand lines of code, I couldn’t help but end up with some sort of a working program. Nowadays, I can write twenty or thirty thousand lines of internal structure, and still end up with a simple test program that has nothing but a text box, and two buttons on it! Ahhh…. such is the path of progress.
My favourite bugbear. Appropriate delegation / compartmentalisation / structure in OO software. There are some excellent books concerning design patterns and anti-patterns. The general rule of thumb is: stuff in a class deals with that class, and delegates to neighbours as appropriate. So:
- The code that formats the message, is not
- The code that retrieves the data that the message needs, which is not
- The code that trawls through some structure looking for a target which might know how to deal with the message.
For those that don’t have time to read through the official textbooks, my rules of thumb:
Do one thing and one thing only in a function, examples:
- Formatting a message.
- Updating internal state on the basis of a message.
- Delegating things elsewhere.
- Performing some algorithmic calculation.
- Converting from one format to another.
OO software works well on the basis of ignorance. Yes, it’s important that the code does stuff, but really good OO code works well when each bit of code knows only about a relatively limited subset of its own class, ancestor classes, and a minimal subset of stuff around it. Code should be as ignorant as possible. i.e. Keep your design contracts simple.
That means good OO software should be generic. Yes, some bits of code have to know the knitty-gritty of how some algorithm works, or how some data is structured, but in general, if your code does not know how to do X, and X is not locally or closely related to your class, then just delegate it elsewhere.
Joel-esque rant over.
To showcase the parsing code I’ve written, I now have a demo app which allows you to view the structure of pages, not unlike the debuggers in MS Edge, Chrome etc. For example:
It’s not perfect, but it does pretty well on most pages, and I am still improving the underlying code.
If you’d like to get hold of the source code or like the parsers as a library, then feel free to contact me, and we can discuss your educational or research use, or negotiate licensing terms.
Delphi has fairly good support for RTTI (reflection). Quite a few of my programs need to stream sets of classes to disk, and read those classes back. This library leverages the RTTI system to provide automatic streaming of classes and published properties, with an extensible API to perform custom streaming.
The source is here. No documentation I’m afraid, you will have to read code and think.
A couple of years back I wrote a simple fractal generator to test some of my threading libraries, and a custom streaming system that I had written. It generates very pretty pictures like this:
For those wanting to get techy, and as it contains plenty of good sample code, the source can be found here.
For the past year or so I have been working with an updated port of CoCo/R for Delphi which I made when finding some older implementations did not work well with modern versions of the Delphi compiler and environment.
I would be interested in feedback and comment.
Delphi offers some fairly simple containers: list, queue, hash table, but does not have trees or tries.
I present here a multi-index container which maintains a doubly linked list, with multiple (sorted) indexes into it. The indexes are implemented as AVL trees. You can create custom indexes and perform high speed efficient sorting, searching and iteration.
Unlike the STL, no knowledge of templates is required.