Forum polls here don’t let users submit additional options, so I was thinking of waiting to see if there are any other suggestions before making a second poll.
The name of the repo and the names of the executables aren’t as important as the name of the project itself. If we were only talking about fixing some bugs, then simply making a maintenance release without formalising it as a distinct fork would be fine (like we do with the Hugo and TADS interpreters.) But the things being discussed here arguably go against Linus’ whole intent and philosophy of the language, such as allowing full 32 bit maths, or adding an “assembly” mode to directly output Z-Machine/Glulx instructions. So forking with a distinct name would be appropriate. Then when people ask about things we could say “you can’t do that with the original Dialog, but you can with Dialogos”.
If Linus ever became active again and liked the changes that had been made since, it would be possible for the fork to be merged back in. But that would be his decision.
The name “Dialog” is snappy but runs the risk of being misleading - when I first encountered it I thought it was the name of an Inform extension for handling NPC dialogue, then a new system aimed at supporting dialogue-heavy games. Sticking with a Dialog-derived name leverages the existing name recognition (of which there is currently some, at least) but runs the risk of perpetuating the same misconception.
DialogOS is also the name of an existing software project although the potential for confusion doesn’t seem that strong.
I figure it’s appropriate to start with brainstorming, so tossing out a bunch of things without a lot of self-filtering is a good thing 'cause one idea might inspire a better suggestion from someone else.
We could do a google form later instead of a forum poll (and I can set it up, I’m not volunteering someone else).
Looks like I’m in the minority vote, but I’ll hope you’ll all indulge me for a moment all the same…
I agree with this framing, and would add:
The “hard fork” path for this project is vastly more work, and it’s not clear to me that this work is actually very likely to materialize. So far @Draconis seems to be the only one who has tried to add even a small feature, and it seems like a bit of a slog; I’ve spent enough time poking around the code to convince myself that I’d be able to contribute minor fixes at best. It’s not clear to me that there’s a ton of folks here chomping at the bit to make sweeping changes to a minimally documented C codebase.
If it’s true that we’re doing mostly bugfixes and small improvements in the spirit of the existing code, I think it’s probably best to keep the name.
It’s easier to start with a maintenance fork and change our minds later than to do the opposite.
So for this reason I’d be tempted to set up a org with a generic name – Friends of Dialog? – import the existing codebase with the existing name, and start filing issues. If that’s all we get, I think it’s a pretty valuable contribution. And if I’m wrong and there’s a ton of motivated committers, that’s cool too!
i have no expertise in this and have a dumb question that almost certainly oversimplifies the issue:
since it’s generally easier to write code rather than read code (esp if the code is knotty) what about simply writing an entirely new compiler that can output to glulx, zcode, whatever?
i know writing a compiler is a massive undertaking but linus wrote the first one single-handedly. aren’t there tools that can help some with this (LLVM?).
I know basically nothing about Dialog’s implementation, so take this with a grain of salt. Generally, writing some compiler isn’t intrinsically hard (of course one gets better at it with practice). However, re-implementing an existing language with all its quirks generally requires a pretty deep understanding of how the language works. This is different from knowing how to write programs in the language, especially when the output of the compiler is far more low level than the input (as in Dialog), so documentation aimed at users of the language isn’t sufficient. So you often wind up having to reverse engineer the existing compiler’s behavior, either experimentally or by its reading source code. This can still be easier than to keep building on the existing code base sometimes, but it’s not as simple as defining the language and implementing the compiler in tandem.
That’s quite the undertaking; I wouldn’t even want to think about doing so unless there were significant tests that could be carried over to the new implementation (I don’t think these exist); any subtle change in how dialogc works could easily break existing project or even the standard library.
Software is hard because of all the unforseen consequences of your endless, tiny decisions.
And Linus is brilliant, but didn’t build this software with the intention of others’ carrying the work forward (no sign of any tests; virtually no documentation of the code or the design).
again, excuse my ignorance, this is largely for my own edification - but languages get new compilers all the time. there are hundreds of C compilers out there and, presumably, the writers didn’t have access to the original PDP-7 assembly code.
granted, dialog is an order (orders?) of magnitude more complicated than C, but if you already know a language’s syntax, data types, etc., what makes it so much more daunting (apart from the time necessary) to write a compiler based solely on that syntax? if linus’ compiler is a mysterious ‘black box’ what’s so hard about simply replicating the behavior with another ‘black box’?
I’m a Category D no-help-at-all type here, but if any fork isn’t called Diabolic what’s even the point?
(It even sets up subjokes, like what a phat compiler the new diabolicc will be)
[Sadly ColdFusion is already taken or I would have suggested naming it after the thing which is obviously distracting Linus from more trivial concerns like this one]
The thing with C is that it has a language specification defining all the edge cases and everything. Dialog doesn’t—the specification is the reference implementation.
. Can I suggest only up to 3 name suggestions each?