Project management software and scope creep

Project management is just one of those areas I keep coming back to, from a semantic standpoint. Since it's by definition a tool that every software development project must use (to paraphrase a financial management book I once read, if you have a project, you will manage it - the question is whether you'll manage it well or not), every software developer sooner or later takes a stab at building a project management tool.

As a result, the space is cluttered with three million solutions, all of which do more or less the same thing but expand out to include every aspect of life within an organization. This is scope creep.

Why does it happen? A lack of semantic explicitness.

Case in point - or rather, what's set me off this time: my son is doing a self-study course of AP Macroeconomics. To finish it by the time the AP exam rolls around in May, we have to make a schedule. And as I was doing that by hand with a calendar, of course, I thought: I should be doing this in Perl.

But you know what? CPAN doesn't really have anything that does that. And when I go off to find general project management tools in the open-source space (let's not even talk about the proprietary space!) I find at least a dozen contenders.

They all involve stack lock-in, to a greater or lesser extent, because, well, that's what syntactically specified software does.

And yet we all know roughly what's meant by project management. That is an area rife for a semantic approach. Sadly (or, well, it's not really sad) all my free-time development cycles are taken up by robotics these days. So this might have to stay on the back burner for another few years. But eventually I promise you....

Declarative knowledge on the CPAN

I was struck today once again by the realization that CPAN contains a lot of declarative knowledge hidden inside various modules. This time it's Date::Calendar::Profiles, which contains a great deal of information about holidays around the world. A CPAN module is probably not the best place to maintain that stuff, but there it is.

Literate programming posts

HNN seems to be posting about litprog again lately.

Here's one about literate Clojure. [hnn] Jacques mentions Leo, which I think I evaluated and didn't care for, once. I don't remember why.

John Shipman responds to the notion that "literate programming [is] considered harmful" (just because you quote the greats doesn't mean your insights are great).

Well, that's just two. Could be coincidence instead of enemy action. But it was enough to make me notice.

Excel and statistics

This spring I worked through an entire statistics class in Excel (well, mostly in Excel). This is mostly because I somehow never actually learned any statistics in college and still have to understand the concepts for translation, but also partly because I've done some other math-oriented stuff in Excel and wanted to learn more about that.

Here's the thing: like many Microsoft tools, Excel can be incredibly powerful - as long as you're using it the way its designers conceived. Go off the reservation and abruptly things get very difficult.

But it's worse. Turns out that specifically for statistics, Excel kind of sucks. Like, wrong-answer-level sucks. The recommendation of the article in the link: use R (or some commercial statistics package).

So here's an interesting idea: wouldn't it be interesting to build a spreadsheet tool that translates to R behind the scenes? Plus has somewhat better handling of tabular data? (That part drives me crazy in Excel: I have to know the shape of my data in advance.)

There might well be such a tool already. If not, it would be fun to build it.

Felix

Felix is a high-level compiled scripting language with a kitchen-sink approach that appeals to me. It kind of feels something like what I'm fumbling towards in the machine end of Decl.

Table-oriented programming

I'm fairly sure I've seen something along these lines before, but this came up on HNN this week and piqued my interest. (As usual, the "this reminds me of...." comments are a treasure trove of fascination.) (Also, it's not the first time it's been on HNN.)

So the idea is essentially that collections are poorly handled in ... basically all existing languages, including SQL. And you know, that's entirely true. But since Decl has essentially made tables a first-class object in the language (I mean, I just keep running into them, you know?) maybe it would behoove me to think more deeply on the whole issue.

This site is moribund - in fact, archived off GeoCities - but I should archive it to a project directory and see if I can distill out a few good principles to bake into Decl.

It's full of sound advice. Data dictionaries, for example - that's something that keeps cropping up in my notes, and has for years. Anyway, the author seems to have been a prolific opponent of OO programming on Usenet, and frankly not terribly well-regarded, but many of the ideas here are quite sound.

Here's an interesting sort of philosophical rumination on the matter: OOP Oversold?

My thoughts: essentially, any single way of approaching the problem of organizing software is just a view onto the semantic content. Sometimes OOP will be a great help (well - it's basically always a great help) and sometimes it's more natural to think in terms of tables, or a functional language, or what have you.

But they're all approximations. Like mathematics, there are myriad valid ways of looking at a given problem, and they're all true. Forcing your expression into a single paradigm will basically always fail, because there will be some meaning that has to be ignored in order to fit the framework.

The only way to get around that is to have a framework as closely aligned with natural language semantics as possible. Hence Decl.

Still, though. Tables. Gotta think about this.

Oh! Also, people keep mentioning Lua when talking about tables. A really quick Google doesn't tell me much about why (except that Lua calls its hashes tables), but some more in-depth investigation would probably be a good idea.

Gherkin/behat

Gherkin is a language used for "behavior-driven development", in which a restricted subset of English (or some other natural language) is used to describe the behavior of some software. Behat then tests it using a domain model, which I find interesting. It's part of the PHP ecosystem.

The idea is that you've got a description of usage scenarios that you can agree on with non-technical users. I think that's pretty cool. But also you've got a higher-level description of the program, which arguably is something the programming system should use and/or have access to. The descriptions there are clues to the semantic domains you're interacting with, so analysis of them should result in a reasonable semantic model of the program.

Anyway. Worth thinking about.

Language dilettantes

Interesting post on stability versus features (well, more than that: read it), referring back to an interesting attempt to quantify a number of programming languages with a scoring system [wayback] and the whole thing set off a pretty interesting set of musings at HNN, as per usual.

REBOL

REBOL (Relative Expression Based Object Language, an acronym that somehow evokes the TARDIS to me) seems to be a language that has a lot of the semantic aspirations that Decl does. Interesting!

Alda: yet another music language

Music in Clojure, apparently.

6 lesser-known Python data handling libraries

There is just a lot of neat stuff in Pyworld. Data handling, for instance.

wftk again?

So here's a neat little checklist management system that sure looks a lot like the original goals for the wftk back in 2000: Checklistomania. [github][hnn]

As usual, I have the inchoate feeling that none of this would be a tenth as challenging in Decl. I should work on Decl.

Programming games

That is, games that involve programming (including Stockfighter) - cool post.

System design cheatsheet

Interesting.

Futhark

Futhark is a special-purpose language for specifying GPU operations that can then be embedded in a driver program running on the regular CPU. This is really pretty cool.

Book: Procedural Content Generation in Games

Looks interesting.

The Organized Crime and Corruption Reporting Project

The OCCRP is another of those data journalism efforts that make me drool. Text analysis, oooh.

HNN thoughts on declarative specification of Excel

Just a note for later. I've been using a lot of Excel lately - it's a great tool, as far as it goes, but when you reach its limits, you've just plain reached them. There are some interesting points made in this HNN thread, some of which I'll enumerate at a later date.

R and semantic programming

I'm reading a pretty fascinating HNN thread on R today. I haven't worked a lot with the R/Matlab/Octave types of languages (my daughter has, and I've helped her debug things, but I don't really know what I'm doing with them). It seems that a semantic approach, kind of layering type inference onto an editor or something, might be really interesting here.

Worth considering, anyway.

Automatic Differentiation

Well, this is just all kinds of cool. I hadn't realized you could calculate the differential without differentiating. Just ... never occurred to me, although in retrospect it makes sense.

I really want to do things with this.