I like to eat cereal in the morning. What do you think?
–
JobFeb 7 '11 at 18:31

3

Does it mean that someone writing code in Notepad is a good programmer? After all that person is writing from scratch .. :-P
–
ZerotoinfinityFeb 8 '11 at 20:26

1

@Zerotoinfinite notepad is a great tool if you don't have anything else except for Word. Of course, butterflies can be used but they are not always available. And Emacs raises a biological exception called 'Emacs Pinky' which you don't want at all.
–
райтфолдFeb 8 '11 at 23:22

17 Answers
17

Honestly, it's mostly about the project scope. As many have mentioned here, using visual tools does not make you any less of a programmer and can be a time saver. However, you have to be able to trust your tools and be aware of the code generated by your actions.

Are methods automatically generated? Is the positioning used absolute or relative? I've used Flex Builder and some Silverlight tools, as well as some good old Swing generators and the behavior of such tools can vary widely. While those tools can provide design speed and instant visual feedback of what your application can look like, the code can take a big maintainability hit, especially if you do not know the tools inside and out.

Therefore, both approaches have some merit:

Visual Assisted Approach

Instant visual feedback.

Very fast to create a UI.

Harder to review and maintain.

Modifications to the UI can have
surprising consequences.

Some unused auto-generated methods
may be left behind.

Coded by hand

Slower development.

Easier to maintain (given good
code!).

You get exactly what you coded: no
leftover functions, no undocumented
features.

The first method is very useful for fast-moving projects, where you want to have a quick visual feedback. The second method requires more discipline, but is more useful for critical applications that might need to be maintained for a long time.

Of course, take it all with a grain of salt. If you're used to code an interface by hand, you'll be faster and more efficient going that way. On the other hand, if you (and your team) know about all the artefacts generated by a visual editor, then maintainability might not be an issue for you.

I don't think I'm understand what you mean by drag and drop. I don't use .NET, but I do use Qt for user interfaces, and use Qt Creator for creating the layout of widgets.

I don't think this makes me less of a programmer, as the actual logic of the program is all done elsewhere, and I just use the Qt Creator to make things line up in a way which is:

much less time consuming

far easier to adapt to user requirements; and

generally easier to understand than if I built all the layouts up manually in C++.

I'm not "ashamed" of this. I don't see why anyone would be. My applications have a good deal of logic and functionality around, but it's not all about the user interface. Surely this is the case for most people? Interfaces provide a means to use functionality, they are not the functionality in and of themselves.

Dragging visual images around is just one of many development tools to make your life easier -- same as a debugger, or something that auto-generates getter and setter functions -- and there's nothing inherently wrong with that. It's like using a calculator. If you rely on it too much as a kid then you might not ever get good at your times tables. However, once you are proficient with the methods, you still might not have the desire to multiple 634*592 by hand. Yes, you can still use the methods you were taught in grade school, but unless there's a compelling reason to practice it, it's not relevant to the problem at hand, and it's faster to use the tools.

On the other hand, if you still reach for the calculator when multiplying 6*91 then you probably should think more about getting your own practice in. With practice, there are a lot of blocks of code that you will know by heart and should not need to drag and drop them.

You are programming, it's just that you have less control over the generated code, which is usually why you would prefer hand coding. You could have the best of both worlds: use drag & drop to make a quick prototype, then fine-tune it by hand.

Unless you are encoding 1 and 0 directly on the hardware you are using some level of abstraction. This is a good thing as it makes us more productive. Assemblers lets us write code faster than manually placing 0 and 1's. Early languages like FORTRAN and C lets us be even more abstract. Modern languages like C#, JAVA, and so on allow us to be even more productive. Tools like Visual Studio and Qt Creator allows us to automate some of the more boring and mundane portions of our applications. Allowing us to concentrate on the more important logic in our application.

Could you gain a small amount of speed by hand coding these sections, yes you could, and if you used a lower level language like C you make it even faster, but someone with the knowledge and time could make it even faster if they wrote in assembler or even directly in machine language.

Does not knowing how to write in Assembler make you less of a programmer. In some cases it does, but for most of us it does not in my opinion matter. As an analogy, how many engineers use slide rules instead of calculators?

I don't think it's possible to build anything more than very trivial programs with easy-to-use drag-an'-drop, or very highly constrained programs with complex drag-an'-drop (usually domain specific, more complex and buggier than Forms Designer).

I personally really like drag-an'-drop for things like UI design, as it takes away a lot of the tedium of code that creates a control, sets properties, sets position, lather, rinse, repeat, blah blah... and it lets me get to the interesting algorithms and problem solving faster (once the UI is out of the way). Custom drag-an'-drop builders that try to do fancy workflow creation and business logic and then allow complex code-like expressions for runtime evaluation I'm a little more hesitant about. They tend to be more restrictive in what can actually be built and they still can't do everything they need to do. In those cases I'd much rather just write the code by hand.

+1. This sums it up IMO. The only time you should be using Drag-n-Drop stuff is for 1) UI work and 2) If you're doing an extremely trivial demo app. Anywhere else it's more of a hassle than a benefit.
–
Wayne MApr 20 '11 at 12:29

1

@Wayne and poster, atleast for me the code generated by ANY UI-drag-drop tool is too ugly to use in production... And it's never UI tailored for resizing etc!
–
MaxApr 20 '11 at 21:33

When I open Visual Studio for coding, yes... I call myself a "programmer" . But the story begins when I say I know the tool on which I am working. Specifically talking about Visual Studio, if I write the aspx page by my hand completely instead of dragging and dropping the tools from toolbox... than I won't be a good programmer because I am not fully optimizing my time.

