Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rafal99]

Besides, isn't it also rumoured that the source code is so mind-buggeringly complicated and idiosyncratic that nobody else except Toady can really understand it?

This statement is getting repeated in every single thread about opening DF source, but do not see how it has any basis in reality.
If Toady wasn't writing a good code he wouldn't be able to handle such a huge project for so many years.
Looking at structures which are read from DF memory by DFHack, Toady uses a pretty good object-oriented design.

But I agree that if you work on a project alone you are likely to make simplificatiions, like do not document the code, do not put comments, and possibly use variable/function names that make no sense to anyone except you. But after all, you still have to write a good, generalized code, otherwise you will fall in your own traps pretty soon.

[KoboldWarmonger]

Besides, isn't it also rumoured that the source code is so mind-buggeringly complicated and idiosyncratic that nobody else except Toady can really understand it?

This statement is getting repeated in every single thread about opening DF source, but do not see how it has any basis in reality.
If Toady wasn't writing a good code he wouldn't be able to handle such a huge project for so many years.
Looking at structures which are read from DF memory by DFHack, Toady uses a pretty good object-oriented design.

But I agree that if you work on a project alone you are likely to make simplificatiions, like do not document the code, do not put comments, and possibly use variable/function names that make no sense to anyone except you. But after all, you still have to write a good, generalized code, otherwise you will fall in your own traps pretty soon.

In addition to the things you mentioned, Toady:

1) Is a mathematician. There are probably a few problems he solved in ways not obvious to someone who programs for a living. Worldgen is some crazy weird black magic, I'm sure.
2) Has been adding ORGANICALLY to the code for upwards of a decade now! He falls into his own traps ALL the TIME.. this is why instead of fixing things he will (sensibly) often opt to rewrite them entirely, as much of it is placeholder. He's only very recently had frameworks in place for *most* of what is going to happen in the game.

There's no way to know, for sure, cause we can't see it. But because of the tone of the dev logs and the nature of projects this large multiplied by the fact that its a one-man show, by one man who's never been formally schooled in software engineering and all the little organizational best-practices that people know by now...

if I were a betting man, it's obvious where my money would be. Total clusterfuck.

P.S. Can you really tell if it's *good* OO design by looking at the unit data that gets read by therapist? I mean, you can certainly tell its broken up into objects, but is it good? And besides, units and other actual physical things that get modelled lend themselves to being thought of in a certain way- for more abstract bits of data, you're going to start having to make judgement calls.

[Telgin]

...by one man who's never been formally schooled in software engineering and all the little organizational best-practices that people know by now...

...Total clusterfuck...

Heck, I have been trained as a software engineer and any of my stuff longer than about 500 lines turns into that.  At least on the first iteration.  I have no doubt that Dwarf Fortress is messy inside, but at least Toady has taken the initiative to rewrite subsystems as they are no longer able to support what the game needs instead of mercilessly tacking stuff onto them and adding lots of duct tape.

Truth be told, I'm thoroughly impressed with how much of the game Toady has been able to rewrite and not have to throw the whole thing away.  The C++ rewrite was probably nightmarish alone.  Then there's stuff like adding a z-dimension to the game...

It must be reasonably well organized inside if he's able to do that.  Or it's getting there if it's not.

[Starver]

Besides, isn't it also rumoured that the source code is so mind-buggeringly complicated and idiosyncratic that nobody else except Toady can really understand it? He is after all a mathematician by training rather than a software engineer.

Don't underestimate the ability of software engineers to also create mind-buggeringly complicated and idiosyncratic code.

Personally, I'm going to 'grow' one of my future projects, through 'genetic' code morphing, morphing and distorting a large number of randomly varying copies, culling the least satisfying programs and repeating with the rest...

Who knows how humanly readable the result is going to end up, though...

