Aaaaaaah.
In that case I completely agree. I was also curious and interested in the discussion that never actually came. Probably Jim found that the replies he got meant he’d be hijacking a thread and swimming against the current and thought his attention would best be served elsewhere?.. I’m only speculating, though.
I’ll PM him. He may not wish to argue this point much further over there, but maybe he’ll want to continue the discussion in a different environment. I.e., here.
I do covet the jump arrows (links that highlight the source that an error refers to) that have been missing in Mac IDE for a couple of versions…
The braces in section headers doesn’t seem like a thing they would mean to deprecate, so I wonder if there is a bit of misunderstanding. Zarf was awfully curt with me about automatic section numbering recently, so maybe that group is touchy about something for some reason.
Similarly with the Scroll Thief bugs. It’s hard to see how a built-in action causing a run-time problem if invoked exactly as described in the manual is a “feature”. And the braces in section headers are also a feature described in the manual and used in the built-in extensions…
Thanks! <post must be at least 20 characters> </post must be at least 20 characters>
The main reason I didn’t pursue the topic further on the forum was that I didn’t feel it would be useful. For one thing, I’m not a software engineer, so I’m only vaguely aware of the issues that might arise in attempting to maintain backward compatibility. For another, it doesn’t matter what I say, because Graham Nelson (a) never reads the forum, AFAIK, and (b) has always done things his own way. The fact that Graham teaches at Oxford suggests that the term “ivory tower” may not be entirely inappropriate – but on the other hand, Eric Eve also teaches at Oxford, and his work on TADS 3 has never been handed down from an ivory tower!
Personalities aside, the reason I mentioned backward compatibility at all is that I feel Graham is doing his users a disservice. Back in the late '80s/early '90s, when I was reviewing synthesizers for Keyboard, my sarcastic line that I thought ought to be Yamaha’s corporate slogan was, “We’re Yamaha. We don’t have to do it right.” Their success with the DX7 was so phenomenal that they seem to have figured they could enjoy the same success no matter what design choices they made. In a similar way, Graham’s success with I7 seems to have led to a situation where he feels it’s okay to do things his own way, that people may grumble a bit but will in the end follow along like little ducklings, because hey, it’s Inform 7! It’s fantastic!
In many respects it is fantastic. But this is one of the perils of success.
That said, we need to remember that the development team for I7 is small and unpaid. That makes it very hard for them to make sweeping changes in a code base and then test them properly before release. And sweeping changes would probably be necessary to create backward compatibility at this late date. (My computer wants to restart. I’m going to launch this message and then continue the discussion later.)
(Oh, BTW, “midiguru” is Jim Aikin. Dang these computer monikers, anyhow!)
One of the design decisions Graham made that is apparent on the surface was to encourage the development of third-party extensions. This had been part of the I6 community for some years, and it’s a fine idea in many ways. It allows people to implement specialized features, and also encourages people to have “buy-in” with the system. But if you have a small development team, don’t attempt to make new releases backward-compatible, and encourage third-party extensions, the inevitable result is that when a new version is released, many or most of the extensions break!
This was foreseeable. Apparently it was not foreseen.
Even in the absence of extensions, author code breaks when there’s no backward compatibility. But the author is sitting right there in front of the computer, and can make the necessary changes in his or her project, based on an intimate knowledge of exactly what the project code does, or is supposed to do. An extension author, on the other hand, may no longer be involved in IF at all, and may have used programming concepts that are difficult for the author to untangle.
I have no solutions to offer. There may not be any solution (other than to switch to TADS 3 with the adv3Lite library, which is certainly worth suggesting). I can suggest ideas for how to produce backward compatibility at the author level – syntax such as “Section 3: The Jail Cell (compile using 6L02)”. If individual sections could be compiled using different compilers, a good deal of the problem would be smoothed over. But – and this is a big but: Not being a software engineer, I have no idea at all how difficult it would be to refactor the compilation process so as to allow that to happen. It might be impossible, and I’m pretty sure it would be a huge job.
Nobody here has said anything that entirely rings like the “Graham owes us!” sentiments of the old raif newsgroup, but I still think it’s worth pointing out that the mindset of the IF community has long been “if you don’t like how something is done (or the lack of something), go do it yourself” and there’s just no way of projecting how you would like things to be handled on the people in charge.
This doesn’t bother me for a couple of reasons. One, yeah, it’s a hobbyist medium and it’s unfair to ask anyone to do anything other than pursuing their own ideal of the form, and two, there are so many sandboxes to play in and help improve. I know lots of people are scared by more code-y IF languages, but several of them offer authors more control over even smaller things. Even limitations can be an asset to authors as it makes them think more creatively.
As far as this particular issue is concerned, I’m not exactly familiar with how the Inform 7 extension system is set-up (besides knowing that they made them a lot easier to install and use), if extensions don’t come with sample games already, maybe they should. While the I7 maintainers can’t be expected to test them all, it at least makes it easier to have some foresight into what will break on new releases so authors can be properly warned (but of course, this is even harder to catch for problems that won’t show up until runtime).
When there is an error, if you click the “console” tab - in the top right corner of the right-hand panel - you can view the compiler output which will list each problem report with its line number.
That’s a requirement for a new extension to be officially featured. But one problem I have heard of is, it’s tough to get your new extension in, and the feedback for why it isn’t ready yet is sporadic.
That said I agree that Graham doesn’t owe us anything. I’m glad to be able to do what I have with I7, and if I need to write a workaround to do something weird, or there’s some architectural think I don’t understand, well, no biggie.
I’m glad what’s fixed is fixed, and I have to admit a small bit of pride for being able to submit a few trivial bugs and see Graham say, yeah, let’s fix them. I know how hard it is to fix relatively trivial stuff in my own work.
Late reply, I know:
I actually got an extension in the Public Library with almost no trouble. I did get it sent back about four times with requests for specific things (labeling default messages, making sure to have test commands in the demonstration code) but It was a surprisingly easy process on my end, at least.
Hmm. I may give it a shot, then. The thing is, my favorite extension is a personal one that is probably eclipsed in general by Aaron Reed’s Small Kindnesses. Maybe I’m overthinking things.