Is ADV3Lite Even Needed?

None of this is to detract from Eric’s work on this and I’ll be the first to admit TADS development discussions are not something I’m privy to. But I read this: … -intro.htm

That’s kind of a “wall of text” for an elevator speech of why I, as a new author or TADS-intimidated author, should use ADV3Lite. But what I pull out of that is this (direct quotes):

“The adv3Lite library is intended as a simpler alternative to the adv3 Library for use with TADS 3.”
“The resulting adv3Lite library has thus ended up being a lot more than barely minimalistic.”
“While it removes many of the complexities of the adv3 library it also adds a number of features.”
“The adv3Lite library should be reasonably similar to, but not slavishly identical or compatible with the adv3 library.”

So … ADV3Lite is a less complex but more than barely minimalistic library that removes complexities but adds features making it reasonably similar but not slavishly identical to ADV3.

All of this, of course, presumes that a “lite” library is even needed. The assumption seems to be that the existing library is simply too complicated. So rather than make an overlay or abstraction layer on top of that to smooth out complexities, we’ll just invent another library. A DSL approach seems like it would have made a lot of sense here.

Then I get to this: … odules.htm

I read: “The adv3Lite library has been designed to be as modular as possible, so that if there are features of library you don’t need for a particular game you can easily exclude them from the build (on how to do this, consult the System Manual).”

So I may even want stuff taken out of my “lite” library – making it even lighter? And to figure out how to do that, I have to consult the system manual? This seems like exactly the type of complexity that someone is saying they might want to avoid! (I realize the default with ADV3Lite is to include everything; but the above is mentioned early on and that means reader will have to parse it and thus decide if it matters to them.) If removing complexity can be handled by modular removal like this, can’t that be done with ADV3 making it less complicated? (As an author, I would certainly be asking that.)

None of this handles what I think is one of the more “complex” issues for a new person not used to programming environments: the fact that setting up a project is a lot more cumbersome in TADS 3 than it is in Inform 7. As a simple example, the #charset = “us-ascii” is still mentioned. However, from what I understand, a single line in the build file like this:


can mean that you don’t have to include that line in all of your source files. (It seems to work for me, anyway.) If that’s the case, why not drop what is clearly a confusing line to many into the build file, having that handled automatically? Even if not confusing, the line is noise. And one thing Inform 7 succeeds admirably at is removing the implementation noise. If we wanted to make TADS even simpler from a source-cognitive-friction level, could the #include “advlite.h” be dropped? What if the build file could contain something like:

use_library = adv3lite


use_library = adv3

Then, when these are read as part of the build file, every source file would automatically have the appropriate include directives put in place during compile time. The point here is that rather than adding libraries, you can sometimes reduce what looks like unfriendly code to people not used to programming languages. Again, something Inform 7 does fairly well.

Granted, these aren’t the best examples. I’m just trying to look at it from a different angle. The reason they are not the best examples is because I don’t know the exact problem that is being solved. (“A less complex thing” is not a solution statement and saying “ADV3 is too complicated” is not an adequate problem statement by itself.) What I haven’t seen is what people feel makes ADV3 so complicated? The fact that it’s a large library? Okay, but ADV3Lite is sort of getting there as well. And if it’s a large library – so what? There are mechanisms to search it. Are we saying those need to be improved? Or, again, would an abstraction layer help?

I’m just not getting why this alternative ADV3Lite was the most effective solution. Maybe because the actual problem it is solving is elusive to me.

If I can say this without denigrating Eric’s recent work, which in any case I haven’t looked at, I think these are good questions. He will have to address them, and I’m sure he will. He usually has pretty clear ideas about what he’s doing, and why.

I’ll add only that when I read his comment (somewhere or other) about needing to add more control over how an item is mentioned after it’s added to scope by the player looking under something, my reaction was, “But that’s what adv3 does already.” This, I think, underscores your point.

