It doesn't appear that TADS 3 is open source, no, just closed-source freeware. I can't find any reference to either source code availability or license information.
"Open source" is widely accepted to mean "licensed under terms that meet the Open Source Initiative's Open Source Definition", instead of the obvious meaning of "source available", only because many people put a lot of effort into correcting everybody who assumed it was plain English and not jargon.
"Closed source" has not had a similar education campaign, so it still defaults to the common-sense meaning of "source not publicly available". The opposite of "open source" is "proprietary".
Awesome! Inform7 is intriguing. You can learn more about it here: http://inform7.com/
What is very unusual about it is that it creates a programming language for interactive fiction that looks very much like natural language. Its tools are very friendly for new users.
You may also be interested in Object-Process Language (part of [1]) which is a similar concept to Inform7, but without the domain specific focus of interactive fiction.
"It's nearly there: I'm only a few momths [sic] away, and the next public release will certainly be in 2019. Simultanously [sic] with the next public release, the Github repositories will all be made public."
> But only a few, since Inform has no dependencies on third-party code. You need a modern C compiler, ideally clang, but gcc will do; and you need basic Unix tools. But that's all.
> Core Inform is written in ANSI C, properly speaking C99. That was the first decision I took, in 2001, and it was the wrong choice. I had my reasons, but C++ would have been better for the heterogenous tree structures you need inside of compilers. I feel much happier about my other early decision, which was to adopt literate programming.
> Literate programming was invented by Donald Knuth in the 1970s: he was responsible for the slightly insulting name, as if all other programmers are illiterate. The idea is to write a program like an essay, with a narrative, so that its source code can be read by humans as well as computers. This is not just about commentary: it's about making long or complex functions more comprehensible.
> Literate programming is not a popular choice today. The canonical primers on software are respectful but basically tell you not to use it: "Code Complete", for example, or "The Art of Unix Programming". It failed to catch on for several reasons: most programmers do not like to write essays. Most code has a short shelf life anyway. Commentary in code is out of fashion these days, and some coders even consider it harmful.
It reads a lot like a special purpose logic programming language, almost as if it has a prolog engine built in. Expert systems generally use logic programming. I think that's what the GP means. Rules engines are something different AFAICT, (all I get on Google is business related stuff) and seem to use forward chaining, and I'm not sure how you'd get Inform-like behavior with that.
There are built-in rules for some things, like rooms. If you say "the living room is east of the dining room", then going west from the living room will move you to the dining room. There are libraries of rules for containers, ropes, water, fire, etc.
This past year I taught Python to 7th and 8th graders.
But to 6th graders I taught CLI basics and Inform7 (all on the command line).
It was one of the most successful "programming and computer basics" courses I've ever run. A fair amount of custom tooling to make it run smoothly, but a shared VPS for the students and some deploy scripts made it possible to not only make individual games but also collaborate on a larger scale game written collaboratively (each user writing their own set of rooms which was compiled automatically into a full game).
I've spent a long time messing around with Inform7, for quite a few years on and off, and then I kind of stopped after realizing a few things: 1) it's incredibly frustrating and inefficient to write games in an English like language when you're a perfectly capable programmer, 2) if I try to do any even slightly more complex programming I'll be shot in the foot, and 3) I'm terrible at writing puzzles.
I did try to solve the first two problems by trying Inform 6, but it's just not a great language and that third problem is a sticky bugger. (:
Anyway, Inform has an extremely powerful and featureful IF engine, and one that I dearly wish I could tap into using some kind of decent programming language (even ZIL!). It going open source gives me hope that that might become possible in the future.
If anyone knows of any good IF libraries for existing programming languages (especially Lisp) that would be awesome.
>I've spent a long time messing around with Inform7, for quite a few years on and off, and then I kind of stopped after realizing a few things: 1) it's incredibly frustrating and inefficient to write games in an English like language when you're a perfectly capable programmer, 2) if I try to do any even slightly more complex programming I'll be shot in the foot,
I've heard that people who get annoyed with both 1 and 2 usually use TADS instead of Inform.
IIRC Inform 7 .i7x is internally translated to Inform 6 .i6t source which is more low-level C-like language. Have a look at code pieces formatted as (- ... -) in installed Inform extensions. You can mix 6 and 7 together.
BTW I tried to feed some Inform 7 code to APE[1], which is a parser of an English subset written in Prolog, without much success as I recall.
As for existing IF tools the first come to mind are Twine and Ren'Py.
Yeah, I have actually tried I6, the problem is it's much lower level and doesn't get a lot of the power of I7. I want the power of I7 but without the COBOL-tastic syntax.
And I read Knuth's book "Literate Programming" in formative years and loved the idea.
But somehow I never connected Inform 7 as generically a live, working modern example of literate programming. That's pretty silly! The language is full of dozens of good examples of worked programs, albeit nearly all written as one kind of text in/text out/parser interaction.
One difference I maybe see is that Knuth writes a book about a program which is built in a very didactic fashion such that every single bit of source code is commented with a detailed explanation of what it does. In real life, though, most Inform games have a bunch of utility code that is not super well commented but is needed to glue things together; and the way that real large Inform games are written means that the program isn't quite as narrative as the example Knuth gives. The program certainly tells a story when interpreted, but the source code of the program itself doesn't tell a story in quite the way that I kind of read Knuth's book as promising.
About half of some of the best IF of 2018 was written in Inform 6 or 7 ( https://ifdb.tads.org/poll?id=mryx4c8bzwym7rvy ), so it's doing fairly well, even if many good authors have been tempted by other options, up to and including roll-your-own.
Separately, I have struggled to find an interpreter on latest OS X that loads all of those 2018 games reliably -- what is the community's preferred Mac interpreter now?
This is a bit random, but I have a cameo appearance in Counterfeit Monkey as my rockstar alter ego 'Nexami Engeo.' Cool to see the game being mentioned on Hacker News
The punch line is that Graham Nelson still has not open-sourced Inform 7, but hopes to do so in 2019. So, if you decide to build your work on Inform 7 and Graham gets unexpectedly run over by a tram like Gaudi, you're very likely out of luck; you won't have the legal right to fix problems in the platform, port it to new platforms (such as, as he notes, iOS), or remove whatever spyware his heirs decide to add to "monetize the platform".
So, it's nice to hear that he's making concrete steps forward, but the bottom line is that he's still not open-sourcing it, just continuing to promise to open-source it, as he has been doing for many years.
With that in mind, I think the title of the HN post is misleading; it would be more accurate to entitle it "Not Open-Sourcing Inform 7", and still better to entitle it "Not Yet Open-Sourcing Inform 7."
And that's a shame, because Inform 7 looks like one of the most interesting experiments in programming-language design today, and has been for years. Years that I haven't tried it, because downloading and installing proprietary software is not my idea of a fun pastime.
It is perfectly reasonable to be skeptical for all the reasons you've noted. However, I see two things that have changed. Most importantly, he has set of specific month and year. He is also stating a specific license, which I don't recall him doing before. Finally, he did release inform 6 as open source years ago.
So again, you have reason to be skeptical. But there are also reasons to hope.
I mean, it's obvious why it's taken so long from the slides. He has built an entire literate C project as well as a CLI test project, both entirely independent of Inform; an intermediate output format; and has worked toward an intermediate input format.
I for one am very interested in his ideas around exporting the world model to other areas, like Unity. That way you can script your world in Inform 7 and then make it available in e.g. a 3D RPG with a bridge between the two. Obviously that's years away, but it's an interesting idea.
Finally, the main concern here is that there's just so much here that has lived in the author's head for decades (18 for Inform 7 alone) that it will be daunting for new contributors to get involved.
None of that is relevant to software licensing, source code secrecy, and the entirely preventable risks they impose on users. Yes, it's possible that without Graham and the commendable efforts he is making to make the source understandable, it would be dauntingly difficult or impossible to understand well enough to make changes. But the users who would hypothetically be up a creek in that situation are even worse off now: they don't have the source code at all, and if they did, they'd be at legal risk if they tried to use it, due to the toxic and corrupt copyright system.
Basically from my point of view he's asking other people to put themselves at risk of having their creative work destroyed, in order to avoid risks to his ego.
"Creative work destroyed" is scaremongering.
All the old versions of Inform are available, so people who have already written games can build and release a new version of their game just like they always could.
It will be great to see an open source version and maybe this will result in improvements that attract new authors, but in practice, Inform 7 being a closed-source tool has not been any trouble for existing game authors and the risk is no greater than before.
It is extremely well founded scaremongering. Almost every creative work in a format only accessible via proprietary software becomes unreadable in fifty years or less, an eyeblink in human intellectual history. That risk has always been the same. The few exceptions are things built on proprietary software that was so popular that open-source clones exist — a relevant example in this case being the Z-machine.
Creative work built on proprietary software is like a sand castle below the high-tide line, except that the tide won't try to monetize your castle by bundling malware into it.
That assumes that the only relevant article in the long term is the executable code. But I don't think that's true at all. The Lyons book on Unix, and several books about the Linux kernel, have shown that the source code also matters. If you can't correctly interpret the source code, the source code is far less useful. So if source code is also important (and it is), then having a publicly-known way to process the source is also important.
Thank you for saying this, David. I wanted to say it but I had already lost patience with the discussion. BTW, speaking of the source-code archival problem and also your work on the Karger–Thompson attack, have you been following the work on Mescc?
I've been semi-following the bootstrappable builds stuff in general - that work is already listed on my page https://dwheeler.com/trusting-trust
Mescc is obviously an example. Years ago Bellard demonstrated a bootstrap using tcc to compile the Linux kernel (which was pretty amazing).
I think the approaches could work together well. Bootstrappable builds reduce the size of the binary you have to trust, and DDC can act as a check on a binary.
Have you ever open sourced a large, complex, closed-source project of a similar scale, developed by one or two people?
I built a project with a friend that was half the size of this one and less complex. At one point we had to decide whether to open source it or shut down the project entirely. The amount of work to get it to the point of open sourcing it so that anyone could meaningfully contribute to it (or even build it without a very specific setup) was daunting, and I simply didn't have the time or energy to go through with it.
The fact that he's spent years getting it ready is a testament to his dedication to the community.
Finally, you have no way of knowing what his contingency plan is. He may have passwords and instructions detailed to transfer control to someone else in the event of his death.
The fact that your build setup was poorly documented provided you with no incentive to use the legal monopolies granted by copyright law against your users. I agree that it's important to go beyond the mere legal grant of rights to study, copy, modify, and redistribute software, for example by simplifying and documenting your build system. But not having done that, or not yet having done that, is no excuse for not having done the more basic step of simply granting them the legal rights that the law ought to grant them in the first place, but doesn't; nor for keeping secret the source code to the software your users were depending on, preventing them from modifying it even if they were capable of figuring out how to compile it.
And it's true, I have no idea what his contingency plan is. But you are suggesting some kind of secret Rube-Goldberg-style legal setup as a substitute for the simple and straightforward publication of source and promulgation of a license like the Artistic License he plans to use. That would also be much safer, legally, since there's no room for heirs, debtors, or lawyers contesting a will, auctioning off the copyright to the software in order to pay debts or legal fees, etc. A much more likely case is that he simply doesn't have any plans for that situation because he isn't worried about it, and you've been reading too many silly novels.
Oh wow...I've never gotten around to playing with Inform7, but always meant to and have played a lot of games written in it. Emily Short is a big favorite of mine.
Funny thing is I always assumed it was already open source.
Relevant quote from the previous talk from last year:
"(4) The unreleased tools needed to build and test Inform were far worse, some being huge Perl scripts which were just mazes of twisty little passages. They were nowhere close to being releaseable in quality. One reason Inform hasn’t been open source in some years is that this infrastructure was such a mess. But not being open source is an existential threat right there."
Indeed. Nobody cares how awful the tools are - something that exists, is open source, and can be improved is infinitely better than that which doesn't exist and has to be reverse engineered.
As a fan of interactive fiction (I used to run a podcast about it) and a programmer, I've always hated Inform 7. The design philosophy is totally upside down. I understand the apparent value of making code _look like_ english, but in the end it makes code very hard to write.
Its like literally the only read only programming language I know of.
Code which looks like english makes the implicit suggestion that you can program it in english, but in fact, like all languages, it only accepts a very narrow syntax. This makes the language exceedingly frustrating to use.
I've got to elaborate: programming languages are for telling dumb machines _exactly_ what to do. English is for communicating with other intelligent beings, usually in a more or less interactive way. The two use cases could not possibly be more distinct. One way to see this is to observe how much redundancy and ambiguity is built into natural languages. Redundancy is there because natural communication is lossy and ambiguity is there because communicating agents share an enormous amount of common context. Programming languages have tended towards less and less redundancy and more or and more precision over their history.
Its more or less a coincidence induced by sloppy human thinking that we are "communicating" with computers when we program. Honestly, I'd almost rather program in assembly than in any of these absurd "natural" languages.
Although I broadly agree that other programming languages probably shouldn't follow Inform 7's example, I think Inform 7's similarity to English can be fun to play around with [1], so I'm glad it exists.
Perhaps after it's open sourced, someone will look into grammar improvements?
54 comments
[ 4.1 ms ] story [ 114 ms ] threadCurious: Is TADS3 open source?
Nice to see literate programming used in the project.
https://github.com/realnc/frobtads/blob/master/tads3/LICENSE...
"Closed source" has not had a similar education campaign, so it still defaults to the common-sense meaning of "source not publicly available". The opposite of "open source" is "proprietary".
What is very unusual about it is that it creates a programming language for interactive fiction that looks very much like natural language. Its tools are very friendly for new users.
If you're curious about what the language looks like, you could look at my tiny game Accuse https://dwheeler.com/accuse/ and in particular read its source code: https://dwheeler.com/accuse/source.html
[1] https://en.wikipedia.org/wiki/Object_Process_Methodology
> Core Inform is written in ANSI C, properly speaking C99. That was the first decision I took, in 2001, and it was the wrong choice. I had my reasons, but C++ would have been better for the heterogenous tree structures you need inside of compilers. I feel much happier about my other early decision, which was to adopt literate programming.
> Literate programming was invented by Donald Knuth in the 1970s: he was responsible for the slightly insulting name, as if all other programmers are illiterate. The idea is to write a program like an essay, with a narrative, so that its source code can be read by humans as well as computers. This is not just about commentary: it's about making long or complex functions more comprehensible.
> Literate programming is not a popular choice today. The canonical primers on software are respectful but basically tell you not to use it: "Code Complete", for example, or "The Art of Unix Programming". It failed to catch on for several reasons: most programmers do not like to write essays. Most code has a short shelf life anyway. Commentary in code is out of fashion these days, and some coders even consider it harmful.
It is a very different domain specific language. I recommend looking at this to see a programmer's view:
http://www.ifwiki.org/index.php/Inform_7_for_Programmers/Par...
But to 6th graders I taught CLI basics and Inform7 (all on the command line).
It was one of the most successful "programming and computer basics" courses I've ever run. A fair amount of custom tooling to make it run smoothly, but a shared VPS for the students and some deploy scripts made it possible to not only make individual games but also collaborate on a larger scale game written collaboratively (each user writing their own set of rooms which was compiled automatically into a full game).
I did try to solve the first two problems by trying Inform 6, but it's just not a great language and that third problem is a sticky bugger. (:
Anyway, Inform has an extremely powerful and featureful IF engine, and one that I dearly wish I could tap into using some kind of decent programming language (even ZIL!). It going open source gives me hope that that might become possible in the future.
If anyone knows of any good IF libraries for existing programming languages (especially Lisp) that would be awesome.
I've heard that people who get annoyed with both 1 and 2 usually use TADS instead of Inform.
BTW I tried to feed some Inform 7 code to APE[1], which is a parser of an English subset written in Prolog, without much success as I recall.
As for existing IF tools the first come to mind are Twine and Ren'Py.
[1] https://github.com/Attempto/APE
I've read plenty of Inform 7 source code (see e.g. https://github.com/i7/counterfeit-monkey/blob/master/Counter... ).
And I read Knuth's book "Literate Programming" in formative years and loved the idea.
But somehow I never connected Inform 7 as generically a live, working modern example of literate programming. That's pretty silly! The language is full of dozens of good examples of worked programs, albeit nearly all written as one kind of text in/text out/parser interaction.
One difference I maybe see is that Knuth writes a book about a program which is built in a very didactic fashion such that every single bit of source code is commented with a detailed explanation of what it does. In real life, though, most Inform games have a bunch of utility code that is not super well commented but is needed to glue things together; and the way that real large Inform games are written means that the program isn't quite as narrative as the example Knuth gives. The program certainly tells a story when interpreted, but the source code of the program itself doesn't tell a story in quite the way that I kind of read Knuth's book as promising.
About half of some of the best IF of 2018 was written in Inform 6 or 7 ( https://ifdb.tads.org/poll?id=mryx4c8bzwym7rvy ), so it's doing fairly well, even if many good authors have been tempted by other options, up to and including roll-your-own.
Separately, I have struggled to find an interpreter on latest OS X that loads all of those 2018 games reliably -- what is the community's preferred Mac interpreter now?
So, it's nice to hear that he's making concrete steps forward, but the bottom line is that he's still not open-sourcing it, just continuing to promise to open-source it, as he has been doing for many years.
With that in mind, I think the title of the HN post is misleading; it would be more accurate to entitle it "Not Open-Sourcing Inform 7", and still better to entitle it "Not Yet Open-Sourcing Inform 7."
And that's a shame, because Inform 7 looks like one of the most interesting experiments in programming-language design today, and has been for years. Years that I haven't tried it, because downloading and installing proprietary software is not my idea of a fun pastime.
So again, you have reason to be skeptical. But there are also reasons to hope.
I for one am very interested in his ideas around exporting the world model to other areas, like Unity. That way you can script your world in Inform 7 and then make it available in e.g. a 3D RPG with a bridge between the two. Obviously that's years away, but it's an interesting idea.
Finally, the main concern here is that there's just so much here that has lived in the author's head for decades (18 for Inform 7 alone) that it will be daunting for new contributors to get involved.
Basically from my point of view he's asking other people to put themselves at risk of having their creative work destroyed, in order to avoid risks to his ego.
It will be great to see an open source version and maybe this will result in improvements that attract new authors, but in practice, Inform 7 being a closed-source tool has not been any trouble for existing game authors and the risk is no greater than before.
Creative work built on proprietary software is like a sand castle below the high-tide line, except that the tide won't try to monetize your castle by bundling malware into it.
This just isn't a problem. Open source emulators are available. You don't need Inform 7 to run old games from ifarchive.org.
(Often, authors release their games without source, so having Inform 7 wouldn't do you any good anyway.)
I think the approaches could work together well. Bootstrappable builds reduce the size of the binary you have to trust, and DDC can act as a check on a binary.
Thanks for asking!
I built a project with a friend that was half the size of this one and less complex. At one point we had to decide whether to open source it or shut down the project entirely. The amount of work to get it to the point of open sourcing it so that anyone could meaningfully contribute to it (or even build it without a very specific setup) was daunting, and I simply didn't have the time or energy to go through with it.
The fact that he's spent years getting it ready is a testament to his dedication to the community.
Finally, you have no way of knowing what his contingency plan is. He may have passwords and instructions detailed to transfer control to someone else in the event of his death.
The fact that your build setup was poorly documented provided you with no incentive to use the legal monopolies granted by copyright law against your users. I agree that it's important to go beyond the mere legal grant of rights to study, copy, modify, and redistribute software, for example by simplifying and documenting your build system. But not having done that, or not yet having done that, is no excuse for not having done the more basic step of simply granting them the legal rights that the law ought to grant them in the first place, but doesn't; nor for keeping secret the source code to the software your users were depending on, preventing them from modifying it even if they were capable of figuring out how to compile it.
And it's true, I have no idea what his contingency plan is. But you are suggesting some kind of secret Rube-Goldberg-style legal setup as a substitute for the simple and straightforward publication of source and promulgation of a license like the Artistic License he plans to use. That would also be much safer, legally, since there's no room for heirs, debtors, or lawyers contesting a will, auctioning off the copyright to the software in order to pay debts or legal fees, etc. A much more likely case is that he simply doesn't have any plans for that situation because he isn't worried about it, and you've been reading too many silly novels.
Funny thing is I always assumed it was already open source.
"(4) The unreleased tools needed to build and test Inform were far worse, some being huge Perl scripts which were just mazes of twisty little passages. They were nowhere close to being releaseable in quality. One reason Inform hasn’t been open source in some years is that this infrastructure was such a mess. But not being open source is an existential threat right there."
Its like literally the only read only programming language I know of.
Code which looks like english makes the implicit suggestion that you can program it in english, but in fact, like all languages, it only accepts a very narrow syntax. This makes the language exceedingly frustrating to use.
Its more or less a coincidence induced by sloppy human thinking that we are "communicating" with computers when we program. Honestly, I'd almost rather program in assembly than in any of these absurd "natural" languages.
Perhaps after it's open sourced, someone will look into grammar improvements?
[1] http://slesinsky.org/brian/code/i7_poetry.html