Print

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

[Two]

"working by chance" is more like you run your code and it surprises you that it actually works fine. The opposite is code that was designed to be fail-safe, has been incrementally tested step by step and works fine as the result of carefully engineered architecture. Also please note that I don't blame him for any of this, as actually the majority of programs are in this state. You start small with a small idea, release it and it works fine. Then you add a few ideas here and there, and after some time you realize that you actually never structured your code, but that it would now take way too much time to do that.

Minecraft is another good example of this. They are actually in the process of restructuring the code since 1.7, and after about a year or so, they finally managed to streamline at least the graphics part. With a big team of programmers and a lot of money to back them up.

[draeath]

If - big word, if you program things correctly from the get-go then a 64-bit build is just a toolchain argument away.

Even if you don't, once you repair your portability problems from then on it's a simple build switch. There's no "maintaining" a distinct 64-bit build.

[Two]

That is why I love coding in Java. You neither have portability issues, nor a tool-chain. It just runs.

[draeath]

That is why I love coding in Java. You neither have portability issues, nor a tool-chain. It just runs.

Incorrect on both counts. You do have a toolchain - you execute java bytecode, not java code directly. In fact you have to compile it yourself with javac, contrasted with something like python. For the other point - try working with RS232, or even some of the more esoteric SSL items - case in point, at my last job we had a major nightmare because our SSL code didn't work on IBM iSeries, but it did work on Windows and Linux. Regarding the other bit, RS232 worked on some platforms and on others the support simply didn't exist - got some weird JRE errors when that happened.

EDIT: wow that came out awkward. I hope you understand what I'm talking about

[ShadeJS]

Actually, there's been SEVERAL features that have been accidentally removed, like the diplomats.  In the .34 release, caravans came at the opposite end of the season they were supposed to.  There's been several times on the journal where he's written something along the lines of "I went ahead and rewrote the code for xxx. It was a much bigger job that I thought it would be." A current example would the the mood rewrite, in which he stated that he's glad that he left it for after the big release. It isn't that its was complex, it is a symptom that his code is more "Jury-rigged" than he first thought.  Yes, there IS a "working-by-chance" state, though in all honestly, its not ruly "working by chance." Its more of a "Working in a way that that he wouldn't do with his experience today."

That's more of a QA thing than 'by chance'. Personally I think Toady would probably benefit from a 24 hour 'play day' whenever his brain goes, "Time to cut a minor release!" that sees him play fortress mode and adventure mode. Working 'by chance' was the person flirting with me in intro to C 15+ years ago. I just think that Toady may want to 'eat his own dogfood' for a day before he releases. Though I'm mostly OK with the notion that releases will vary in quality.

[Two]

I just think that Toady may want to 'eat his own dogfood' for a day before he releases.

I am pretty sure he does it all the time, also dogfood is hardly appropriate for one of the most in-depth and entertaining games on the market. If you take a look at the bug reports, you see that the main part of the game is working just fine, but the details are not. And given a game of this complexity, you cannot expect a single man to test all the details before every release, or we wouldn't have a release for the next few years. What Toady lacks is a professional team that supports him, but then such a team eventually demands salary, and that means DF needs to come with a price-tag, and that means certain features like graphics need to be adjusted to please the customers. A tantrum spiral of intense magnitude.

Incorrect on both counts. You do have a toolchain - you execute java bytecode, not java code directly. In fact you have to compile it yourself with javac, contrasted with something like python. For the other point - try working with RS232, or even some of the more esoteric SSL items - case in point, at my last job we had a major nightmare because our SSL code didn't work on IBM iSeries, but it did work on Windows and Linux. Regarding the other bit, RS232 worked on some platforms and on others the support simply didn't exist - got some weird JRE errors when that happened.

Well ok... if you call the one compiler tool a chain. Ok technically you could add Ant to that list, however I usually start counting the tool chain at the first item that I need to worry about, and thats 0 with Java, because all I need to do to release is to press one button and then wait for a second. If I compare that to the C/C++ nightmares where I need to make sure that really everyone kept the make files up to date, and that 20-30 minutes compile time on larger projects. I really gives me the creeps just remembering it.
Esoteric things as you describe are not supported by Java, and you can hardly blame a tool for not working properly with something that is not supported. And yes I do know the pain, I once run a RS232 project in Java and initially told the customer that this should be a day's work... we never finished it.

On the other hand the benefits of coding in Java: 64 bit is the new thing? Supported without even touching the code. So people now do have more than one CPU? Give me a minute... aaand we are multi-threaded. So your program crashed? There is a detailed error log that tells me where and why so I can fix it. Always.

[draeath]

Ever get stacks from the JVM itself? That makes me queasy - seen that a few times.

Meaning your program didn't crash, the JVM itself crashed.

[King Mir]

That's pretty much it. Toady has also said that his code is absolutely terrible, so there's that.