I’m not convinced, however, that setting up a project in T3 is more complex than doing so in I7 – at least, not if you’re using Workbench. Just click the button and it creates a starter game file with all of the necessities in place. The only thing you have to do that’s at all old-fashioned is copy a two-line header to any subsidiary source code files that you create. That hardly strikes me as burdensome.

What I personally would like to see (and I think this is an idea that has come up at least once before) would be an expanded macro system for T3 that would allow the author to come a little closer to writing a game using syntax that would be somewhat more similar to I7’s. There are already LOTS of macros and templates in place that go part of the way, but I do think a “natural language-ish” template system would be welcomed by a few authors who are currently intimidated by T3.

Of course, that’s a whole process of development, and I’m not volunteering to do it…

Even more important, I think, would be to make Workbench genuinely cross-platform. That would increase the pool of possible authors rather significantly.

Your problem is that you’re confusing TADS with adv3. Everything you mentioned is part of TADS, not part of adv3 or lite. adv3’s learning curve isn’t considered difficult due to #includes or character sets. That’s part of TADS, not adv3.

Instead, think sense passing, object disambiguation and in general the classes/interfaces/APIs provided by adv3.

Try to understand it as this: It is less complex, because it strips down some of the most complicated parts of Adv3, which are rarely needed. But it’s more than barely minimalistic library, so you will be able to write a nice game using it. It’s not just a learnware. It adds some new modern features, which are simple enough to understand and are very handy in actual game development. Everywhere possible the lite library is designed with full adv3 in mind, so it will serve as a step to smooth-out the infamous learning curve to the full Adv3.

That does not work that way. Any kind of abstraction layer could on first sight look more simple, but it actually only adds a more complexities (and thus errors) to the code. As one of my friends like to say: “An abstraction layer is a really great solution for many software development problems. There is just a little catch - it’s not a solution for a problem of too many layers of abstraction” :slight_smile:

That is more a “good software development practice” than anything which would concern you.

I’ve translated TADS 3 into Czech language and I must say that ability to compile project consisting of source files written each in different encoding is a crucial feature for my project.

Few weeks back I was trying to do something in my project (trying to find the right spot, when commands are parsed and evaluated into game objects, but just not too far so original phrasings are thrown away). As I do most of my development on Linux without workbench, this time I’ve booted my win xp on notebook and stepped through the code with debugger. It taken quite a bunch of hours, bookmarks and remarks to finally build the mental map and reach the solution. There are many stages on the way - the point where messages are generated is not the same, where message parameters are substituted and is not the same where the messages are printed into output.

Now understand, that I am a professional programmer and I’m used to deal with complex code. And even Adv3 is exceptionally well documented, it takes me a good deal of time to finally learn all the ways through the code. So I understand, that authors which are not programmers in the first place could have a tough time, when they step with the debugger into the deep corners of library. And as I’ve followed Eric’s work on Adv3 lite it seems to me, that he is on the right way and I wish to thank him for his effort, although I’m not the target audience.

I think you’re referring to a post on my blog where I’m (a) responding to a problem identified by a user of version 0.1 of adv3Lite and (b) discussing how I proposed to tackle it in version 0.2 (I was in part obliged to discuss it there since, as I mentioned in that blog post, the mail server would not accept the email address of the person who called my attention to the problem). Also, as a matter of fact, it’s what not adv3 does already, since the discussion is of a mechanism (designed to simplify things) that doesn’t exist in quite that form in adv3 (although the user in question had called attention to an unintended side-effect which made things less simplified than I’d hoped).

To expand on this just a little (though tomasb has largely made the point for me already), the perceived complexity of the adv3 library has been a recurring complaint against TADS 3 ever since it appeared. Of course, not everyone complains of this; there are plenty of TADS 3 authors (I among them) who have been perfectly happy to get to grips with and use the adv3 library in all its rich complexity (and adv3Lite isn’t really aimed at them). But there do seem to be a very sizeable number of people who (to quote just one from memory) are “put off by its alienating complexity.” I suspect this refers (a) to the sizeable class hierarchy within adv3; (b) the complexity and sophistication of its world model, which is more than many IF games need and © the difficulty of customizing certain responses where the adv3 library both tries to be to helpful with its defaults and takes a seemingly huge number of method calls from one object to another in the course of doing so (consider, for example, banishing an unwanted “it’s closed” at the end of a description of a door or container). It’s these issues that adv3Lite is trying to address without ending up with something so minimalistic that you couldn’t write a worthwhile game in it.

