For some reason I'm always pleased to get
modded up to 5 on
/.. Since I'm no fan of open source software in general, taking the fight to the beast's lair and emerging victorious is very rewarding -- much like, say, being scorned for years as a crackpot firebrand, sticking to my guns, and finding my perspectives and ideas on the lips of the next
(
Read more... )
Ultimately there may be a finite set of problems, and if so then Linux may yet catch up in time, but so far I have yet to see anyone come up with a list of all the areas that would need to be addressed to make that happen. The current list of problems is always met with denial -- only past problems can be admitted. I also feel that the Mac is widening the gap and not standing still.
That said, sure, kiosk Linux systems used for a narrow range of applications and locked out against unintentional damage are not a great deal harder for the average user to walk up to and Google on than a Windows or Mac kiosk system would be. Whether these people would find the same ease in a home Linux system that they had to set up and maintain themselves is a different matter.
Reply
How come macro and scripting systems for modern applications are so much more difficult to use for automating nontrivial tasks than batch files and shell scripts?
Reply
The reason that scripting is more difficult on GUIs comes down to one simple fact: the application developers have chosen not to adopt it in any sensible form, when they adopt it at all. The architecture created for Apple events and AppleScript by my good friend Kurt Piersol some twelve years ago is perfectly sound and very powerful, but app developers have shunned it, even after Microsoft took it and bent it slightly into OSA. (And I'm definitely not letting my current employer off the hook here -- they're one of the worst offenders.)
Reply
FUNNY INDEED.
If I did, though, I could always just run it from tcsh on Mac OS X.
THE POWER OF UNIX UNLEASHED!!!
Reply
Seriously, though, the fact that unix and similar systems make it hard to deal with anything that's not a flat file (ergo est Oracle) actually does have its advantages: give me the the wasted space and other problems of a pile of numbers in tab-delimited ascii over scaring up some 15-year-old library to parse a binary file format any day.
Of course, now that we're all using XML, no one will ever have data migration problems again.
Another advantage to slaving over the command prompt like a neanderthal is that once you've got gawk or perl to do what you want to one file (for numbers I use octave scripts), it's trivial to get it to programmatically do the same thing to 1000 files.
I must admit I haven't done anything like this in a few years now. Also, I have been using Windows 2000 as my workstation OS since, um, 2000 I think.
The reason that scripting is difficult on GUIs is because, say, adding another computed column to a thousand excel spreadsheets requires you to learn a whole new ORTHOGONAL set of skills on top of the skills necessary to interactively use a spreadsheet, move files from your hard disk to removable media, etc.
Reply
I don't think the wasted space matters much today. However, I think that the penetrability of obsolete text formats is overrated, unless one sticks to a very simple feature set. Just following links/pointers in someone else's unrolled text data stream can be a significant project.
Of course, now that we're all using XML, no one will ever have data migration problems again.
Hee hee. Right now it's still an odd-man-out import/export format for most applications. Integration of XML into native programming control flows has proven more difficult than most people expected. Even a simple but critical thing like full round-tripping is often a V3 feature at best. So for today's software, you'd still be digging up that decades-old library to figure out how to export the binary file to XML.
XML itself is more strongly structured than either text or binary, and so is theoretically more comprehensible to future ages, but as the schemas thrash has shown, there is a lot that is not obvious from the layout of data. Somebody else's XML could well be largely incomprehensible after the fact and only partially extractable -- and yet it would still be at least partially extractable.
Do you know of any good essays on the conflicts between human knowledge representation and XML? Last time I looked with any depth into the subject, the otherwise brilliant Tim Berners-Lee was trying to conflate isomorphic synonomy with linguistic structure.
Another advantage to slaving over the command prompt like a neanderthal is that once you've got gawk or perl to do what you want to one file (for numbers I use octave scripts), it's trivial to get it to programmatically do the same thing to 1000 files.
That's why I use perl for my web site. Once I hit the sweet spot for simple template functions I barely had to worry about it for years. Automatibility is great and using an off-the-shelf HTML parser I could do a lot with a very reasonable effort.
Still, there's also no reason someone couldn't come out with a nice standards-conformant GUI web site editing package that would shield me from having to do the back end myself. I just haven't seen one. They all want me to wear my programming hat all the time. That's not a hat I wear while writing, and spending a little time doing my own programming has shielded me from the need to think that way all the time.
I must admit I haven't done anything like this in a few years now. Also, I have been using Windows 2000 as my workstation OS since, um, 2000 I think.
W2K is not at all pretty, but it seems pretty stable. I'm doing my Windows development on it rather than XP.
The reason that scripting is difficult on GUIs is because, say, adding another computed column to a thousand excel spreadsheets requires you to learn a whole new ORTHOGONAL set of skills on top of the skills necessary to interactively use a spreadsheet, move files from your hard disk to removable media, etc.
There's no reason that particular task has to fall to scripting rather than to a fully integrated GUI command. However, I do agree that scripting is orthogonal to GUI use. For instance, it requires at least basic testing and debugging skills, which would be an insurmountable obstacle for many or most people. Perhaps one reason scripting is neglected in consumer programming is that the market of directly affected users is smaller because of popular cognitive barriers to scripting, such as short attention span and lack of deductive or inductive problem-solving skills.
Reply
Leave a comment