This thread on the sas-l mailing list got me thinking on why I rarely try out other editors these days. Granted it is specific to the product but still, there are lessons worth learning from it.
If you see the litany of complaints in that thread, first off, you'd notice that in a code editor that is pretty much non graphical in its code presentation, you'd have few of the problems listed. Sure, you'd have to do a lot of pagination to paste and read code later on but you don't have to tear your hair out in doing so.
And if you were just that bit script savvy (not necessarily elisp), you'd be that much more productive and less error prone. The complaints listed are the ones that bug me too. I don't seem to know what is happening when the table structures are copied as graphical objects or some sort object is copied in these GUI heavy editors. And the dreaded mouse clicks drudgery in validating whether the structures are being copied correctly?
That'd kill me out of sheer boredom.
Partitioning the code, testing it in little pieces, assembling it in functional pieces are lost with these editors. Sure, you can do it but that comes with experience and I bet that you'd have to do the mappings and flows all over again while assembling it.
If it were left to an editor like vi or Emacs, cloning, copying and modifying large parts of code is easy with a bit of builtin functions or other Unix tools like sed, grep and bash shell. Notice that you are not forced to use the editors themselves if you want to? But with these new editors with their project folders and tracking, you'd have to hack it to figure out data structures and try figuring other means to edit the code. And it all goes awry in the next release of the editor.
The more you use the product editors, the more is the learning involved in relearning doing the same things because the menu options have changed. There is very little in applying what you've already learnt to be productive immediately.
That's partly the reason why people are pretty insane in sticking to Emacs or Vi. Compared to sheer frustration with a "smart" editor, these are plainly functional tools that are general purpose text editing applications that Just Do The Job.
You build on what you've already learnt with Emacs; the core functionality is always available in all the modes and you learn the mode specific behaviour as required. And being text oriented, you've got only yourself to blame for any "mysterious" bug that appears.....well, mostly.
Every new fangled editor comes with some new idea that makes it worthy in some respect but you seem to have to lose out a number of other features that makes you productive to use it.
I threw in the towel a long time.
Now, I just check out whether the same feature is available in Emacs in some form or the other.
If you see the litany of complaints in that thread, first off, you'd notice that in a code editor that is pretty much non graphical in its code presentation, you'd have few of the problems listed. Sure, you'd have to do a lot of pagination to paste and read code later on but you don't have to tear your hair out in doing so.
And if you were just that bit script savvy (not necessarily elisp), you'd be that much more productive and less error prone. The complaints listed are the ones that bug me too. I don't seem to know what is happening when the table structures are copied as graphical objects or some sort object is copied in these GUI heavy editors. And the dreaded mouse clicks drudgery in validating whether the structures are being copied correctly?
That'd kill me out of sheer boredom.
Partitioning the code, testing it in little pieces, assembling it in functional pieces are lost with these editors. Sure, you can do it but that comes with experience and I bet that you'd have to do the mappings and flows all over again while assembling it.
If it were left to an editor like vi or Emacs, cloning, copying and modifying large parts of code is easy with a bit of builtin functions or other Unix tools like sed, grep and bash shell. Notice that you are not forced to use the editors themselves if you want to? But with these new editors with their project folders and tracking, you'd have to hack it to figure out data structures and try figuring other means to edit the code. And it all goes awry in the next release of the editor.
The more you use the product editors, the more is the learning involved in relearning doing the same things because the menu options have changed. There is very little in applying what you've already learnt to be productive immediately.
That's partly the reason why people are pretty insane in sticking to Emacs or Vi. Compared to sheer frustration with a "smart" editor, these are plainly functional tools that are general purpose text editing applications that Just Do The Job.
You build on what you've already learnt with Emacs; the core functionality is always available in all the modes and you learn the mode specific behaviour as required. And being text oriented, you've got only yourself to blame for any "mysterious" bug that appears.....well, mostly.
Every new fangled editor comes with some new idea that makes it worthy in some respect but you seem to have to lose out a number of other features that makes you productive to use it.
I threw in the towel a long time.
Now, I just check out whether the same feature is available in Emacs in some form or the other.
No comments:
Post a Comment