I would add that Mike Roberts suggested the need for a less complex alternative to adv3 some time ago, and started working on one he called “Mercury”. A few months back Mike said he’d made a start on Mercury but didn’t really have the time to do much more. As well as calling for possible collaborators to finish off the Mercury project, he released what he had done in case anyone else wanted to build on it for their own project. This was the spur that got me going on adv3Lite (which is built on Mike’s Mercury code).

I’d prefer to phrase that a bit more pragmatically as “is there a market for a ‘lite’ library?” The other reason for releasing the public beta at this point is to gauge the answer to that question. I suppose I could have simply started a thread here on “Does anyone think an adv3Lite library might be a good idea?”, but at that level of abstraction I’m not sure what the responses would really have told me. So, a secondary reason for putting out this public beta is precisely to get some feel for the question bukayeva poses, since there probably isn’t too much point in my putting a whole more effort into something for which there’s no real demand.

But, I’m also aware there’s something of a chicken-and-egg situation here, since in order to test the demand for adv3Lite in its target market, I’d ideally need to get it to a state in which it could be released to that market (i.e. not only with more bugs removed and more rough edges smoothed over, but with some kind of tutorial manual written to supplement the reference manual that already exists - a decidedly non-trivial amount of work). On the other hand I do feel a bit reluctant to put too much more effort into this without some indication that someone somewhere might be interested in the end result!

Says who? Who says they are “rarely needed”? Why are they rarely needed? Why are they complicated? Complicated to understand? Complicated to implement? (The two can be different.) I’m not disagreeing with you here. I’m just pointing out that bald statements like this tell me nothing except one person’s opinion.

Except that numerous projects in Java, Ruby, and Python show this to be incorrect. Sinatra, as just one example, is an abstraction layer over HTTP verbs and it is massively popular and easy to use. CoffeeScript, Slim, Haml, jQuery – all can be considered forms of abstraction in terms of dealing with their underlying technologies. WebDriver is an abstraction layer that allows you to use various technologies to talk to web browsers. And have done very well at smoothing out complexities. If this is what ADV3Lite is meant to be – fine. A professional programmer probably could have explained it that way, I would guess. But to a new author who may want to try the tool – none of that will matter. What matters is whether the problem domain is matched with how the person thinks about writing in that domain.

This is an area that I think Inform 7 has done remarkably well in. It has provided a DSL and clearly the vast majority of the text adventure community has responded to that.

So I guess I still don’t know: who is ADV3Lite being aimed at? From another thread, those people – whoever they are – aren’t being solicited for their feedback yet. So all that I see is the library is being developed for “some people” who say that “TADS is too complicated” by which they may mean “ADV3 is too complicated” and not TADS itself.

I’m honestly not trying to be combative here. I think TADS is a very powerful language and I respect the work that’s gone into it. (In fact, I actually just like the TADS language as a language, beyond its application towards creating text adventures.) But I also think it’s obvious that TADS 3 is not favored over Inform 7. And I think many of the reasons for that are very obvious. And I don’t think any of those reasons will be changed by the fact that there is this “ADV3Lite” library, which automatically implies “less functionality” to anyone who is used to seeing the word “lite” applied to anything.

Time will tell, I guess. :slight_smile:

That right there is much better than anything else I’ve read so far and a new game author who wanted to try TADS 3 or a game author who already had and was “scared off” would probably respond well to just that simple paragraph right there because it’s concise and gives some tangibles that someone can latch onto.

Regarding (b), if the library is modular – as the ADV3Lite library is as well – could people not be instructed to just remove the parts that text adventures games tend not to need? Meaning, to me ADV3Lite is really that: it’s just a stripped down version of ADV3 and thus really isn’t an “alternative library” – but just ADV3 with the allegedly more complex modules that are not often used stripped out.

