Slashdot Mirror

C++ Colin? Is that you?

http://www.hacknot.info/hacknot/action/showEntry?eid=81

even though GUI builders are evil

I'd just like to point out that the article you linked is crap. Or, more precisely, it's written by a developer who's apparently never used a GUI design tool. Most of his "problems" boil down to, "You're still going to have to write your own code anyway, regardless of what you do in the GUI builder," which I answer with a great big, "Duh!" In fact, most of his signs of GUI builder use are really just signs that you're dealing with a lazy developer, a non-developer who bought into the idea that he could just drag 'n drop his way to freedom, or a developer (like the author) who's not very familiar with the GUI builder in question and/or has pre-judged the GUI builder tool before even trying to use it.

Granted, 99% of my GUI builder experience has been with Microsoft Visual Studio which is actually very good, so maybe his concerns are valid for other tools. Of his list of signs, Visual Studio makes it trivial to handle the first three (layout management, variable names, and localization), it's possible to fix the fourth one by writing custom controls, and there's nothing wrong with the fifth one (common boiler plate code) though with the use of parital classes in .NET 2.0 Visual Studio does its best to hide that from the developer.

Most people don't seem to think about refactoring their GUIs; already there's one post here telling you not to code your GUIs but use the pathetic drawing tools to create them, even though GUI builders are evil, and one of the very reasons they are evil is they preclude even the simplest refactorings. The bulk of programmers seem to be happy about that.

My experience is that there really isn't anything special about GUI refactoring vs. any other kind of refactoring, at least in the languages I use. That may be a factor; dynamic languages like Python or Ruby seem to be a lot easier to implement "Don't Repeat Yourself" in. You may find you'd be better off switching to one of them, especially if you're trying to work in Java, with seems to elevate repeating yourself to a moral imperative.

But beyond that, I don't really see what's special about GUIs.

The other thing is that when you are first learning an environment, you need to cut yourself some slack. No matter what you do, your first few cuts will suck as you are getting your bearings. I'm all about refactoring and testing, but when I recently picked up Django, I didn't worry about either at all in the first week. Now I have to go back and re-examine everything I did and get the testing going for it, but I don't see any practical way to avoid it; testing my initial garbage would just increase the investment into code that I'm basically throwing away anyhow. (As I have a lot of web experience, that's probably faster than usual; any other framework type would probably take me longer.) You may find that you have built "one to throw away"; consider actually doing so.

Submitter has a bad case of Wikiphilia.

I wonder if it's related to Morgellons?

.... let me post two opposing sides of the swing vs swt debate:

Swt is crap

and

Swing is crap

It's their use of SWT that prevents it from being cross-platform. It's SWT that doesn't live up to the hype.

They could have choosen Swing and it'd work everywhere, right now. But since they chose SWT, which relies on JNI bridges to call native OS UI libraries, they have to wait for SWT builds for 10.4.

I really, really don't understand why you'd write a Java program with SWT, unless you found a serious problem with Swing and were really only looking to support Windows. In which case, why use Java at all? You might as well write in VisualC++ or C# ( or Cocoa/Objective-C ) if you're going to tie yourself closely to native code.

Here's a great rant on SWT.

Personally, I've never used SWT, but... it just doesn't sound like a great idea.

1. Be careful about how you name things. If you are writing .NET code, there are established guidelines. If not, you can use a general guide to naming things or, chances are your platform documentation has its own guidelines already. Don't waste your time trying to invent new ones, you'll simply confuse your users.
2. Provide lots of examples.
3. Use your own SDK! The best way to do so is to write unit tests. You can then most likely use a lot of that source code directly in examples, thus ensuring your examples always work. (minus the asserts and 'failure tests', unless you want to prove a point, etc.)
4. If u kant rite professional english and complete sentences, hire someone who can.
5. If possible, segment the reference for different classes of users: beginners who have never used your API and experienced users who are trying to squeeze it for what it is worth.
6. Use appropriate tools (NDoc, Doxygen, RoboHelp, etc.), especially if you can create several output flavours (PDF, CHM, HTML, etc.) from a single input. Bonus points if it's part of the source code itself (i.e. as special comments) as there is less chance of a synchronization error.
7. Hyperlink as much as possible. This will make easier for the user to discover features.
8. Make it easy for your users to report documentation bugs. A Send feedback on this topic link at the bottom of each topic (like a lot of MSDN) is a great way to make sure documentation errors don't stay hidden too long, because incorrect documentation is worse than no documentation at all!
9. Beware of pointless documentation such as: "The 'EnableJrtOutput' property allows you to enable the output of JRT." Explain what JRT is and why people would care to turn it on or off.
10. Your documentation is as important as your code. It should thus be QA'ed (reviewed) as intently as the rest of your product. Don't put off documentation to the last minute.

Obligatory linkwhoring: The Skeptical Software Development Manifesto

It doesn't actually sit opposite any methodology, it simply extends the basic principles of skeptical inquiry into software engineering. It's anti-hype more than anything else.

http://www.hacknot.info/servlet/HS?cmd=sen&eid =1