People don't like to learn new things and expect the "perfect" software to guess what they are trying to do and do it for them. (shades of XP?) However to those of us who who know what we are doing such application behaviour is obtrusive and annoying.
This is another large HCI issue. How do you make an interface which is "intuitive" and "user-friendly" so that even a person who has never experienced a similar system before, be able to use it without any form of training; AND make sure that the same interface doesn't get in the way of someone who has been using it for a while? For simple programs, this is no big deal. For complex programs, it is. MS tried to solve this in office2k by hiding options that weren't used often. For a new user, the menus are sparse. There is nothing to confuse them. Experienced users can still navigate their way round and get the required functionality. Lets not mention the problems caused to new users when office decides something isn't used much any more and hides the item from the menu ;)
As far as learning new tools, such as lisp, emacs, or sendmail rewrite rules I have one teeny problem. I kind of don't like learning legacy, ready to die, non progressive languages for the sake of maintaining legacy applications. I would put sendmail in that category. I think its concept is way to clumsy. I would like to see something a bit more logical and more closely related to the problem domain rather than idiosyncratic syntax.
emacs and lisp are not 'legacy' I cant use ms office at uni - no win32 boxes. I refuse to use staroffice because its a pain in the ass, huge, and mimics a win32 desktop - which is REALLY annoying in linux. I use emacs instead, it does everything I want, and it does it better than the office suites would have. And it has tetris :). sendmail, well...
However I think languages like Java are a good idea. I think any kind of RAD tool is a good idea. I think languages that create a better representation of the problem that they are modelling are a good idea. I just don't like seeing old technology hanging on past its use by date because it's "tried and proven".
There is a big difference between continuing to support legacy apps because they are already implemented in a production system, and implementing a legacy app in a new system. By all means, when rolling out a new mailserver, use exim or postfix or qmail, or whatever you prefer. I think if you tried to replace a legacy sendmail server in a large network you'd create far more problems and spend far more time than it would have taken to have learned how to use sendmail to the point you can fix the problem.
Yes, we should be willing to learn, if its progress. As long as its not COBOL. ;)
Even if its not progress, we should be willing to learn. How much of the software / it consultant industry in the 90's was to do with "Y2K bugs" ? Which could all fall under the domain of 'legacy applications'. COBOL's another kettle of fish entirely ;) (although, a good deal of aforementioned 'y2k bugs' would have been for cobol systems) Daniel ------------ WLUG - The Waikato Linux Users Group WWW: http://wlug.linuxcare.co.nz To unsubscribe, send an email to majordomo(a)list.waikato.ac.nz with "unsubscribe wlug" in the body of the message.