I'm not saying there's no hope, mind. I am, however, saying "don't get your hopes up".

If his code was *ACTUALLY* terrible he wouldn't still be releasing DF. It would have collapsed under it's own complexity long ago. It sounds like he writes non-idiomatic Cish C++ that works for him. Given that he's (mostly) a one man show when it comes to the code that's not as much of a problem as it sounds. The bigger question is, "What does a 64 bit compile buy other than a slight slowdown?". More address space... Most people here like short histories, on small, lower population worlds, with smaller embarks 'for the FPS', so that's not much of a gain. Given the lack of big video, big textures, big models, and big audio I'm quite sure that a lot of the stuff that lives in memory now doesn't need to be there permanently if an actual problem with the amount of memory needed does (regularly) emerge (that's not a bug).

If making a working 64 bit compile requires more than some trivial find and replace, maybe helped with some short scripts, it's probably not a great use of his time. (Though Toady should do what he wants with his time, so 'Yay!' if he does it I guess.)

You don't speak for most people.

64 bit addressing mostly allows a larger embark area. As for offloading stuff from memory, Toady would have much less work making the program 64 bit then building a system for swapping things out of memory or adding a database into DF to decrease memory usage.

For some applications 64 bit can be faster, though I doubt that this would be the case for DF because it has a memory latency bottleneck.

[Two]

Meaning your program didn't crash, the JVM itself crashed.

Seen that two times so far in my life: once when we used a home-brewed version of the JVM for a very exotic embedded device, and the other time when I used some unsupported OpenGL libraries that caused the crash. I never heard of the actual, official JVM crash ever.

[draeath]

We never figured out what was going on.

Basically we have a java application that would run in a store on each cash register, that would drive the payment device. It was running standard/official Sun JRE 6, 32-bit, on Windows XP Embedded (32-bit). Once in a while, a register would flake out - and on digging, the java process had died and had been restarted. A nice little JVM stack/core would be sitting in the application's root. Generic access violation.

I directed them to test the hell out of that hardware - and no fault was ever found. It also happened sporadically around their businesses, so it wasn't even specific to a geographic region.

Quite maddening.

[Nameless Archon]

Most people here like short histories, on small, lower population worlds, with smaller embarks 'for the FPS', so that's not much of a gain.

You don't speak for most people.

64 bit addressing mostly allows a larger embark area.

All of those things (long history, large world, big embarks) are things I'd like to do. In the current iteration, however, long history is mostly pointless (all dwarven civs end up goblin-owned due to army arc not finished), the new restrictions on neighbors limit the utility of larger worlds aside from variety, and big embarks... well, I think the pathfinding across the larger space is the real culprit there, not the memory footprint, but don't quote me.

[BenLubar]

What we need to do is get Toady one of those "time turner" things Hermione had so he can implement all the things he wants as well as all the things the players want in an hour.

[Sizik]

What we need to do is get Toady one of those "time turner" things Hermione had so he can implement all the things he wants as well as all the things the players want in an hour.

That would wreak hell on whatever version control software he uses.

[ShadeJS]

I just think that Toady may want to 'eat his own dogfood' for a day before he releases.

I am pretty sure he does it all the time, also dogfood is hardly appropriate for one of the most in-depth and entertaining games on the market.

'Eating you own dogfood' ISN'T pjorative.

http://en.wikipedia.org/wiki/Eating_your_own_dog_food

The point I was trying to make wasn't that 'Toady doesn't test' (he does), but that some of his minor releases would have benefited from a longer, continuous play, playtest. I don't really think that a person can argue that too much. I also clearly stated that I'm fine with the notion that point releases will vary in quality (though the overall quality tends to get better over a major cycle).

Most people here like short histories, on small, lower population worlds, with smaller embarks 'for the FPS', so that's not much of a gain.

You don't speak for most people.

64 bit addressing mostly allows a larger embark area. As for offloading stuff from memory, Toady would have much less work making the program 64 bit then building a system for swapping things out of memory or adding a database into DF to decrease memory usage.

For some applications 64 bit can be faster, though I doubt that this would be the case for DF because it has a memory latency bottleneck.

I'm sure I don't speak for most people-- Heck I don't tend to play on small worlds with really short histories myself, but you hear the suggestion that people should consider it. I'm not suggesting some horrible database backed dynamic loading system, but if push came to shove Toady could probably be more discerning about what gets generated / loaded when, and how long it stays in memory. For the most part push really hasn't come to shove, IMHO.

That's not to say I'm anti-64-bit, I'm just mostly 'blah' about what a 64 bit build brings to the table. I'd be happy to see a 64 bit build (assuming that Toady hunting things that depend on 32bitishness isn't a big rabbit hole).

[Bloax]

I'm pretty sure most things in DF are a huge rabbit hole, but 64-bitness would be a very good rabbit hole to hunt down for future proofing the program from running into memory limits (which it already does in some cases).