Regarding ©, that sounds interesting – but, again: did it need a whole alternate library to make that possible? Maybe it did. I genuinely don’t know. I guess it would be good to see an example that is supposedly “complicated” in ADV3 and then how it is “simpler” in ADV3Lite. Example-driven development here would go a long ways towards clarity, I believe. (Similar to how someone will show how some complicated JavaScript is so much easier to express when using jQuery, for example.)

My own take on the relative popularity of the two systems is actually a bit unflattering to Inform 7. I think it attracts novices because it looks easy to use. It deliberately creates the impression that you can write IF without learning the nuts and bolts of programming. As you get deeper into it, you discover that that impression was somewhat misleading, but by then you’re committed to it because you’ve put time into learning it.

Then there’s the nice cross-platform IDE.

On top of which, I’m sure a certain number of people are enticed to try I7 precisely because it’s popular. If everybody else is using it, it must be good, right?

None of these factors has anything to do, pro or con, with the desirability of a lite library for T3. I’m glad Eric is working on this project, for several reasons. Even if it doesn’t entice anyone to give T3 a try, he may create some useful classes that can be ported back into adv3.

Ultimately, the answer to bukayeva’s question, “Why a lite library?” is, “Why not?” This is an all-volunteer community. Everybody gets to do whatever they like. Questioning anyone’s motives or the ultimate value of their work is not very useful.

I could raise questions about Jon Ingold’s Inklewriter experiment, for example, but I’m not going to go there. Firstly because I may, in the end, be proven entirely wrong; and secondly because it would be pointlessly rude to question the nature or likely future of Jon’s hard and rather interesting work.

In my last game in TADS 3, I had just one room in which a character told the player to follow her and moved once. When it came time to make sure that the player could use the command “FOLLOW” in this instance, I found out that adv3 already has a follow command built in, assuming that you are prepared to hook up all the complex paraphernalia required to make it work.

I then had to spend a considerable amount of time figuring out (1) whether I could use the existing functionality, (2) whether I could twist it to work in a more simple fashion for this one particular case or (3) how to completely disable it and replace it with my own simple verb.

It’s cool that T3 can do something this advanced right out of the box, but the fact is that very few games will require a robust system of following NPCs, compared to the number where you may just need to implement the verb for a few specific cases.

Similarly, I rather like the “house style” for conversations in T3 (greetings, actor states, alternative topics, parting words…) but in games where I’ve wanted to use much simpler conversation systems, ensuring that my characters don’t suddenly turn stupid or mute when you use the (numerous) default conversation verbs has frequently been a bit of a pain.

TLDR: adv3 is full of complex, interlinked behaviour which it is assumed you will use in a certain fashion. A simpler, more modular library would enable TADS 3 to live up to its true potential: as the IF language in which, appearances aside, it is actually by far the easiest to simply write.

(I’ve switched to Inform 7 due to the wider support for the Z-machine, but I find it to be a long-winded language that frequently enforces quite strict assumptions on how IF games should work and present themselves. Funnily enough, the option to start a new I7 project with a cut-down world model is something which has apparently been occasionally requested of I7, and I wouldn’t be surprised if the next version has taken steps in this direction.)

I haven’t tried the new library, but I think it’s pretty exciting that Eric Eve and M J Roberts are actively developing new stuff for TADS. It can only mean good things lie ahead, IMHO.

I have tried many times to write games, and I’m a programmer by trade, so the complexity isn’t really anything more than another library to learn for me. But, in the end, I have only ended up getting a bit frustrated by being bogged down by little details. Not because I can’t solve the problems necessary to achieve what I want, but because I expend a too much of my limited free time resolving the issues than I hadn’t expected and eventually lose interest or have to stop completely mid-stream due to RL necessities and find myself lost to where I was. Since this is a hobby for most authors, I suspect these types of scenarios are quite common.

