Jeremy Bowers wrote:
<snip>
Domain-specific abstractions do that *faster* than GUI designers, not slower. And better, too, since every iteration tends to be fully functional and not just a "let's see what this looks like" prototype.
Heck, switch 'em out dynamically based on what day of the week it is and how the user feels today. Let's see your GUI-designer do that.
And if you're not used to doing it that way, you'll be *stunned* at how much stuff tends to factor out and get easily re-used.
An approach that has more data to work with (some idea of what things are doing and what they are for) will beat an approach with less data ("thing at row 4, col 2" or, worst case, "thing at 233,144") any day.
GUI designers are like the regexs in the famous jwz quote: "Some people, when confronted with a problem, think 'I know, I'll use a GUI designer'. Now they have two problems." Both have a niche in the "quick fix" department, both are typically over-used, but overall regexs are the more useful of the two; at least there are cases where they are the undisputed right answer (like defining tokens in a language parser).
Generally, over the first couple of weeks of a project, the domain-specific language writer may seem to be behind the GUI designer cranking out screen after screen of templated GUI widgets, but after a couple of weeks the domain-specific language user will pull into the lead and never give it up, and will be a lot happier to boot.
First time i hear about domain-specific abstractions.
Do you mean that instead of using a GUI designer, you make some sort of engine that constructs a gui for you?
One thing i find repetitive to do is designing gui's that are just simple views on a database tables where one can create,edit and delete records. If one could construct a gui dynamically for these types of things, that would be great.
Benedict -- http://mail.python.org/mailman/listinfo/python-list
