Data Management

Poll: Do you prefer visual or textual development tools?

After observing that the Ruby on Rails community is dropping visual tools for command lines and scripts, Justin James is curious to learn what TechRepublic readers prefer: visual or textual tools.

One thing I noticed with my recent Ruby on Rails experiments is that the Rails community is embracing a "back to the old school" approach in terms of dumping visual tools in favor of command lines and scripts. For example, instead of using a database editor, you sculpt your schemas with code that edits the schema and gets run during deployments. There is a certain appeal to this, since it means that once you are skilled you no longer need to fight tools, but it does raise the bar a bit higher to achieve a basic level of competency. I definitely see the advantages, though I am not sure if it is the right choice for me (I need to do a real hands-on Rails project to know for sure). Which kind of tools work better for you?



Justin James is the Lead Architect for Conigent.


As I was building in netbeans, I saw who the existing visual tools get in the way. They're designed for a different way of thinking. To work in MVC, using the benefits that Rails brings to the table, we need to rethink what our visual tools. We need to rethink what they need to do. Netbeans tried to help that, but they were still a little too oriented to desktop apps.

Mark Miller
Mark Miller 1 Like

I've seen visual tools make me very productive, and other times get in the way big time. One lesson I learned is that visual tools are seductive. They make things appear easy, when in fact they could be screwing you over in terms of the design of what you're building. For static visual interfaces, visual tools are nice, because you can accurately place things where you want them on a screen. You don't have to wait for a compile step, though in Rails all you need do is a refresh on your browser to see what's going on. One thing that is really nice about an IDE is full-screen debugging. My (limited) experience with Rails is all you have is line debugging. Reading up a bit on it just now, you can also output to a log file. Also saw somebody say they preferred this to using a GUI, maybe because of the difficulties that using a GUI presents to designing a good dev. environment that works reliably cross-platform on a network. For server-end stuff sometimes logging is nice to have, but in my experience with using .Net for server-end stuff, I much preferred being able to step through my code as I was using an app., or calling a web service, and to be able to see the code around it, in context. As I tried to say in a comment on your last post on Ruby (it went into the black hole), I checked out Rails 5-1/2 years ago, then discovered Squeak and Seaside, and found that more to my taste. You get the advantage of a good OOP environment, an IDE (Squeak's built-in tools), and a web interface that you can inspect (as a collection of visual objects) and edit in real time (this can be turned off for deployment). At the time I looked at it, there were database APIs, but no schema framework like what Rails has. I've been out of that scene for 3 years, so I have no idea what they've done with it since then.

thoiness 1 Like

I want a visual representation in the same IDE I am programming in so I can visually architect what I am programmatically making (I don't care that it isn't a word). Also, if a visual tool negates the need for twenty command line entries, then putting your nerd tendencies away in favor of efficiency would be the correct choice. If you were to build a script that could be dropped in and configured to your liking using your code, would you still shun it? If not, perhaps it should be inspected whether the tools being offered implement best practices. If so, then you'd be a fool to duplicate the work already done for you. Perhaps these tools do not give you the full range of features you need, but as long as you can fall back to the underlying code and tweak to your needs, you may have saved yourself a few dozen lines of code. Done several times, the time savings is immeasurable. No, it should not be done in lieu of understanding the underlying code, and that is not what I am saying. Ask if a designer was given the option to code his way through a design, would he? Of course not, and many of us developers need to remember that we are many times called to be GUI designers, regardless of platform. With that in mind, the sterility of code does not give one the creative representation of ones work. You should always be vigilant of your aesthetics, as this is ultimately what your end user will see. I know I'm arguing two points (and one slightly off topic), but I am specifically on board with what Microsoft Visual tools has done, and believe that adopting those principles would assist even the best of developers if handled correctly.

Sterling chip Camden
Sterling chip Camden 1 Like

... is that it's easily version-controlled. It's also intelligible to anyone who needs to visually decode it. And once you've gained competency, text is more efficient for a full range of expression than any sort of visual gestures.

Editor's Picks