So, whether it’s a set of robust library objects that hide away a lot of the often unnecessary details, or an entirely new library, if it makes many types of games easier to write, I think it’s worth it.

One problem I can see with having two libraries is that writers might not need the complexity of X for their game, but do need the complexity of Y. In this case, having a “one or the other” situation isn’t ideal.

Yes, I can see the problem. What I had in mind was a couple of scenarios:

(1) Authors coming to TADS 3 for the first time (or coming back to having tried it before and not got on with it) might initially learn the adv3Lite library and then use it for their games for as long as it served their purposes, only moving on to the larger adv3 library if they actually needed the features it provides, or because, having become reasonably competent with adv3Lite there were curious to see what adv3 contained.

(2) Authors already reasonably familiar with adv3 but a little dubious of some of its complexity might give adv3Lite a go and then perhaps stick with it if they found it meeting their needs (but perhaps using adv3 for more heavyweight projects).

That said, these scenarios do rather presuppose that people know and understand the options available, and it may be difficult to ensure that this is the case.

But given that the adv3 library already exists and has a number of broadly satisfied users (so that it would be neither possible nor desirable to attempt to withdraw it), I’m not sure what other solution exists to the problem of providing some users with something a bit simpler other than a second, simpler library. I suppose if one could go back in time to around 2003 knowing what we know now, a more ideal solution would be to devise a single, more scalable library that could somehow work both a bit like adv3Lite and like adv3 according to which options were enabled (perhaps though making some of the more advanced features of adv3 into optional extensions), but even if someone did provide me with a Tardis, I’m not sure how practicable that would be, since the advanced features of adv3 are so tightly and fully integrated into that library, while the relative simplicity of adv3Lite relies on making a number of simplifying assumptions. So I’m actually left wondering what an ideal situation would actually look like (while also recognizing the point you make).

Before I answer, I have to say, I have tried several other IF languages, and TADS is the only one I’ve ever felt was worth investing time in and the library is very sophisticated. So, my struggles are purely due to time restrictions and a case of ADD in my personal life, rather than any real problems with the language or the adv3 library.

If I were to guess, I would think it is possible to offer an additional layer on top of some of those more complicated library components which were less cumbersome to use. These would be an optional set of classes and would have a number of assumptions that would limit their usefulness to the most common needs, but as a result, would be much more intuitive for beginners. For those who need more control or like getting their fingers dirty, they can always stick to the middle layer which is what is used today. That doesn’t help with things like the underlying parser or any of the really low level stuff that I think the lite version is looking to address (or maybe I’m confusing two things?).

I’m not actually complaining about adv3lite. I just wanted to toss in my 2 pennies, in case it was helpful to anyone. I was actually excited when I read about it.

There is part of that, no doubt. But it’s also because Inform 7 provides a humanizing interface to code. This has been a trend for years now. Look at tools like Cucumber, for example, that are very popular in the whole BDD development scene. Just as with Inform 7, Cucumber presents what looks to be easy to use, but then does offer some more complications that weren’t apparent at first.

But that’s okay in that it has done its job: it brought people in. And what I’m understanding is that this is what future TADS development is trying to do. Bring people in who were previously reluctant or unwilling. Using Inform 7 as an example of how to do that is not a bad thing necessarily.

I think it can be useful, as long as it is not combative or done for spite. Questioning the value of one path over another is how healthy development works.

I believe going down the path of ADV3Lite is an ineffective and inefficient path. Just one point you mentioned is a good one: “Even if it doesn’t entice anyone to give T3 a try, he may create some useful classes that can be ported back into adv3.” So why not just write those into ADV3 now? Taking the extreme case, if all of the “lite” library gets back-ported into ADV3, then why not just have a simplified interface as part of ADV3 or an abstraction layer rather than a separate library? If the ADV3 library is not modular enough to support this – although I think it is – then a more viable project may be an incremental refactoring.

All I’m saying is that this is why it’s healthy for a community to question the value of one set of development work over another. That does not mean we are castigating the person doing the work.