You're still programming, just like I'm still cooking when I pop a frozen meal in the microwave. Just because it takes less skill doesn't make it invalid, but you also won't see me on the Food network touting how good my Lean Cuisine meals are.

If you drag & drop, you're letting the
editor to build code for you. You're
building an application that has no
proper code logic, correct?

In the beginning there was Frontpage. Dragging and dropping elements created many tables and nested tables. This is bad for maintenance. But, its also an outdated concept.

I drag simple controls on a web form
in .NET, but surely you cannot rely
100% on building an app that way?

IDE's are productivity tools. Its faster to drag and drop. If there's no need to write the code manually, then don't.

Today, Visual studio allows drag-drop of many elements without producing lots of trash code. Also today, Microsoft has invested quite a bit of time/money researching good defaults. In fact, there's a whole campaign around framework/tool usability entitled fall into the pit of success.

There is nothing wrong with using a DnD editor to design user interfaces. Considering you're designing a graphical interface being able to see how your interface looks and might be interacted with as you build just makes sense, and if you can't get the DnD editor to give you just the right look/behavior, you can always go into the generated code and fine tune.

Well, I will say this from the two development areas that I know well enough to comment on: WPF/Silverlight development. I almost never use drag 'n drop with any of these because I find that the code that it creates, particularly the XAML stuff makes all kind of crazy margins and assumptions about what you are trying to do. When you're creating a form or some type of screen in WPF/Silverlight, you want to make sure that your controls will be able to scale well when the user is resizing things. Sure, there are times when you want to define a margin, but you should do it on your terms, not the IDE's. When I was doing more stuff with Windows Forms, I definitely relied heavily on the drag 'n drop because it was just so easy to bind to datasets that way, but you wound up having to undo like 1/3 of the code that was generated - which got very ugly.

Nowadays with WPF and MVVM its a lot cleaner and lends itself to hand-coding applications, which I think in the long run also separates the real developers from those that can drop a form on the window and create a simple crud app. Anyway, I think its good to write code rather than just drop stuff on the screen because it allows you to really create efficient code and not just bloated pieces of code. I am also really digging deep into the ASP.NET MVC Framework for an upcoming project I need to do and I am happy that I got away from draggy droppy, because that will certainly NOT help you with the MVC framework!

I look at it in terms of tools and results. Each method, drag-and-drop or hand-coding, is just a tool. It's my job to determine per task which tool gives me better results? (Note: desired results per task will vary greatly.)

Sometimes I may want to hand-code because my desired result is that I completely understand and control the code. Or that I have small details that need to calibrated in a precise manner.

Sometimes I may want to use drag-and-drop techniques because my desired result is that I want to produce a large number of fast results.

In practice, I use both. I'll split a task into a series of tasks, and for a particular subtask I'll determine whether hand-coding or drag-and-dropping is more preferable. Then use the best tool for the task. Sometimes hand-coding is picked because I'm already in hand-coding mode. If one particular task requires one particular tool exclusively, there's not much to fret about.

"Surely that means you're not really programming. You're building an application that has no proper code logic, correct?"
As far as DnD not really being programming: I would probably in most cases technically agree with that classification. But in reality, if DnD or hand-coding can produce the same result, the naming doesn't mean anything.

(Also, with DnD you're still building an application that has code logic; it's just that most of the details are being taken care of by a program. In a similar way to how when we write in high level languages, we're still writing for a machine somewhere, but most (or all) of the details of machine code are being taken care of for us.)

Finally, the amount or type of work put into a creation is not an indicator to the quality of the creation. For me personally, hand-coding feels like "real" work or "real" programming because it takes more time, thought, or other resources from me. But at the end of the day, my programming is judged mostly by my programs, not by my processes.

Do you have a nagging boss who spoke of timelines before he could say mama when he was born?

Most of us do.

Yup, you learn a lot if you have got all the time in the world to go figure things out for yourself. Now for the lesser mortals, who have timelines and family, and hopefully some personal priorities too, they'd prefer using some help.

Using only drag-n-drop is not programming but for stuff like UI design, they are a God send.

And frankly, even if I take your argument and say that I am a sloppy programmer if I use drag-n-drop what greatness is achieved by learning MFC or WPF? Why not expend energy on optimizing or fine-tuning the application logic and let the basics be taken care of?

If you've got the relevant programming knowledge why should care whether it is from drag and drop or pure coding. If you can make sure the code which is generated is not faulty and it is correct according to the core programming concepts and it supports the programming logic you are going to develop I hardly see any big disadvantage than not. In fact it will make the life of the programmer much more easier, provided that you are a good programmer.

If you are a newbie to the discipline of programming then you have a problem with drag and drop. What you will know about the specific language at the end of the day would not be the correct way it should be executed and optimized. But if you are an experienced programmer and if you can make a judgement on the code which is automatically created, drag and drop will definitely add on to your efficiency. That is why I guess there are drag drop supported tools available, to develop applications fast, how strong the logic is, programmer's concern; because the tool will not be able to create the logic but support one.

For an example integration tools in business intelligence; they definitely are pure drag and drop tools as far as the logic is concerned. The programmer should definitely know what he/she is doing. It only saves the pain of writing code to do an integration. There will be minimum differences if you compare coding against dragging and dropping in this context. I believe coding is more error prone this way, as you will be trying to re invent the wheel throughout the span of a project and beyond.

With all the ideas and examples I would like to conclude saying, dragging and dropping is to make the work easy for experienced guys and be more productive. They are not the tools for people who start learning (but may have exceptions) programming, may be coding on the note pad will definitely be advantages for as person who is starting up. If you know your context correctly you definitely will be able to use dragging and dropping extremely productive.