"I used to do storyboards right in the VB6 IDE asking the business guys what they wanted, 'so you need a form, with a list box and what should be in the list box, and when you clicked ok, now what...' And on it went. In a couple of days to a week, we basically had the front end of the application prototyped. Since it was back in the 'two tier' days all we had to do was hook it up to the database. And if we got really 'fancy', (or had the luxury), we added a third tier of business logic written out as VB6 classes, not in the stored procs, and after a bunch of testing, report writing, etc., boom! off it goes into production."

I hate Dreamweaver's design mode. Sure, only writing straight HTML/CSS/JavaScript over the many years has arguably taken more effort. I had to learn the "complexities" of my environment, that the author bemoans, such as browser bugs (found a new one that's IE7-exclusive the other day), but now I can recognize and solve browser bugs almost instantly and can build pages blind. As a result, the finished product is always of the highest quality and very robust.

And you're happy with it?

The existence of browser bugs? It's a necessary evil derived from consumer choice in browsers. No different from different desktop platforms. Unless all browsers standardize over one rendering engine (rather than a list of standards), we'll be dealing with cross-browser compatibility for a long time.

He does have a point about the size of frameworks - I decided about 6 months back that I wanted to get onto the iPhone bandwagon, so I decided to write a Mac app to get my feet wet - I could use the RubyCocoa envrionment to continue using Ruby, whilst learning the Cocoa API. Like Windows, MacOSX has a huge API, and each time you want to do a different task - networking, multilanguage support, undo/redo, working with bitmaps, scrolling, file support, etc etc etc, you have to stop programming, and look it all up. Sometimes you may even be sucked into having to read a 300 page document, although that is thankfully quite rare once you are no longer a beginner on the system. But then, each time that I do one of these things, I'm always thankful for the framework's existance, because I can't help but be aware of the fact that it is saving me probably months of work to create my own system.

Maybe his problem is that he is underestimating the size of the problems that the different systems are solving under the hood. Like, he talks about VB6 apps, from memory those don't scale so well if you have more than a handful of users using the app at the same time (I may be wrong about this, it's just what I seem to remember from that time - I wasn't actively working on those types of app at the time). Much of the complexity of today's systems is designed to permit you to handle scaling to hundreds/thousands/millions of users, with correspondingly huge amounts of data being handled.

A lot of biz apps like mine have forms with upwards of a 100 fields ( ya i know, but those are the requirements ), creating and maintaining that is just a whole lot easier using the drag and drop method instead of handcoding html ( at least for me ).

Efficiency in a small business app just doesn't matter. What bugs him, AFAICT, is that it's harder to throw together an app for a few users that solves some pain they have. VB6 is possibly the best environment for doing this ever, so I see where he's coming from.

So rails is more efficient, written in a vastly superior language, more conveniently hooked to the DB, and more scalable than VB6. But! Designing a UI is still basically manual labor with it, labor he used to be able to toss off with ease in VB6.

(Also, you don't need to be a "full-on db wonk" to write a simple stored procedure.)

The open-source descendant of Foxpro is Dabo: http://www.dabodev.com

As easy as anything MS but with a real programming language (Python).

Thank you! This 2008, why can't i get a platform independent way of quickly and easily coding up a GUI app like I could in VB4 in '95?

Fortunately getopt and so on haven't gone anywhere, they're still just as usable as they were.

I was just trying to show where he was coming from.

There was definitely that, too, but I'm much less sympathetic to that point. The .net libraries, like java before them, are gratuitously baroque.

In many domains, creating reports is the primary purpose of the app. And it really is painful in html, even for someone who knows it well. Trying to fit these apps into a dumb-client browser really is nontrivial with today's web frameworks.

The use case he cited really is a problem for HTML: designing the interface in front of a user in real time. Maybe using DreamWeaver, but not sure that's the same.

This seems to be exactly the shortcoming that balsamiq is addressing.

Not my experience. I would second his proposition that VB6 was great at what it was doing. It just worked.

Also, since you are not depending on one vendor, you can use the same tools for a longer time -- no need to change to the latest visual studio, for example. So, UNIX is complex, but change is more incremental than when using Windows/Mac OS X SDKs.

I think that one of his points. The UI was much easier.

We started to have all the customers requesting web applications. It was our specialty but in many cases the web applications were not justified. But the customers insisted. Writing web applications was way more complex than writing regular client server applications.

In web applications, you have HTML + CSS + Javascript for the view. While AJAX can talk to databases, it's slow for parsing out data that would be better handled in a faster interpreter. Thus, you have the "controller," or at least what is called a controller in webland, as a code generator for HTML and sometimes even javascript. Then, you have to interface with the database already, so you have to make the decision whether to have a database specialist, or just to treat it like a dumb store and do all of your business logic next to your controller. This is where we see the wonderful JDO, EJB, Hibernate, Activerecord, etc.

Rails makes it less painful, so long as you don't have a legacy database.

For large applications, the overhead is negligible. however, small and medium business-hosted web applications are still more difficult than the old client-server model.

And Access is easier yet. We still haven't come close to that with web apps.

I suppose he laments the old days when he used to reinvent the wheel ...

Yes, and: trying to figure out what the documentation means, etc.

Libary documentation tends to be not very good, and libraries themselves are not designed to be easy to learn. I'll illustrate this using Python's SimpleXMLRPCServer, not because it's particularly bad, but because I've been using it recently (It's at http://docs.python.org/library/simplexmlrpcserver.html )

1. Naming conventions.

The name of the module is SimpleXMLRPCServer not simplexmlrpcserver; most Python modules use the convention of the module name being in a lowercase, but this one differs -- Python should standardise.

Similarly the name of the class is SimpleXMLRPCServer, beginning with a capital -- but some python classes don't begin with a capital.

Similarly the naming conventions of methods and parameters should be standardised -- either use underline_separated or camelCase but choose one and stick to it. It's just irritating if there's a parameter called logRequests, and another called allow_none.

2. Documentation not complete

To quote the documentation: "If logRequests is true (the default), requests will be logged; setting this parameter to false will turn off logging."

Er, where are they logged? It doesn't say. Sure, I could read the fucking code and work it out but I SHOULDN'T HAVE TO. It probably puts it in a file somewhere, but for all the doumcnetation says it could build a factory of nanomachines on the surface of the moon and write the log file there in big 6 meter high letters.

3. interface of library too complicated

A library should be a black box that can be potentially big, exposing a small interface to the outside world. That way, by learning a small, simple interface, you get access to lots of functionality.

It's quite simple to register a function with the xmlrpc server:

   def myFunction(aString):
      return "x" + aString = "x"

   server = SimpleXMLRPCServer(("localhost", 8000))
   server.register_function(myFunction, "myFunction")

But there also a way of registering as functions all (or some) of the methods of an instance of a class, using the call register_instance(). This is more compex than it needs to be and figurung out how to use this function is impossible (for me at least) without extensive examples. However, this function is superfluous -- if I want to expose all the methods of an object as remotely-callable procedures, I can do it myself by making iterated calls to register_function().

Once the larger community decides what it wants, and how to do it, all the complexity disappears inside the machinery. Writing web-apps doesn't require low-level network wrangling, because the choice of TCP/IP etc. has been made: you simply use it as it is given. The higher levels of web-apps still present more complexity than they ought, though -- so we still haven't made enough limiting choices.

Overall though, the prognosis would seem bad: It is the essence of software to be parameterisable, to be changable. So it will always be able to produce choices at a greater rate than they can be well-chosen.

"Simple things should be simple" is the author's point. I agree.