To view parent comment, click here.
To read all comments associated with this story, please click here.
I do not believe into orthogonality of GUI and textual interfaces, because text is graphics and images convey meaning. I wish people would see over the implementation details and understand, that the goal is to mimic normal human conversation, not draw pixels or walk the rodent around the keyboard.
If 50 years ago textual interaction was limited to console with one-line edit buffer, it doesn't mean that the proponents of language interfaces still want to force fixed-width green-on-black ASCII characters down people's throats. We just want to at least retain the functionality we always had so we don't get lost as our clients are.
GUI applications are wrong because designer is forced to reinvent the interface for every single application, because the application is tied to the pretty picture you draw to the end-user, because you limit your application to a certain platform and the single way you physically access it, because your application becomes monolithic and because it becomes unautomatable.
What you mention about Tcl/Tk is nice, but the implementation is still wrong; I want to talk to the computer, not gesticulate to it.
I kinda agree, and I kinda don't. Let me try to explain...
Every program sets out to accomplish a given task. Some tasks are better for users via GUI and some via CLI. It doesn't mean that you can't implement them as either - just some are better suited one way or the other. As such, users will be able to use the program better when its UI is the one that is better for that task.
That said...I try to provide both kinds of interfaces for my programs. Why? Most users like GUIs better - it's more natural to them, so providing a GUI is good. However, at the same time CLIs are better for scripting and other tasks that admins and some (not all) developers like. So there's an audience in providing both. Providing both pushes the core of the tasks to library APIs, so you get better, more extensible code architecture/design too.
Some systems (e.g. IBM AS/400) do things the old Green-Screen way - for that you need to interface appropriately, and provide transitions appropriately. (Yes, I've done worth that way!)
Also - there is no reason to be tied to a single platform with a GUI any more. There are a number of toolkits out there (Gtk, WxWindows, Qt, KDE/Qt, SDL, etc.) that enable software to cross the platform barrier from a single code-base. Furthermore, it's very easy to do.
It doesn't help to stay stuck to CLIs, nor does it help to go overboard on GUIs. There's uses in both.
True, GUIs do provide more information as the graphics used have meaning to the user. However, as DejaGNU and other toolkits do provide - they can be automated.
I'm not going to say CLIs are the end-all-be-all. They aren't. And a GUI does not necessarily mean a big monolithic application - it doesn't.
A GUI will typically be a bigger application than a CLI as there is a lot of code for handling events from the GUI. However, ClIs are not that small either b/c they have to parser the I/O a lot more - and that is a lot harder to do than in a GUI, and often results in a lot of redundant programming too.
In either case there is a core functionality. You don't have to reprogram that core functionality every time you have a new program - that's what libraries are for - whether using shared, static, or convenience.
As the saying goes - there's more than one way to skin a cat. ;-)






Member since:
2007-08-22
Actually you can - by using tools such as Tk and Tcl. DejuGNU (build on Tcl/Tk) does this quite well to produce fully automated GUI test suites to ensure GUI components work well.
I think the bigger issues comes down to that a lot of programmers don't like writing GUIs, so they avoid them - despite the fact that GUIs are a lot, lot friendlier to end-users.
You can do almost anything with a GUI. But 'plugging' different applications together through GUI components is a bit harder - but, as I said above - it can be done. You just have to adjust your toolkit appropriately, which may mean learning another programming language that can do the job (like it or not).