Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lucusLoC]

i think you misunderstand my point. the reason we have memory hack tools like DC (or whatever the currently working tool is called) is because DF does not actually have the ability to do those functions. there is no way to manage dorfs en mass, and in order to expose that functionality in a script format the game has to be capable of doing it in the first place.

and "my way" is less breakable than "your way" simply by the virtue that "my way" is editable by whoever has the template. "your way" requires that the author update the tools before they gain functionality again. also "my way" does not exclude 3rd party tools, it just makes them explicitly unsupported. for example, you could have a utility that edits a construction and then spits out an appropriate text file that df could read.

other things that could be "rawified" to an editable save format:

work profiles
trade agreements
embark profiles
stockpile settings
squad rotations and equipment settings
job manager queues (would dovetail nicely with the building template, build all the doors/tables/chairs you need for that dining hall with one command!)

and some from future suggested items:
immigration manger requests (especially useful with the save embark profile)
custom automatic alert profiles



some of these would even be easy to have a simple "save" button in game.

the thing is these are all things that the interface does not yet support (well, most of them anyway, and none of them have an editable save that i am aware of). and the interface would need to support them anyway if we are going to make them available to a scripting language of some sort.

in short, when you get down to it you are asking for a parallel input interface for functions separate from the game interface so that you can change the style they are presented in with a 3rd party utility (ok, that was not so short). that utility may be more streamlined and intuitive. but those functions have not been written yet, and the need to be before we can even think about having a script for them. otherwise all you have is a glorified key press macro utility.   

Spoiler (click to show/hide)

we also need to come up with a better naming convention than "my way" and "your way." it sounds divisive to me, and hinders moving towards a common goal.

[Andir]

I'm not sure I understand how your way and his way differ at all... both of them require an interface to read the command line or the file.  If there was a CLI, could I open up your AI/Template file and paste a line from it into the game and have it interpreted?

If so, why not have a CLI (a single line to enter commands) that you can save to a template file...

[lucusLoC]

the issue is one of form vs. function. if a script is to exist in game, the function for that script needs to exist in game ( i cannot assign "work profile x" to 10 dorfs if the games does not know how to assign a work profile). if the function exists it will need to be able to be accessed by the standard interface.

storing the function itself in a script is a bad way of doing it, in my opinion, since that makes it almost impossible to maintain. any change to the code will likely invalidate the function.

if you have the function contained internally and only have it access saved files of a standard format then it is much easier to prevent those files from becoming obsolete, since all you have to do is modify the parser to map to the new internal structure.

lets look at the above example example. i want to assign work profile x to some dorfs. with the scripting method i would call a script that would iterate through all the jobs for a dorf and change them to an appropriate setting. if i wanted to do 2 dorfs i would modify the script to select the first dorf, change all the settings then select the second and change all those settings. that would be a separate script.

now in all likelihood scripts would be generated on the fly by 3rd party applications, and all you would do is enter parameters and maybe load up presets.

but the whole concept of "work profile x" is stored and implemented in the script itself, the game has no idea what a saved profile is, all it know are that certain dorf have certain jobs enabled and how they got that way is a mystery.

if a command is depreciated it is likely that the entire script will be invalid, and consequently any app that builds those scripts.

if, however, the concept of a saved work profile was internal to the game, with its own function and structure, and its own save format, then it would be far more resistant to changes and those changes would have a known effect and be taken into account. that functionality could still be opened up to an API of some sort, but it would be a much simpler and shorter call.

you could argue that this puts all the work load on toady, but i would argue that it actually saves him work in the long run because he does not need to maintain a second interface to the game.

[ggeezz]

i think you misunderstand my point. the reason we have memory hack tools like DC (or whatever the currently working tool is called) is because DF does not actually have the ability to do those functions. there is no way to manage dorfs en mass, and in order to expose that functionality in a script format the game has to be capable of doing it in the first place.

Toady wouldn't need to write functions to manage dwarfs en mass.  You only have to be able to change 1 job for 1 dwarf (which is already supported), then a tool can change all jobs for all dwarfs by repeating the 1 function as many times as necessary.

In general, Toady would only have to create the atomic functions, and then tools would create series of function calls that produce complex changes.

and "my way" is less breakable than "your way" simply by the virtue that "my way" is editable by whoever has the template. "your way" requires that the author update the tools before they gain functionality again. also "my way" does not exclude 3rd party tools, it just makes them explicitly unsupported. for example, you could have a utility that edits a construction and then spits out an appropriate text file that df could read.

