Small time coding [Was: Re: About Visual Basic [Was: Industry versus academia]]

[Michael Vanier <address@hidden>]

Very nice discussion of VB.  I've often wondered why VB had such mindshare
among certain groups of programmers.  Another point often brought up in
support of VB (and related to some of your points) is that VB was one of
the first environments to supply a component-like model where custom
self-contained GUI controls could be created and then distributed to
others.  Perhaps you'd like to comment on that?

BTW some lisp and scheme debuggers (MIT scheme's comes to mind) have many
of the interactive features you have in mind (like starting a repl at any
point in the stack).

OK, now here comes a rant.

I really like your expression "small-time coding - the coding which does
not require any knowledge of algorithms and design".  It crystallizes a
concept that has been bugging me for a long time.  The notion of "end-user
programming" is talked about a lot in educational circles.  The implication
is that such coding can be done by "mere mortals" and not "coding gods",
which implies (but rarely states outright) that it requires neither a deep
knowledge of algorithms or of program design (you know, those things that
make programming *actually interesting* ;-)).  I think there is a lot of
misunderstanding on this topic.  The primary misunderstanding is that the
reason existing programming languages and environments are too hard for
non-coders to learn is that they have complicated text-based syntaxes
instead of being GUI-based.  Even though there is some truth to this (at
the entry level at least), I think it misses the big picture completely.
Even if you had the most intuitive GUI-based programming language
(something like LabView comes to mind), you *still* have to deal with
algorithms and design.  Even though most "small-time coders" probably
aren't going to initially create anything that requires sophisticated
algorithms or deep understanding of design abstractions, sooner or later
the programs they develop will scale up to the point where it will make a
difference, and at that point, all the GUIs in the world won't help them.
There is simply no substitute for actually understanding the art and
science of programming if you want to be a programmer, just like you can't
design cars if you don't know something about mechanical and electrical
engineering.  The implication of the end-user programming advocates often
appears to be that learning to program should be like learning to speak a
new language, which is just wrong.  The linguistic aspects of the problem
are just the tip of the iceberg; all the really difficult stuff comes
later.

The reason I think so many of us are so interested in programming languages
is that we want languages that make it easier to do the hard stuff:
designing complex algorithms and designing, extending and maintaining
complex programs.  GUI-based programming environments aren't going to solve
these problems.  In fact, for algorithms at least I would argue that
text-based languages are superior. 

Thanks, I feel better.

Mike


> From: Guillaume Marceau <gmarceau@cs.brown.edu>
> Date: 11 Mar 2003 10:01:54 -0500
> 
> On Fri, 2003-02-21 at 17:33, Lauri Alanko wrote:
> > On Fri, Feb 21, 2003 at 05:11:48PM +0000, DLWeinreb@attbi.com wrote:
> > > The big world out there has a WHOLE LOT more people who are really
> > > not qualified to go near C++, Java, C#, and so on, but can get
> > > by in Visual Basic.
> > 
> > Exactly what is it in Visual Basic, then, that makes it more suitable
> > for these people? Clearly this property, whatever it is, is something
> > that a lightweight language should have. Or is it something that's
> > inherently incompatible with the features we want for "serious
> > programming"?
> 
> 
> Good question.
> 
> The short answer is : best-of-the-show debuger and GUIs as a code
> abstraction mecanism. The long answer follows.
> 
> 
> 
> 
> The idea of a monopolistic language strong-handedly controlled by a
> single company is distasteful to the community here. As a result, we
> know very little about Visual Basic.
> 
> Beside, there are many good reason to be unimpressed with Vb. First, its
> syntax is wildly irregular, marked by Vb's long history of short-sighted
> evolutionary steps ("Open "MyFile.txt" For Input As #1"). Many of its
> features appear to have been designed by a marketing department and are
> often unorthogonal with each other (for the longest time, libraries
> classes could have subtyping relationships, but not the user-defined
> classes). Plus, Microsoft takes as little care in the correctness of the
> implementation as for its other office products. That means Visual Basic
> and its libraries crash as often as Excel or Word does. Nasty.
> 
> 
> There are good reasons for its success though. By far the most important
> is Vb's debugger. Vb wins beginner programmers with its debugger, the
> best by far, for miles around.
> 
> Upon opening Vb, its interface present a full featured REPL. It can do
> everything a lisp-style REPL can do: it can evaluate expression using
> precisely the same syntax as the compiled language. It can also define
> new variables, new functions and new classes on the fly. More
> importantly, it works in pair with the debugger. When stopped on a
> breakpoint, the REPL can access and modify the any local variables on
> the stack frame (gdb-style), move the execution point around to another
> line and call functions and object methods (something gdb cannot do
> consistently).
> 
> It gets better. The Vb interface can incorporate code changes on the
> fly. It does it quickly, consistently and is very permissive of the kind
> of changes it can handle. There are merely two constraints: is it not
> allowed to remove or change a function's signature, and it is not
> allowed to remove a variable currently on the stack frame (removing any
> other variable is fine). Even changes to the current function are
> accepted. It is as flexible as it could be.
> 
> 
> Other, lesser reasons why Vb is doing well:  it keyword completion and
> its context sensitive library documentation search takes advantage of
> type label on the variables to restrict the list of matches to what is
> relevant. It is simple but it works - works really well in fact.
> 
> Its window and dialog box editor is also conviniently comingled with the
> language. Dialog element can be bound directly to names, and functions
> can be bound directly to events, which saves having to write insipid
> code or the form :
> 
>      Button button = new Button("Button", 50, 100);
>      button.addActionListener(new ActionListener() { 
>         public void actionPerformed(ActionEvent e) { ... }
>      });
> 
> or of the form :
> 
>     (make-object button%
>               (drscheme:unit:make-bitmap
>                   (string-constant check-syntax)
>                   (build-path (collection-path "icons") "syncheck.bmp"))
>               (get-button-panel)
>               (lambda (button evt) (syncheck:button-callback)))
> 
> 
> I am aware of one other feature unique to Vb. Vb has a notion of
> coding-time execution, called "custom controls". This allows the (rather
> rare) competent Vb programmer to write convenient GUIs for the
> non-professional Vb programmer. These GUI are typically used to
> pre-select some of the constant argument to class constructors. For
> instance, in the example above, the bitmap argument the button% class
> constructor is a constant. In Vb, a competent Vb programmer could code a
> bitmapped button control, which would then let the beginner coder select
> its bitmap file using a file-open dialog box. It is at the same time
> convenient and a simple way to ensure that "syncheck.bmp" is not
> misspelled.
> 
> I have participated in the construction of a multimedia database
> browser. The application was to be entertaining and visually appealing.
> The coders created a spreadsheet control which was then given to
> artists. The artists could selected the fonts and the colors using
> non-threatening GUIs prepared for them. The more adventurous artists
> also wrote some simple Vb code to animate highlights and such.
> 
> This is the realization of Vb : with a solid debugger and the
> possibility to abstract monkey code into GUIs, Vb made small-time
> coding - the coding which does not require any knowledge of algorithms
> and design - accessible to people with no or little programming
> training.
> 
> 
> If somebody is aware of a project to bring these features into a
> professional language (mainstream or not), I would love to know.
> 
> 
> Disclaimer: I used to sell my Vb programs in highschool. However, I have
> not touched any Vb code since at least 1996. I switched to C, then to
> C++, Java, Ocaml and then to Plt Scheme, and never went back.
> 
> 
> -- 
>   "In Google non est, ergo non est." 
> 
> - Guillaume
> 
>