For example, were I considering an entirely new library versus some other development path, I would have said: “Okay, here’s X, Y, Z. Those are some examples of features of ADV3 that people seem to find too complicated. What I want to do is make them not so complicated.” But first I need to find out what it is that makes them so complicated. I need the specific feedback of users. Then I would like to understand how they view the domain. How would they have liked to word it? How would they have expected it to be written? What would be an acceptable level of domain complexity?

I think this can still be done with one (or more) of the aspects that ADV3Lite is supposed to solve. I’ve seen this kind of discussion in the Inform 7 forum quite a bit (i.e., “It would be nice if I could code it this way …”) Whether or not the suggestions get incorporated, the discussion is healthy and keeps a user base engaged – ideally prior to a ton of decisions being made and implementation being done.

Anyway, time will tell if I am way off base here. It wouldn’t be the first time. :slight_smile:

There are several points that could be made in response to this:

  1. I think I’ve been around TADS 3 long enough to have some feel for what users think of it; there have been plenty of opinions posted on forums over the years and I’m not totally inexperienced at using the system myself.

  2. The adv3Lite blog was started at partly to encourage just the kind of feedback you’re suggesting. Planned features were posted well before the release of the first public beta so interested parties had the opportunity to discuss and influence the development. In fact no one posted any comments there, but one person did contact me by email, looked at the code, and made a number of suggestions that were incorporated into the first beta release.

  3. The purpose of releasing a public beta early in the development cycle (version 0.1 was very rough round the edges) was to allow people to try it out and, in addition to finding any bugs, offer feedback that might influence the future development of the library.

  4. I expect many people find it much easier to give feedback on something they can try out and experience than on a set of abstract proposals.

  5. In any case an IF authoring library is not like an order processing system or a student record system, where end users have a thorough understanding of their own business processes and thus probably know rather better than the software author what’s needed. The target audience for adv3Lite includes relative newcomers to IF who may have very little idea of what an IF authoring system either needs to or can usefully contain.

  6. Certain constraints apply to adv3Lite simply because it’s based on TADS 3, which means that certain ways of doing things are more with the grain of the language than others. For example, TADS 3 lends itself to using object oriented code in a way that Inform 7 doesn’t.

  7. A further constraint is provided by the fact that the adv3Lite project hardly came out of nowhere. Mike Roberts identified the need for a simplified TADS 3 library some time ago, and started work on one in the form of what he called “Mercury”. He has not had time to complete it however, and a few months back he released the existing Mercury code and offered it to anyone who wanted to use it as a basis for their own projects. Since I’d been tinkering around (not very seriously up to that point) with ideas for an alternative TADS 3 library I decided to take up Mike’s offer and build something on his Mercury code (I hasten to add that it’s not at all what Mike would have built, since he was clearly intending to take Mercury in a somewhat different direction). By doing so I was (a) trying to ensure that Mike’s work on Mercury didn’t want to go to waste and (b) taking advantage of many of the rather nice features it already implemented.

  8. Yet another constraint is provided by my decision to make adv3Lite broadly resemble adv3 in the way it does many things, thereby easing the transition between the two libraries. This constraint is suggested by the goal of making TADS 3 more accessible to users, and no one has really argued why they think this was a poor decision on my part.

  9. It seems to me that most if not all the IF authoring systems actually in use have come about initially through the vision and work of single individuals, however much other people have subsequently become involved in the process. I’m really not at all convinced that anything at all would have been achieved by setting up a discussion from scratch on what people might ideally like to see in an alternative TADS 3 library and then hoping a coherent design would somehow emerge. It seems to me that this sort of thing only happens if someone gets on and does it.

  10. That, however, is not at all the same thing as saying that people aren’t welcome to offer feedback, suggestions, and ideas. They very much are and I very much hope they will. I say again, this is a public beta, not finished released software with everything set in concrete. I take the point that certain design decisions have been taken that inevitably constrain future development, but that is in turn an inevitable consequence of trying to provide a coherent library rather than a jelly on springs.

  11. Some people might find a certain irony in complaints that I am ploughing ahead with adv3Lite without seeking proper feedback while so few people are actually taking the trouble to try it out and actually offer the kind of detailed feedback that might usefully influence future developments.

  12. I am nevertheless immensely grateful to bukayeva for provoking this discussion!