That's not necessarily so.  One way to design a third party tool for such an interface (perhaps the best way) would be to read all codes from a configuration file.  Some of the third party tools already work in a similar fashion by reading memory offsets from a config.  This way a user would be able to update their own copy.  Or better yet the first person that updates it can share the configuration with everyone.

[Andir]

you could argue that this puts all the work load on toady, but i would argue that it actually saves him work in the long run because he does not need to maintain a second interface to the game.

You lost me because there's still an interface... the interface to run your scripts and the interface to give them access to the values they can change.  They have to have access to certain parts of his app.  The mere idea that an external script can modify internal variables without memory hacking or exposing those variables into an interface just doesn't fly.  Toady would still have to load in said scripts, hand them an object with all the variable accessors to let the script change those values.  No programming language that I'm aware of will let a script modify any value it sees fit, with the exception of javascript, actionscript, and a few others... but those aren't fast enough to process the amount of data Toady is and one could argue that they aren't languages, but script. They also aren't as "source secure" as the current method.

[Grax]

Interface is great at all, nothing needed to be changed now. Maybe in far future versions, but not now.

[ggeezz]

you could argue that this puts all the work load on toady, but i would argue that it actually saves him work in the long run because he does not need to maintain a second interface to the game.

You lost me because there's still an interface... the interface to run your scripts and the interface to give them access to the values they can change.  They have to have access to certain parts of his app.  The mere idea that an external script can modify internal variables without memory hacking or exposing those variables into an interface just doesn't fly.  Toady would still have to load in said scripts, hand them an object with all the variable accessors to let the script change those values.  No programming language that I'm aware of will let a script modify any value it sees fit, with the exception of javascript, actionscript, and a few others... but those aren't fast enough to process the amount of data Toady is and one could argue that they aren't languages, but script. They also aren't as "source secure" as the current method.

What I'm saying is that a 3rd party tool could create functionality that Toady doesn't write by building on atomic functions.

Right now, you can change 1 profession for 1 dwarf at a time.  That's atomic.  It can't be broken down any further.  You can also view the professions active for any dwarf.  Toady has written the game to allow this, but there's no programmatic interface for these same functions.

If there were a 3rd party tool could query the interface, show you a form and then perform 100 commands in the game to make your changes.

So Toady doesn't have to write an interface or functions to allow you to change multiple professions for multiple dwarves.  He only has to write the basic functions (Query all dwarves and Edit a single dwarf) and those can be combined to do anything.

[Andir]

you could argue that this puts all the work load on toady, but i would argue that it actually saves him work in the long run because he does not need to maintain a second interface to the game.

You lost me because there's still an interface... the interface to run your scripts and the interface to give them access to the values they can change.  They have to have access to certain parts of his app.  The mere idea that an external script can modify internal variables without memory hacking or exposing those variables into an interface just doesn't fly.  Toady would still have to load in said scripts, hand them an object with all the variable accessors to let the script change those values.  No programming language that I'm aware of will let a script modify any value it sees fit, with the exception of javascript, actionscript, and a few others... but those aren't fast enough to process the amount of data Toady is and one could argue that they aren't languages, but script. They also aren't as "source secure" as the current method.

What I'm saying is that a 3rd party tool could create functionality that Toady doesn't write by building on atomic functions.

Right now, you can change 1 profession for 1 dwarf at a time.  That's atomic.  It can't be broken down any further.  You can also view the professions active for any dwarf.  Toady has written the game to allow this, but there's no programmatic interface for these same functions.

If there were a 3rd party tool could query the interface, show you a form and then perform 100 commands in the game to make your changes.

So Toady doesn't have to write an interface or functions to allow you to change multiple professions for multiple dwarves.  He only has to write the basic functions (Query all dwarves and Edit a single dwarf) and those can be combined to do anything.

What you are describing is nothing more than:

