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:
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: dl.dropbox.com/u/58348218/adv3Li … 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.