I wonder how many folks had any idea the blog was there? It doesn’t appear on IF Planet. I bet you would have at least some more traffic and interest if it did…

Fair comment. I’ve mentioned the blog a few times here, and when I first set it up I mentioned it on the TADS 3 development blog, which I thought was echoed on Planet IF, but maybe tying it into Planet IF directly would be a good thing, so I’ve just emailed the maintainer to ask him to add it.

Chiming in…

I guess I’m pretty much Eric’s role model for a potential user of the Adv3lite library, since I’m brand new to writing IF, and am still trying to find my way around, and explore different authoring systems.

I’ve had a look at I7 and shunned back, because of the pretended ease of use which, as others have commented, made me afraid of the hidden complexity behind it. I prefer programming over configuring, “C” over Java, LaTeX over Word, because I like to see what’s going on, and when I7 tries to “shield” me from this by using pseudo-natural language, I’m getting wary. Anbody remember COBOL?

I6 looked like a good start at the core, but one can tell the many ad-hoc additions which have been made. Even worse, the number of poorly-organized and poorly-documented tools required to achieve something as simple as displaying a still image has put me off.

So I switched to TADS3 as the next in line as a promising candidate. I’ve started reading “Learning TADS”, and gave up at chapter 4. Now I’m working on “Getting Started”, but, frankly, I’m beginning to lose faith here, too.

Why? Virtually every other sentence is “Now you should look in the library reference, and make yourself acquainted with twelve gazillion classes”, “There is a special sub-class for this and that, or you could use a template…”, everything leading you in a thicket of exceptions, options and modifications – all of which I, as a starter, won’t need. What I’m missing is the explanation of basic concepts – How is a move processed? When (and how) do things happen in general? Not “which setting must I use to achieve a particular effect”, but “where are knobs found to make anything happen?” I’m a bit unclear whether this is a consequence of the TADS design, or of Eric’s writing style, but it’s bewildering and confusing.

I’d like to contrast this with “C” (or, to a similar degree, with LaTeX), where there is a core language with relatively few concepts (which, in “C”'s case, can be sufficiently explained in a 200-page book like “K&R”), and a lot of libraries. Alienating as some of the “C” concepts are (like the whole pointer thing and the memory non-management), once you’ve submitted yourself to them, you’re fine to go with the language wherever you want. All the rest is learning the particular library features you require for this one job at hand. This is my idea of cool design.

Something like this I’d like to see in an IF language, too: A design with a small core, and library add-ons which only come into play when required. As I said, I’m unsure if TADS is built that way and I’m simply too dense to see it, or whether there are really too many dependencies and side-effects intrinsically interwoven in the language. But, to finally come to my point, if the seperation would at all be possible between TADS and Adv3, then there would be no need for an Adv3lite at all, but only a clean design split between “core” classes and “add-ons” (to oversimplify a concept). (FreeBASIC for example allows different language “dialects” with various supersets of QBasic, so you can program pretty much any style between old-school BASIC and highly object-oriented language.) Even more so as file size etc. aren’t currently a consideration which would require one to slim down the TADS installation.

As of now, Adv3lite seems like a half-hearted project to me: “Taking away the complexity without removing the sophistication” looks like a recipe for failure and IMHO bound to lead to a library which is not going to change the amount of incomprehensibility, but only its style. My advice is: Kill your darlings. Sacrifice special features. Will a novice really need doors and connectors? No. Conversation system? Only the most rudimentary one. Drop the exotic special cases. If your user requires them, he can a) hand-model them, b) switch to Adv3, or c) reconsider if he really requires that. It’s never going to be an easy language unless the core required to understand it is small.

Sorry for the rant, there went a bit of frustration with my own incompetence into it.