I’m reading all about Linus Åkesson’s “Dialog” IF programming language with his excellent Javascript/CSS based “Å-machine.”
I’m impressed.
TADS3, on the other hand, is a mature language with all kinds of authorship hooks right out of the box.
I just wish we could meld Dialog’s outstanding design with TADS3’s maturity. I guess, bluntly, what I wish for is the functionality of both with the ability to call routines with object passing with a web-based interpreter target (like Å-machine).
I know some have tried to contact Michael in the past to no avail. Still, I marvel at Michael’s work.
I sympathize with the wish that TADS were open source in general terms: though of course it is always the author’s decision, one consequence of deciding to keep something personal to you is that if you lose the interest in developing it, it doesn’t get developed.
I have to say, OTOH, that the idea of combining Dialog and TADS seems totally bizarre to me: I can’t easily imagine two languages with more different ideas of how a program should be constructed on more or less every level, so I think you’d be constructing a sort of mashup between Latin and Chinese. But … to each their own.
I remain resolutely sceptical about whether lack of suitable languages is a problem for IF. It seems to me that we have a copious supply of languages and tools to suit more or less any preferred style of coding whether for parser-based (Inform6, Inform7, TADS, Dialog, INSTEAD, ADRIFT, ZIL) or choice-based (Twine, Ink, Elm …) and targeting either story+interpreter, web-based, or standalone “app” models (the last of those, for obvious reasons, only with considerable effort in most cases: but that’s inevitable). Most of them are proven (in the “proof of the pudding” sense) to be amply capable of producing work with a high degree of polish in the hands of someone who has put in the time to learn to use them and the time to learn the craft. All of them are equally capable of producing clichéd mediocrity. It’s really not the tools, but the way they are used, that counts.
My hunch is that the biggest problem for TADS is that it backed the wrong horse in the race to web-deployment, and that its second biggest problem is that its API is just too heavyweight, and that its third biggest problem is that it is heavily tied to Windows, and that its final problem is that it now gives the appearance of being more-or-less neglected by its original author. Open sourcing might help with the last of those problems. The rest are solvable, but only by someone who is willing to put in a lot of time.
I’m confused. The source code for TADS 2 & 3 is available to download from the TADS site. Are you saying that there are restrictions on how that can be used?
Actually, no it’s not open source*. Check the licence. It permits porting but explicitly prohibits modification.
This source code is distributed for the specific purpose of porting
TADS, so that you can run the software on any system of your choosing.
All other derivative works are prohibited without the written
permission of the author. I want to avoid the creation of variations
on the system, because it leads to confusion on the part of users if
there are multiple incompatible flavors floating around. However, if
you have a specific idea in mind, I’d be happy to at least consider
it. Please contact the author if you have any questions about this or
if you would like permission to create a derived work.
I’m not sure one can assume the Gargoyle TADS sourcecode is GPL’d. Gargoyle is, but the TADS folder has a LICENSE.TXT of its own, and it contains the restriction set up above. So at best the position is ambiguous, and I’d be inclined to think that the restrictive license applies.
cstevens: I enjoy working with the Raspberry Pi. So far, I have been unable to find a way to make TADS3 compile source on the RPi. Do you have any suggestions on a way to make it work?
Hard to say; does it compile on your Linux box? I recall needing ‘automake’ tools for compiling–you need to run ‘autogen.sh’ to start. From there it’s about compiling the dependancies as necessary. Rinse and repeat for each library.
I haven’t my main workstation now or I’d paste my compiling docs. Keep at it and publish your docs when you’ve finished for others.
Also, check out Generator-TADS, (tutorial in GPS article) super handy for creating new TADS3 projects.
I know, however, that it does compile against the latest gcc.
The RPi uses a modified version of Debian based on an ARM risk based processor. I have been trying to make it work for some time. I will try again with your ideas and report back.
v/r
Jeff
PS. Frobtabs has not been ported to Raspbian. It would be very nice.
As I understand it, Gargoyle and QTads are both interpreters, so they would only need to use the source code of the TADS interpreter, not that for the compiler, Workbench development environment, the libraries, or other tools.
In other words, it’s quite possible that the majority of the TADS source code still has a restricted licence.
That is correct, but most of the TADS 3 compiler is also part of the interpreter (a TADS 3 game can compile and run TADS code at runtime.) In QTads, only the required parts of the compiler are shipped, but Gargoyle ships everything from what I can tell.
Yes, the Workbench is not available under the GPL. The libraries on the other hand are shipped as part of your game. The lack of a license on them seems to be an oversight, because the license you use for the games you create is completely up to you.
Anyway, the TADS VM and compiler being effectively available under the GPL doesn’t mean someone can just start developing it on their own. Including the HTML TADS layer, it’s a ~350.000 lines of code (without comments) project. In comparison, Inform 6 is 30.000 loc, and the reference glulx VM is 11.000 loc.
MR knows the code base in and out but I’m not sure anyone else does. It’s probably not something one can start seriously working on on their free time.