> GET_CREATURE
Cat1, Cat2 (all creatures)
> GET_CREATURE Dwarf
Dwarf1, Dwarf2, Dwarf3, etc. (all creates of dwarf)
> GET_CREATURE 5, 60, 50
Dwarf12, Cat3 (all creatures at x, y, z)
> GET_PROFESSION
Cook, Farmer, etc.  (all professions)
> GET_PROFESSION Dwarf12
Miner, Farmer, etc. (all Dwarf12's professions)
> ASSIGN_PROFESSION Dwarf12 Miner
Dwarf12 is already Miner
> REMOVE_PROFESSION Dwarf12 Farmer
Success
> GET_CREATURE_INFO Dwarf12
Dwarf12: Urist McMuffin
Location: (5, 60, 50)
Professions: Miner, Cleaner, Transport_Stone
...etc.

Which can be done in a CLI as well... where's the difference?

[Disclaimer: I used arbitrary commands for example only...]

[ggeezz]

It could be done in a CLI, but it seems to me that would be rather slow if you were changing professions for 200 dwarfs.  I don't know though.  That's just my experience with CLIs.

[Andir]

It could be done in a CLI, but it seems to me that would be rather slow if you were changing professions for 200 dwarfs.  I don't know though.  That's just my experience with CLIs.

What I'm getting at is: What you ask is no different.  Toady still has to have an API to do what you want and if he ever changes it, it will break something.  But Toady's main concern, from what I understand, is a third party tool dictating that his next update include something he doesn't want added, or having them control his updates.

[Footkerchief]

ggeezz, judging from what you said I'm guessing you've already seen Toady's statements about the risk involved with third party interfaces, but I'll post them here anyway for the benefit of anyone who might not have seen them:

Spoiler: first quote (click to show/hide)

Somebody reported a post in this thread...  it didn't really matter which one.  A bit of chilling would be good.  There are a few people that have failed to chill.  There are quite a few statements here I'd respond to in person myself, and some very sharply, but internet discussions are more fragile and more prone to derailment.  So I'll try to stick to what seems to be the core of the matter.

Which for me (and granted, I'm picking a recent post -- I've read the thread, but don't remember when this came up first in this thread) is along the lines of what Jamuk said.  I'm being asked to assume risk.  I don't accept assessments of the risk as extraordinarily slight -- I've seen no sound basis for those assessments here.  I also don't think the currently proposed licensing/obfuscation method of putting the cat back into the bag would work -- with a principal downside being that it requires me to turn into an asshole who, after initially sanctioning the process, breaks everything that people have been working on.  Publishing an API and then trying to reel it back in just seems completely unworkable and irresponsible to me.  So the point is to assess risk upfront and then make a decision I can live with.

And right now, I have no idea what would happen.  This isn't the same as leaving my math job or adding the Z coordinate.  The first was a decision I had to make personally for my quality of life, and the second was a calculated risk which I didn't really have strong misgivings about (though some people are still pro-2D version, I think I can get most of them what they want over time in terms of gameplay difficulty, etc., though it'll never feel like it's quite on that rail again most likely).  Do I accept that third parties could improve the interface?  Of course.  Do I think I could do better than a third party myself, even over time?  No, not at all, though I can certainly improve on what I've got now to a large degree even without external input (which I, of course, love to receive).  So, initially, there's some attraction to the third party interface idea.

However, reflecting on the position I'd be in, there are things not to like about it.  How many threads were there about broken utilities when this version came out?  If more than half the player base comes in off a third party interface (and given how much the current interface sucks, and how much it is a source of first time downloaders dropping the game, this is not only imaginable, it is very, very likely), how would it be if it broke at each release?  There's no way to mitigate that without my direct involvement -- imagine a release down the line where you can suddenly move dwarven armies around on the world map, with a tactical view and various options.  That interface can't write itself, and it wouldn't be a quick patch, though certainly dedicated people, assuming that about whoever is maintaining the front-end at that time, can pull things together rapidly.  The pressure on me to work directly with them to get the interface out at the same time as the game itself would likely be immense and disruptive, given what little evidence we have from broken utilities.  That's not to say that I often get requests to work with utility writers (other than from the writers themselves, who I generally accommodate), but this would be at a different order of magnitude.

So what's the exact risk there then?  First, I don't want to work with other people.  So, assuming I don't do that, there's now a constant amount of pressure on me and a general disruption in the forums.  The latter could be mitigated with some announcements/guidelines, etc., but the pressure wouldn't go away.  Monetarily, it's impossible to say what on earth would happen, but if I supported the third party interface directly pre-release, I'd likely make more money, but I'd be unhappy.  If I didn't support it directly, but it was there, I'd still likely make more money, but I'd be unhappy.  That's not to say that I don't want to grow the audience and allow more people play the game, but I want to do it in a way with which I feel satisfied, even if that ends up being slower or just plain worse than a hypothetical third party alternative.  If someone, as a potential donor, thinks that's unreasonably selfish, that person shouldn't send me any more money than he or she thinks I've deserved for his or her enjoyment, just like everybody else.  Despite my dedication to this project, I'm unwilling to sacrifice my enjoyment of working on it for anything, including its quality or even its future release if it comes down to that.  That should be plainly obvious.  I'm not a slave.  Of course I do some things I don't like working on, with the interface and more.  I fulfill requests for features I'm not going to use myself.  However, again, the current proposal is of a different order of magnitude, with the potential of ruining it for me, and the end result is completely uncertain.

Given what I've seen here and there, it seems like a full third party interface might develop even without my involvement (rather than the various utilities we have now), but in that case, despite the same issues that might come up, at least it won't be a situation of my own creation that I feel a strong obligation to deal with, although the pressure would still be there.

Incidentally, in the proposed model, I still don't think I'd be able to bring code back in to the core project -- the first Kobold Quest port attempt showed that people bringing in code don't necessarily check or care about the licenses of the code they are swiping, and I can't assume that responsibility for them (it has stuff from Wine which shouldn't have been there).  Problems come up here with tilesets and so on too -- I know there've been a few cases where a contributor used somebody else's art and then it was put in a game, causing some legal trouble, though I don't have them at my immediate disposal.

I may have missed a lot, both problems I'm not thinking of and ways to handle them, since this gets complicated and is, due to lack of information, somewhat unspecified, but that's what I've got right now.

Spoiler: second quote (click to show/hide)

I tried hard to put myself in your shoes and see things from your point of view, but apparently I failed to understand one thing (correct me if I'm wrong): the general atmosphere of the forums and feedback you receive from players is an integral part of your happiness. I was imagining that you could just let the mess settle down by itself after every release, but since I am not this forum's moderator, I can't really tell how it feels to have a big mess of threads about stuff not working.

It generally sucks to have a bunch of people complaining that things don't work, especially when there's something I can do about, that is, work with the interface modders more closely, having in this scenario sanctioned third party interfaces and released a public API.  It's the pressure that would make me unhappy.  It's good when the forum people are happy, but that wasn't what I was getting at so much.

When you speak of pressure, are you picturing direct pressure? I have a hard time imagining people screaming at you on the forums, except maybe for the occasional moron that can be ignored. Wouldn't people rather be putting pressure on the third-party developers to update their interface ASAP? But maybe you'd feel pressure nevertheless because you dislike seeing that people cannot play the game.

There would be direct pressure on me to work with third party developers -- this isn't about screaming.  This thread itself is direct pressure to work with third party developers (or at least get the ball rolling).  That isn't to say I disagree about you posting it.  I'm simply stating what it is, and I think that yes, there'd be a lot more of this, a lot more I'd have to reply to, and a lot of...  pressure.  Additionally, I'm not just talking about external pressure, in fact, principally not -- having created the situation, I would feel some obligation to make it run as smoothly as possible, and I would rapidly become irritated by this, because it's some of my least favorite kinds of work.

One thing I'd like to point out, though, is that you seem to think that a single interface, "The front-end", would come out of third-party development. Even though that's possible, open-source usually seems to bring diversity (look at the number of linux distros), especially in a single-player game where people don't have to use compatible clients, so they can play together. So I think we'd likely see an improved ascii client, a 2d tiles client, an isometric client, a 3d client, and maybe several of each one. In my view it would distribute the uproar, so that at least not everybody would be complaining about the same thing  . But I don't know if you see that as a relief.
[emphasis added]

He he, of course not.  It's worse actually -- more parties to work with.

Lastly, I may have a good way of mitigating the breakage of third-party clients at every release, without requiring your direct involvement. Assuming that you develop your own open-source interface at the same time as your closed-source server, you would likely publish your interface changes to a public SVN server. You would probably do it incrementally, at the rate of one or several commits a day - akin to backing up your work whenever you've made a step. In that case, you can bet that enthusiastic developers will watch those changes keenly, to see what's going on with the interface. This means that third-party client makers will already know that moving "dwarven armies around on the world map, with a tactical view and various options" is coming for the next version (from your very detailed dev notes), so they'll have time to plan which kind of interface they want to provide for that. And since they'll see the necessary code changes evolve gradually, because you'll always need an up-to-date interface for bugfixing, they'll be able to follow closely your development. They might have to adapt to your last minute changes, but otherwise I believe that the days of bugfixing prior to release could be enough for some of them to finalize their clients on time.
Now of course, you have to feel comfortable with that way of working.

Yeah, this somewhat mitigates breakage with those third parties that are active and approaching the situation with some dedication, but the trade-off of working with my day-to-day changes under that sort of scrutiny is definitely a minus for me, and I don't think it could really happen in a vacuum without questions about changes and so on, or without me feeling like I have to provide some sort of documentation as I add things.  I don't know if that sounds like quibbling, but I can't easily overstate how much I hate managing code or collaborating on code or anything along those lines.

Additionally, I think breakages would still happen, especially when staff leave projects hanging (work obligations, got tired of it, vacations, etc.), and it wouldn't change the fundamental situation I'm imagining, although in the case of project abandonment or delays with staffing, where there isn't pressure to work with the (missing) people in question, it's more the pressure to incorporate changes back into the base API, which as I stated in my previous long post, I wouldn't be able to do without potential legal problems.


I don't mean to write as if I'm sure about any of this, but once I drop this bomb in my project, I can see every day becoming "oh man, what a goddamn hassle" instead of what I've got now, which has less of that.  Again, I think the OP is justified in starting this thread, so I'm not raising that as an issue, but I've also spent some hours in here, reading posts and composing these replies.  That stuff just starts to magnify, and I'll either end up ignoring people I don't feel like I should be ignoring, or not ignoring people to the detriment of the core game itself and my own well-being.

What I would like to hear from Toady is what kind of graphics he has in mind for when he gets to the interface overhaul. That way we could at least prepare some sprites ahead of time and have nearly complete graphics sets as soon as the version with the new interface comes out. I personally waste a lot of my free time doodling in GIMP, so I might as well do something useful.

Depending on the stage of the interface overhaul, ultimately I'm going to be support 2D tilesets (probably in dimensions of multiples of 4 because I'm lazy with image file headers).  So if you want to draw up some 32x32s or something, you won't be wasting your time, I think.  It should be fairly straightforward to support single z-slice isometric stuff as well, once I get that going, since I'd just have to change the print locations and print order, though transparency decisions are probably annoying, and it's slightly more annoying to get multilayer isometric stuff going, since people are going to want various options about display there, so I don't really have a clear opinion on the future of isometric.  The support for a resizeable viewport/window is definite, but nothing has been decided on layering there (for instance, critters walking over grass tiles, that kind of thing -- people will want more and more out of this system, such as inventory and wound displays, and I'm not sure where lines will be drawn, or where it will bog down, anyway).

yeah but did the whole negativy and hostility bring anything beneficial here?

What did it do beneficial? It finally caused Toady to step in and give us a detailed explanation of his point of view thus I guess the best way to get him to respond is to insult one another. Or just report posts.

In case you weren't joking, I wouldn't overstate the value of the report.  I was already following this thread and was planning a reply.  The report got me to come in a day early or so, since things were starting to get sort of silly.  And they still are.

[ggeezz]

It could be done in a CLI, but it seems to me that would be rather slow if you were changing professions for 200 dwarfs.  I don't know though.  That's just my experience with CLIs.

What I'm getting at is: What you ask is no different.  Toady still has to have an API to do what you want and if he ever changes it, it will break something.  But Toady's main concern, from what I understand, is a third party tool dictating that his next update include something he doesn't want added, or having them control his updates.

You can manage breakability.

If the function calls were strongly typed, then type mismatches would cause problems.  So you have loosely typed function calls to mitigate that problem.  You can handle deprecated calls by ignoring them.  You can handle new or deleted skills/professions/etc. by defining codes for them and ignoring calls to codes that don't exist.

I think there's a way to design the API such that breakability is a non-issue.  Yes, certain things will cease to work.  For example, you may assign a dwarf to be a cook, and it doesn't work because that profession doesn't exist anymore.  But that's not an issue.  And there may be professions missing, but that's a small and easily fixed issue.  It won't stop people from using the tool and shouldn't affect Toady's decision to add or remove professions/skills/etc.  Yes, people will want the tool to support the new professions, but all Toady will have to do is specify the codes for the new professions.  He doesn't have to work with anyone.

And then there's the issue of fragmentation.  I still think fragmentation is actually less likely if Toady provides "the right kind" of interface.  We already have Dwarf Companion.  People went to extreme measures (memory hacking) because there was great demand for what it supplies.  The lesson is that you cannot stop something that enough people desperately want.

The best way to keep a DF clone from gaining popularity is to keep people satisfied with DF.  The best way to keep game mods from gaining popularity is to solve the problems mods would solve.

However, reflecting on the position I'd be in, there are things not to like about it.  How many threads were there about broken utilities when this version came out?  If more than half the player base comes in off a third party interface (and given how much the current interface sucks, and how much it is a source of first time downloaders dropping the game, this is not only imaginable, it is very, very likely), how would it be if it broke at each release?  There's no way to mitigate that without my direct involvement -- imagine a release down the line where you can suddenly move dwarven armies around on the world map, with a tactical view and various options.  That interface can't write itself, ...

There are two issues here.  First, if DC used an interface similar to what I propose it wouldn't "break" even with this mega-release.  And the parts that need updating would be trivial to fix.  All Toady would have to do is make a table with the new codes.  The same would apply to a theoretical digging/furniture tool.

But suppose a tool provided a complete interface overhaul, slick 3D graphics and such.  That would need major work and major involvement from Toady.

So it seems to me the best path is to facilitate things like DC and a designation tool (and make them forward compatible), but to discourage things like a "complete interface overhaul."  The best way to discourage a complete interface overhaul is to lessen demand by solving some of the problems the alternate interface would solve . . . like mass dwarf management and designation.

Suppose that it was very easy to do DC and you expect it to be easy to maintain.  And it was comparably hard to do an alternate interface and would likely be a nightmare to maintain.  Toady would be encouraging the former and discouraging the latter, which it seems is what he wants.

And when a new feature comes along like moving armies around a world map, it makes sense for Toady to write that first and then have 3rd parties tools after it has matured.  And if modders expect that an interface will come some months down the road, they'll be less likely to start memory hacking in the interim. 

And that brings up another point.  There's a large difference between an add-on tool like DC and a tool that "becomes the game" and takes over all interface elements.  Players should expect to play Toady's version of the game, to see new features as Toady intends them to be seen.  Otherwise we're heading towards the trouble he fears.

So it seems we should only have add-ons for mature parts of the game.  These parts are still changing, but those changes can be handled easily by publishing new codes.  And you discourage modifications to the new stuff with the expectation that it will eventually become mature stuff that's easy to work with.

[ggeezz]

I was starting from certain assumptions, namely that Toady doesn't mind things like DC, but he is worried about things like Khazad (or what it may eventually become).

Can anyone confirm or correct?

[sweitx]

In short, Toady's knows what he's doing, please stop bugging him with something that he already said "No" a couple of times before.
For those who do programming for a living, you understand how quickly subroutines gets entangled together, how a seemingly "simply" change to one will affect a dozen others.  Dwarf Fortress, given its complexity, is even more susceptible.  More so as it is a program that's under constant changes and overhaul.  A good analogy is you have a room that's partially furnished, Toady releasing an interface will be an equivalent of nailing some of the furnitures down so people can, say, decorate it.  But if Toady later need to make changes that involve moving those furnitures...

[ggeezz]

In short, Toady's knows what he's doing, please stop bugging him with something that he already said "No" a couple of times before.
For those who do programming for a living, you understand how quickly subroutines gets entangled together, how a seemingly "simply" change to one will affect a dozen others.  Dwarf Fortress, given its complexity, is even more susceptible.  More so as it is a program that's under constant changes and overhaul.  A good analogy is you have a room that's partially furnished, Toady releasing an interface will be an equivalent of nailing some of the furnitures down so people can, say, decorate it.  But if Toady later need to make changes that involve moving those furnitures...

I'm not suggesting Toady doesn't know what he's doing.  Obviously he does.  It seems he's also open to suggestions, which to me is a mark of knowing what you're rather than not knowing.

I program for a living.  I've written sets of functions that were horribly fragile.  The smallest change would break them.  Over the years I've learned a little about how to make them more robust and it's made my life much easier, though I still lack much skill/knowledge.

In short, interfaces do not have to hinder development, nor be so fragile.  The Agile philosophy and other related work has helped in this respect.  I think there are ways to create an interface that would cause mostly headache, and ways that would cause very little.  But I don't claim to have all the answers.

I just think that there IS a way for all of us, most importantly Toady, to have our cake and eat it too.  And to that end, I'm soliciting input.