Allegedly. I’ll believe it when I see it.
He held three talks about his progress (text and slides available at http://inform7.com). I doubt he pulled those out of thin air.
(Edit: also, if you check his GitHub, commits are being made regularly.)
I think it’s a question of when not if!
the next public release will certainly be in 2019
To be clear, Graham Nelson’s work is incredible, and his new version of Inform, which seems to involve a top-to-bottom rewrite despite keeping the name “Inform 7,” is clearly an enormous task. It’s just that he’s been promising to open-source Inform 7 after adding just a bit more spit and polish for well over a decade at this point, and I’ve begun to suspect that his personal standards demand a level of perfection that’s simply not possible to achieve. I certainly don’t doubt Graham’s account of how it’s in progress, but until I see it I have to wonder if it’ll be in progress forever.
(One ominous comparison: in one of the talks he refers to Inform as his “life’s work,” which is also what Tarn Adams said about Dwarf Fortress. The difference is that Adams didn’t insist on Dwarf Fortress being complete before anyone could see it.)
Indeed, it is so. So much that I think it’s wise to just bump up the number to Inform8. In my experience, such monumental rewrite will inevitably open up new doors and possibilities for unimagined possibilities, and a new numbering will allow new implementations to be seamlessly added, without fear of breaking Inform7 compatibility.
Meanwhile, please be patient. Reworking 250,000 lines program single handedly is a monumental task few people can accomplish.
What difference does it make if you believe that it’ll be in progress forever, or if you don’t?
Setting up an unofficial bug tracker is a pragmatic action. It doesn’t depend on expectations. It has value even if there’s never another I7 release – it allows people to see if the problem they’re running into is a compiler bug or not, and if so, if there’s maybe a workaround.
It’s doubtless a canonical example of the programmer’s adage: The first 95% of the coding takes 95% of the time. And so does the last 5%. The documentation- likewise.
I believe at Narrascope 2020 he said he thought it would be done before the next Narrascope. As Narrascope was canceled this year, it appears he’s technically kept his promise.
That was an answer to the question, “when will the code be posted to Github?”
It’s very reasonable to ask when I intend to post the Github repository, and the answer is obviously, when it’s finished. “Finished,” of course, is a strange word in this context, because this is a living program, it’s not a thing that’s going to reach any final state, until it’s… Well, I guess, in some sense, we all reach a final state eventually, but the idea is that it will continue to be modified once it goes up. Certainly before NarraScope 3, but, with any luck, quite a lot before. I am working on what amounts to a draft version at the moment. I think experience suggests that I probably shouldn’t give actual deadlines at this point.
I was surprised at this answer, because I thought it would make sense to post to Github well before the program was “finished.” I followed up on Discord:
Why wait on Github until the new version of Inform is “finished”? I think we’d all appreciate looking at your work as it progresses.
(Git’s log of commit messages can serve as one part of a “thick description.”)
One reason I have been reluctant to put unfinished stuff onto Github is that the traditional doctrine of literate programming involves an idea of “publication” as an act: it’s an act that forces us to write our code better, and to improve it
in presentation as well as functionality
and in effect, this has resulted in a very useful code review of the entire code base
but another reason is that there was just a lot of stuff in the code which had become horribly limiting - for example, using C strings without Unicode support
this meant that many areas needed enormous amounts of upheaval
so I’ve been working on this as an effort to bring things to what I consider a reasonable state, and then press the button
I do actually agree that git commit histories are interesting, and in due course people will be able to see mine…
…I am happy to say that they are reasonably free of curse words
For my part, I think he’s making the wrong call here. I think the code should go up on Github immediately; it would have been better to put the code up a year ago.
The idea of “publication” as an act that forces us to write our code better does seem part of the culture of literate programming, in the sense that this is what Knuth did, but I think it’s in no way essential to the ideas of literate programming, and, as Graham points out, it is a totally wrong approach for “living” software.
More to the point, until he publishes anything on Github, he can’t accept help from anyone. Is Graham Nelson the only person in the world who could convert C strings to Unicode strings? On the contrary; that’s straightforward hard work that a volunteer could do, giving him time to focus on architectural concerns.
Under the current plan, the public won’t have access to the source code for Inform until it’s “finished.” But, by his own admission, it will never be truly finished.
I will be pleasantly surprised if we see any Inform code on Github before the next NarraScope, and even more surprised if there’s a public working build of the next version of Inform by that time.
I think you have a shallow view of program development. Software architecture can be significantly varied, even on the same type of programs. People think differently, and judging by the fact that there’s only one large scale literate programming project shows his unique thinking philosophy.
In my experience, reviewing other people’s code takes more time than to just do it myself. This is especially true with projects that I initiated, simply because I know the program and its problems intimately. Putting more people into the fold will simply make a late program even later.
Then there is program coherence. If I’m rebuilding a large scale program, I would borrow large parts of old program, that will eventually discarded. So, I don’t want people to touch, read, or even acknowledge such parts.
There are many reasons to delay publishing a source code, and progress does not happen linearly. Such is a fact of life. Let’s not bother Graham until then. Offer help if you want, but don’t be upset if such offers are declined.
The other side of that coin is that people will invariably create issues stating that “[thing that is currently being reworked] is broken” or that the code doesn’t compile, no matter how often you state that “[thing that is currently being reworked] is broken at the moment”. To a degree, I can understand not wanting to deal with that. Once you publish (and have a significant userbase, which Inform has), a significant part of your time goes into community management rather than development.
(Edit – And, concerning your particular example: maybe he just feels bad about leaving the “grunt work” to other people like that.)
Let’s also not forget that writing code is fun, but when you bring more people into the fold, you spend a fair amount of time doing project management, which is not fun. I know lots of folks for whom coding is a hobby, but none who would choose to do project management recreationally.
Or maybe open-sourcing it before the stars are right would be against the exact terms of the wish he made when the genie granted him his powers.
And maybe it’s kinda weird that we as a community engage in as much speculation as to Graham Nelson’s inner states as we do.
Maybe the community which uses Inform 7 would cease to speculate on the inner state of its primary author when it is granted the permission to look at the changes he is making to the source code.
OK, help me understand this. There’s a practice called literate programming, which interleaves documentation with code. The purpose of that is to explain easily how it all works.
The Inform 7 project enthusiastically embraces this technique. But the reason that neither the code nor the literate exposition around it is available to the user community, is because to do so right now would be too confusing for everyone.
I can’t explain it because I’m not Graham. He isn’t reading this thread.
Forgive me if I should know this, but what would be the reason for the author of a piece of software not to engage with his user community when they gather so happily in a forum like intfiction.org?
As I understand it, literate programming as envisioned by Don Knuth is a way to express Pseodocode as actual program. His grew out of LaTex (actually TeX). Graham’s grew out of Inform. Both tried to express “Writing as Coding” movement that is constantly envisioned, but never successful, at least outside specific domain.
As to why Graham doesn’t engage the community, I don’t see why he should. I believe that he already has the vision necessary to progress, and any activity other than implementation is a distraction. There is enough people here to help you with any question regarding Inform, or any other concerns as well. There will be enough time for engagement once the initial reimplementation is completed.
As Zarf said, none of us here know the real reason why he doesn’t engage in this forum, but we’re not Graham, so all we can do is guess.
I think that if you really want to know, you may ask [she no longer serve as Inform liason per @dfabulich ] nicely, as I believe that she is the best person to know about it, other than Graham himself.
But I won’t ask, and I think that we should all just wait and trust and respect Graham to do his project the way he sees fit.
… and in the meantime you can play with ZIL and ZILF to your hearts content…
Sorry, couldn’t resist
Not wanting to criticise you, @ramstrong but seriously, I find this a very strange statement:
I speak as someone who has never tried Inform 7. And so I’m fully qualified to suggest to you that there will be no new users for that platform other than those tragically dragooned into the ancient religion according to academic necessity.