(Yes, before you ask I've already done it with something simple and RISC-ish[1].  Of course, getting it working with full executable code-set it going to take a bit more infrastructure development, and runs the risk of creating something SkyNetty, along the way... )


[1] Actually, at least twice.  Once with RedCode (for Corewars) and another time with a severely restricted (but utterly self-modifiable!) instruction-set/architecture simulator of my own design, that was very nearly the subject of one of my dissertations at Uni...

[Starver]

Not that it's awfully relevant to the thread, but just to expand on that last throwaway comment of mine..

Those two different instances were two differing approaches to mutating algorithms.  For the Corewars example, I used a "Genome" consisting of many times more (valid) instructions than I was intending to use, with a majority (perhaps 90-95% of them) being totally commented out, essentially "Junk DNA".

Mutations could occur to the opcode or operands of any code, commented out or not, so that there could be a high degree of non-fatal variation introduced to the code, but the mutative process also had a chance to move instruction lines out of/into comments.  Multiple examples of similar-looking code coincide that are functionally the same (and survive the culling if at the top of the current cadre) could accumulate a whole host of different mutations in a population before being "tested" against each other and their predecessors..

For the other example, there are no invalid instructions possible (and instructions/data entirely interchangable, overlapping and self-modifying during runtime!), and "commented" ones were just ones that never ran in the first place due to loops and jumps skipping over code, or back round again.  That was just a simple matter of randomly setting and unsetting individual bits in all offspring.  It's particularly interesting to try and interpret the 'successful' offspring and work out how they managed to do accomplish the selected-for task the way they did.  (And often quicker than a fully-designed setup purposefully written with full inside knowledge of the language instantiation and the intended end-product!)


However, neither way is how I'd suggest DF gets programmed.

[MarcAFK]

I figure that by the time Toady's finished with all the core goals and has the world operating with self sustaining procedurally generated physical, cultural, economic and social systems modelled he will probably just spend the next couple of years working on an increasingly complex "procedural A I" for entities that will end up unexpectantly Turing complete.
Then someone leaves dwarf fortress running through telnet for too long and we get that whole skynet thing going on.
I'm looking forward to it.

[Urist McDepravity]

Re. "horribly complex code noone would understand" - this was already proven wrong by Quietust, with his binary patches.
If its possible to understand and fix bugs in compiled form, its definitely possible to do same with source code, and definitely more efficiently.

Also, re. "Toady's Vision" - there is still option to proceed with features alone, but leave bugfixing to community. There are 2000 open tickets in mantis, there's definitely some work which Toady doesn't want to do himself, but community would gladly pick.

[Bulwersator]

Also, re. "Toady's Vision" - there is still option to proceed with features alone, but leave bugfixing to community. There are 2000 open tickets in mantis, there's definitely some work which Toady doesn't want to do himself, but community would gladly pick.

Fixing bugs is not trivial task, see OpenTTD - it is completely open, certainly with way saner code than DF and almost nobody provides bugfixes. And the important part is ensuring that bugfix really fixes problem without introducing new ones.

Re. "horribly complex code noone would understand" - this was already proven wrong by Quietust, with his binary patches.
If its possible to understand and fix bugs in compiled form, its definitely possible to do same with source code, and definitely more efficiently.

It is possible to read any code (for example Stuxnet [computer virus, cyberweapon created by USA to destroy Iranian nuclear facility] was decoded from compiled form), but it may be so bad that improving DF will be less practical than creating a clone.

[Osmosis Jones]

Why don't you ask Baughn (one of the few guys to have seen some of DF's raw code)?

From memory, (I think it was in a post in the old FotF thread) he said it was messy, but not unreadable.

[Urist McDepravity]

Fixing bugs is not trivial task, see OpenTTD - it is completely open, certainly with way saner code than DF and almost nobody provides bugfixes.

It just means that these bugs do not really bother anyone.

And the important part is ensuring that bugfix really fixes problem without introducing new ones.

Any sane project uses test suite with regression tests for that. This is another area which could strongly benefit from community - writing tests is boring, and I doubt that Toady actually does it, but having good test suite helps significantly.

It is possible to read any code (for example Stuxnet [computer virus, cyberweapon created by USA to destroy Iranian nuclear facility] was decoded from compiled form), but it may be so bad that improving DF will be less practical than creating a clone.

It was "practical enough" to Quietust to debug game w/out sources and make binary patches rather than making a clone.
It was "practical enough" to Baughn to improve rendering part of the game w/out complete rewrite. IIRC, his project started with simple hacking into binaries too, before Toady cooperated with him.
Many of current bugs do not require complex modifications, and are easy to fix, no matter how "bad" are sources.

[Rafal99]

From memory, (I think it was in a post in the old FotF thread) he said it was messy, but not unreadable.

There is no such thing as unreadable code. Period.
Every code can be understood sooner or later even if it was deliberatery coded to be bad and then compiled by compiler that messes stuff around.
But DF is none of these, it is as good code as any.

Fixing bugs is not trivial task, see OpenTTD - it is completely open, certainly with way saner code than DF and almost nobody provides bugfixes.

It just means that these bugs do not really bother anyone.

Exactly.
From my experience with open source projects, when people encounter a bug, some of them will soon check the code out of curiosity and then if the bug is simple then they submit a bug report with exact info which lines of code are bad, or even submit a patch. And 80% of the bugs are simple logic or typo bugs that can be spotted and fixed quite easily. Look at the examples in DF - the bug that made wagons not appear, which Quietust fixed with binary patch - was because one single "if" instruction was wrong.
The other 20% of the bugs is usually more of a "lack of feature" and will require attention from the core developers anyway.

(...) but it may be so bad that improving DF will be less practical than creating a clone.

It will never by more practical to make a clone. Fixing a bug is usually a few hours max including debuging it at first and testing after fix.
Making a clone is years of work, this is why noone would do it. There are several games inspired by DF but none really aiming to be DF clone, they all only focus on a small subset of DF features.

[Bulwersator]

Why don't you ask Baughn (one of the few guys to have seen some of DF's raw code)?

From memory, (I think it was in a post in the old FotF thread) he said it was messy, but not unreadable.

He had access to only small part of code (related to graphics).

[Osmosis Jones]

Why don't you ask Baughn (one of the few guys to have seen some of DF's raw code)?

From memory, (I think it was in a post in the old FotF thread) he said it was messy, but not unreadable.

He had access to only small part of code (related to graphics).

Yes, like I said, *some of* It still is enough to give an impression of Toady's coding however, and it was more recent than LCS.

[Reudh]

I think from now on we should just automatically derail any 'GIMMEH DF SOURCE CODE' threads with anything DF related.