Page 1 of 1

Excessive complexity, or difficulty for difficulty's sake

Posted: Wed Jan 04, 2017 12:27 am
by Tdarcos
The MGM studio had the (Latin) motto, "Ars gratia artis," which translates roughly as "art for art's sake," in that sometimes creating artwork can be for its own purpose, just to make the world more pretty.

Having worked with TADS and having watched a few YouTube programming videos about other programming languages where they criticize object orientation as "unnecessary complexity," or that object-based programming really doesn't buy you advantages that you didn't already have with ordinary functional or procedural programming in 3rd generation application languages.

This may be one of the things I'm seeing in TADS is that too much object orientation was thrown at the language and changes a lot of its operation in ways that making use of the language harder.

The method for defining new verb commands has no correspondence with the implementation of those commands. One defines a name, then specifies that name along with "action", but the actual implementation uses that name without the "action" clause. This is non-intuitive and seems to make things harder.

Also the separation into a set of, well I'm not sure what to call it, perhaps "sections" or "conditions" which determine whether one is checking the command verb for validity vs. executing the command and which again, are not clear as to why they are done that way.

I think I've been spoiled by the somewhat "cleaner" method Hugo was using to separate vocabulary from the routines that execute it. Vocabulary is not code and is defined as the set of commands available and from that different routines that handled each command.

I mean, for decades people picked on COBOL because of its wordiness - I did too - but at least when you did something you declared it more-or-less unambiguously and the language was designed to handle a specific problem domain, the processing of record-oriented transactional data. This is what made COBOL probably the most-used programming language, ever. (Over 80% of software is not for use by the public or sold publicly and as such what is public skews the perception.)

So while TADS is potentially a useful tool in the problem domain of Interactive Fiction I think its unnecessary complexity tends to be more like difficulty for difficulty's sake, a way for programmers to take pride in their "machoness" in being able to use razor sharp and dangerous tools.

I look at the "sneering" that Basic - especially Visual Basic - along with Turbo Pascal/Delphi got in allowing rapid application development because, supposedly, "real" programmers wouldn't use them despite the fact they are/were not toy languages and you could write applications that got real things done.

Because, in the end, that's what a programming language or system should do. Allow people to develop tools to solve whatever problem they have, and (presumably) to increase their efficiency doing so. Writing an Interactive Fiction game using a tool designed for IF is much easier, and makes the person doing so more efficient, than using a general purpose programming language, the way using SQL makes data access queries more efficient than using sequential files you have to read every record from the beginning to the end of the file.

But when the complexity of the tool gets in the way of using it, then you end of losing a lot of the benefit that it otherwise would give you.

Posted: Wed Jan 04, 2017 4:24 am
by Billy Mays
I hope Tsummary swings by and makes sense out of all of this.

Posted: Wed Jan 04, 2017 8:14 am
by Tdarcos
Summary: The TADS Interactive Fiction system is overly complicated and the excess complexity does not seem to "buy" anything in terms of an improvement in ability to be more efficient or make it easier to write these types of games.

The rest explains why I think this is the case, based on my experience in other programming languages

Posted: Wed Jan 04, 2017 8:33 am
by pinback
That should have been your post. We asked you, if you were going to stray out of the Troll Room, to be concise, and your first post was multiple pages and included COBOL references.

You are 0 for 1, in 2017.