

A Programmer's Dilemma - gaius
http://softwareindustrialization.com/AProgrammersDilemmaProductivityLost.aspx

======
thomasmallen
Big surprise. They guy's sick of programming because he never liked coding in
the first place. This is his ideal development model:

"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.

~~~
tyn
"I had to learn the "complexities" of my environment, that the author bemoans,
such as browser bugs"

And you're happy with it?

~~~
thomasmallen
Knowing what I'm doing, understanding all factors in my envoironment? Yep.

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.

------
pfedor
The article is interesting, but I can't help but think that large part of the
guy's problem is that he's not using Unix.

~~~
demallien
I thought he was being quite unfair towards systems today - I certainly don't
think a Rails app is any harder to get up and running than a VB6 app. The only
downside is that making forms/reports isn't as simple - but honestly, is
learning html really so hard?

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.

~~~
gaius
VB6 didn't _have_ to scale, you ran one instance of your app per user, and
worried about scalability on the back end (i.e. the database). People talk
about Rails scaling, that's the difference, notions of scalability have been
shifted a tier up.

~~~
demallien
As I said, I wasn't sure about the details :-) But as you seem to know a bit
about it, what was the standard database that was being used as the backend?
SQLServer? And were the db requests being generated by the app efficient? And
most importantly, considering the thrust of the article, was efficiency easy
to achieve? I'm thinking about this in terms of the skills needed by a single
programmer to be able to do anything useful - if you needed to be a full on DB
wonk to produce an effective VB6 app, then it wasn't really as simple as the
author was making out.

~~~
llimllib
SQLServer or FoxPro or Oracle, you wrote the db requests yourself (probably
just hooking up to stored procs, as he says) and you're totally missing the
point here.

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.)

~~~
kragen
Can't you write Rails templates with DreamWeaver? Is it a lot harder than
assembling dialog boxes in VB? I've basically never used DreamWeaver and I
haven't used VB since 1997, so I don't really know.

~~~
llimllib
heck if I know. MS also has a DnD-style form assembler for ASP.Net, I don't
know why he didn't/couldn't use that.

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

~~~
kragen
Oh, sure. I thought he was complaining more about the excessive complexity of
modern computing environments, though, the way that mainframe people used to
do around 1970, and the way minicomputer people used to do around 1980. Maybe
he should try programming an 8-bit AVR.

~~~
llimllib
> I thought he was complaining more about the excessive complexity of modern
> computing environments

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

------
huherto
This is my experience as a consultant.

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.

~~~
donw
How so?

~~~
ibsulon
1\. In simple applications, you can merge the view and controller on the
client and use the database and stored applications on the server side. Have
two people who know two languages, and you're done.

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.

~~~
huherto
Furthermore, keeping the state in a web application is harder. For example in
a desktop application you can open a dialog box and when you are finished you
get back to where you were. You can call the dialog box from several places
and you always get back to your previous state. It is like calling a
subroutine and then return vs doing a "goto" and then another "goto" to get
back. You end up with a lot of spaghetti code.

~~~
gaius
PG writes that having a good mechanism for state management was a significant
advantage for Viaweb over it's competition.

------
psyklic
The article's main point is just that languages have started including much
larger standard libraries. Larger libraries save time, but they make the
programmer's job more "searching for the right function" rather than "writing
functions."

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

~~~
cabalamat
> _Larger libraries save time, but they make the programmer's job more
> "searching for the right function" rather than "writing functions."_

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")
    

This is fine, and you can omit the 2nd argument to register_function() if you
wish; also fine.

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().

------
hxa7241
This is a dichotomy. Complexity is really many choices and detailed control.
The real barrier to simplicity is reaching a firm decision. You either have
flexibility or simplicity.

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.

------
tyn
"Simple things should be simple and complex things should be possible"

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

