The Windows binary worked for me using Wine in Linux.

I like the game. The interface is nice and clean, and I like how the text "slots" adjust to fit the size of the text placed in them. Nicely done.

I've seen a few projects using D pop up recently. I'm curious, what are the advantages to the D programming language?

Thanks for the comments!

Hmm, the last "Next" button should be in fact a "Finish" button. However, I agree that it's not anywhere near to being a gratification for completing the game . The competition deadline was approaching... well, you know the rest.

I'll share my take at it. For me, D does not have any one "killer feature". Instead, it has the small niceties I value in other languages, baked into the single language.

• I like being productive when all I care about is to make things work, the sooner, the better (rich standard library).

• I like it when the language is reasonably safe so I can write code with just few bugs (type system, general safe-by-default attitude), and then have means to find the rest (stack traces, easy debug output).

• I like it when the language compiles to native code so that speed at the bottlenecks is on par with what I can possibly do (e.g. using C).

• I like coding in a simple text editor (so e.g. Java is too verbose for me).

• When a program gets larger and evolves, I often become frustrated by the amount of restructuring and boilerplate I have to do. In this regard, D was the least disturbing experience compared to the few other languages I used to this extent (Pascal, C, C++, Python).

Sure, there are also some difficulties, like low popularity (only few people around me try D), instability (the language is still evolving, the specification is not set in stone), occasional compiler bugs (no massive manpower backing language development) - but since you asked about advantages, I won't get into details now .

While I agree with your points in general, I find this one interesting, because do you know that DMD doesn't generate very fast code at all? Did you use one of the other compilers? I tried one or both of the others a while ago (a year or more?) and hit some problems (possibly exceptions didn't work?). Presumably they're always improving though, and I noticed the download page on the D website encourages the other compilers more than it used to.

So, as for your game - I found the idea nice at first, if a bit daunting. When I realised that you don't have to think about the poems at all since you can just keep trying stuff until it lights up, I was pleased I had an easy way out but also a bit sad that the mechanic allowed me to ignore the poem entirely. Not sure how I'd fix that myself. I do recognise you had very limited time, and it's nicely done considering

How's your luck with debugging?

I'm learning D on-and-off and every time I do something wrong, I'm greeting by a SEGFAULT and a stack trace completely full of garbage collection.

Like one I mentioned in a previous thread, I dared to use a string concate inside a destructor/finalizer (which invokes the Garbage Collector and crashes). It was a nightmare coming from C++. All I was doing was trying to output a message when a class was deleted.

I feel like debugging in D is many steps backwards compared to Clang with C++ (which is downright beautiful.) (It seems like) I rarely get the right line number, and the stack trace is always clobbered.

So how do you go about debugging successfully? I know that once I stop making "insane mistakes"... mistakes that someone who understood the language would never make, I'll probably be better off.

I also wish there was more tool chain support. Like the plethora of static and dynamic analyzers for C++ and other more popular languages. At least Valgrind (should) still work for dynamic code coverage, and I found D-Scanner for static which I might start hacking to add my own custom code-checks.

Hmm, what OS and architecture are you on? I'm on Windows and usually do 32-bit builds, sometimes 64-bit. All I do is throw a simple -g switch into a debug build. The line number of the bottom function, like main, is usually corrupted, but since I'm most interested in the top of the stack anyway, this is rarely a problem.

The only thing for which I don't get a meaningful stack trace is stack overflow (oh the irony), but the fact makes it easy to distinguish as well.

Regrading clang for C++, I have to try it to compare. GCC (which I use) does not show any stack at all, and even with a switch like _GLIBCXX_DEBUG, I only get to know that, for example, an out-of-array-bounds happened somewhere, but not the exact location.

Also, debug output in D is super easy compared to C++, with debug writeln (x); doing the right thing for many types out of the box.

Some tools for analysis, like profiler (-profile) and code coverage (-cov), are built into the compiler. But sure, there are tons more tools for C++.

Your mileage may vary. For instance, if you depend on a library which relies on LDC or GDC optimizations (heavy use of ranges everywhere is an example), you will definitely get the slowdown compiling with DMD. As I've said, my measurements are for short standalone number crunching programs.

Also note that not only LDC and GDC are improving, but DMD as well ...

Heh. So the difference is that I much prefer debug output and inserting a bit of assert contracts to interactive debugging. But we're not going to start a holywar over the Right Means of Debugging, right?

DMD is the fast compiler for D (but producing slower binaries, as discussed above). Did you try DMD on your system? The site http://d-apt.sourceforge.net/ may be worth a visit. Or not; I don't use Linux much, and didn't try the D APT repository myself (or GDB on Linux binaries generated by DMD, for that matter).

Exported from personal Subversion repository to GitHub (if only to prevent a thread lock): https://github.com/GassaFM/Spring.

A bit of story on my TINS experience to make this post interesting.

On Friday, we just discussed the rules and thought about making a rhyme puzzle, only the designs were either not likely playable or didn't have pathfinding, so we thought about making a simple but completely separate part for pathfinding.

We spent like the whole Saturday with our two kids, busy with real-life stuff.

On Sunday, I went to implement some interface primitives, and ended up with a few GUI classes for the bright future, a working menu screen to test them... and nothing more since real life kicked in as it tends to.

So on Monday morning I was sitting at my PC thinking that it's over for us. Eventually, I found some ways to boost my morale, amarillion's post among them (thanks!!!). As it states, Anybody can write hangman in 2 hours. Well, a rhyme puzzle is not too far away. So I just dropped the idea of following the grand plan of our entry to any degree, and proceeded with the strategy of "just put in the next tiny thing that would work; repeat". Indeed, the GUI design was not yet too horrible and was extended with a few hacks, so two or three hours later, our entry finally resembled a playable game.

In the end, I didn't find a suitable English verse with literal "snow" in it (the Russian version has two occurrences of the word), and about pathfinding, I can only do a suspicious hand-wave, but the other rules are fine.