My previous post drew some attention, and in particular two comments I wish to relate to. I also wish to make a more fine-grained observation on visual editors.
One comment is by Peter Laursen, who rejected the generalization in my post, and another by wlad, who was harsher (but to the point), suggesting my post translated to “I don’t know it, therefore it sucks”.
I must have delivered the wrong message, since apparently people read my post as “don’t use visual editors, they are bad for you”, which is not what I intended to say, nor is it what I actually think. I took a very specific aspect of visual editors and commented on that. My comment should not extrapolate to “anything about visual editors is bad”.
I don’t think people should only be using the command line, and am not in the least interested in vi/emacs/eclipse/netbeans kind of wars. Of course everyone should be using whatever works best for them in terms of productivity and ease of use. And of course visual editors have great advantages over command line.
I’m sorry, it would be childish to assume otherwise, and extra-extra-extrapolation to suggest that was my hidden meaning.
Reflections on Peter’s comments
I can see that my post was harsh on visual editors, and agree one cannot just generalize on the dozens of editors available. I have used a few tools, and only to some extent, since I personally feel more comfortable with command line, and so I cannot possibly generalize on all tools. Nor are they all equal.
My point is, there is one de-facto tool, which is the command-line, for which there are no hidden assumptions. For which I don’t need to investigate whether a new connection is being opened, or if my query is somehow modified, or… I guess one can say “hey, my tool does nothing of the sort and acts just like the command line”. I’m not arguing. The visual editor is an additional layer between you and the server (the mysql command line client is in itself a layer, but a very transparent one, a very low level one), one which needs to take care of visual issues, such as display space, GUI components, widgets not running out of memory, responsiveness, good looks. These, one way or the other, add complexity to the discussion between yourself and your database.
One can say “it’s all configurable, there’s good documentation, you should know the tool you are using”. To some extent the same can be said of the command line client. Here is an observation of mine, please consider it as user input: many (I don’t know if most) users will not bother modifying the settings. Many will feel uncomfortable with turning checkboxes on and off, or modify thresholds. It is similar in essence to users not modifying the default InnoDB settings for the MySQL server, working with 8MB of buffer pool.
Anyway I agree my post was over-generalizing on the criticism of visual editors. Sorry for that. It should have been more specific on the advantages of command line.
Reflections on wlad’s comments
Since I wanted to concentrate on the command line issue, I didn’t elaborate on other stuff. For example, I didn’t specify on what type of trainings I ask students to close down their visual editors and open up a command line. Perhaps one could read as “from this moment on, and for the entire duration of the training, no one should be using visual editors, and anyone who does will find himself/herself out of the class”. I really didn’t think to elaborate on that, and even now – wow, it will take me ages to tell the full story. So I will be extra-brief:
I do make that suggestion. I do that when I start discussion of keys & execution plans. I don’t enforce that. I don’t mind which tool a developer uses. I actually tell them about various GUI tools they can use (naming the ones I see as most popular among other students).
But I also do not turn my training to “I’m going to do this session using the same tools you are using just because you are using them and you are in this class”.
There is a multi-layered reasoning for that:
- Many times there is a mixture of tools in the classroom. I can’t just pick up on one. The command line is the most common tool everyone can agree upon. I sometimes demonstrate on MySQL Workbench since many are familiar with it being an “official” GUI tool by the same company which makes the database.
- If I dwell on the particulars of a GUI tool, this consumes precious time that must be used to explain the EXPLAIN and talk about INDEX in depth. I just don’t have that time on training. The command line consumes very little time for me.
- I also don’t see that I should demonstrate using commercial products. I have nothing against commercial, and on occasion I buy commercial, and I certainly do not slight a commercial product just because it’s commercial, but I prefer to sponsor open source. If students have a commercial product, I don’t see this is my duty to walk them through the product.
- There are actually a few more reasons; operating systems, installations, assumptions on installed software, strict system administrators who would not installed anything I would tell them, projectors, font sizes, contrast of colors on projected image, … Believe me, I’ve been doing this for years, there are many factors to any small decision in class.
Last, I wish to relate to wlad’s “I don’t know it. It sucks” attribution to my post.
It is true there is not one single SQL GUI tool I know bottoms up. And the status is deteriorating, since I’ve long since decided my personal preference is command line. This makes me a non-expert, no-authority on any GUI tool. I actually present myself as such in class. This does not lower the quality of the training; it’s an aspect outside the training (for the reasons I mentioned above). I therefore agree to “I don’t know it”.
Now, I strongly believe I do not make the connection to “therefore it sucks”. I think that’s an exaggerated extrapolation of what I said. But it is such an overwhelming statement about myself for me to read, that I will keep it in mind. It’s a good thing to keep in mind, not only on GUI tools, but also in real life.
Being a Unix user, one of the reasons for using MySQL command line tools rather than GUIs is that with the CLi you can easily integrate other shell tools with MySQL input or output.
Admittedly, I am a proficient command line user, and therefore for me it is relatively easy to run a shell loop using input from the MySQL CLI tool and push back the output to MySQL, all in the same line.
Like this:
$ for T in $(mysql -B -N -e ‘show
tables from world’) ; do echo “CREATE TABLE world2.$T LIKE world.$T;” ; done | mysql -vv
I understand that someone used to a GUI may look at that as an abomination, but for me this is one of the simplest uses of the MySQL CLI integrated to shell tools. There are more complex, and more powerful things that can be done, and I feel very much satisfied with the command line for this reason. I would be lost in a GUI, which is in many cases very limiting for me.
When is a GUI helpful? When you have to create queries from a complex schema and you need an enhanced editor that suggests you table and column names efficiently. I use Aqua Data Studio for this reason only.
While I agree with you that the commandline is the ultimate tool, many times the extra layer(s) of abstraction help a developer get familiar with the MySQL environment and how queries actually work in MySQL, without having to learn a new tool also.
There is value in exposing a little bit of MySQL at a time.
I use a separate editor for when I’m creating stored procedures or events, long pieces of code that I likely will troubleshoot for a while before getting it right.
I favor the CLI, although I use Workbench side-by-side, but not for admin tasks.
For example, if you only enable root@localhost to have GRANT OPTION (or replace with the administrative permission of your choice), it’s not always easy or convenient to do port tunneling so you can use a GUI. OTH, the MySQL CLI utility will always be there on the server.
My $.02
G