[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About Visual Basic
After spending many years working on several large VB projects, I can
probably offer a reasonable comment.
The language is limited and very inconsistent. Switching to more
interesting languages (Java, C++) changed me from someone who programs
for a living to someone who loves to program.
Here is a run down on syntax/semantics:
Pseudo OO - you have objects, but no inheritance. Building a class is
done through the gui, so the programming overhead is a source of
resistance. I rarely found myself just whipping together a useful
little class.
Functions and Subs (procedures) are different concepts, a la Ada.
A large collection of semi-useful functions. There is no organization
to these functions like Java has. This means lots of browsing through
the hundreds of functions to see if there is already something that
does what you need.
Collections (more or less lists) and arrays are the standard collection
objects.
Strong type checking if you ask it to do so. Otherwise it is all
dynamic.
Pass by value is the default; pass by reference is an option.
Exception handling with gotos.
I believe you can still type line numbers and do gotos and gosubs like
in the old days. I've never seen it done, though.
Honestly, there is nothing about the language that I would recommend
except perhaps the more wordy syntax like Ada's vs. the non-programmer
terrifying symbol syntax of C and Java. So, please, don't use it as a
model for new languages.
But VB ain't just a language...
The editor is weak for text editing. Cut and paste are the fanciest
tools you have, but you have no choice, it's the VB environment or
nothing. On the other hand, the autocompletion, parameter tool tips,
and integration with the debugger are second to none.
It can be both interpreted and compiled. You want a quick program, just
type and hit "play." You want a "real" program, turn on strong typing
and compile to native code with optimizations. There are no exclusive
restrictions for either mode. Compiled code can be just as dynamic.
Sadly, all the details about linking and compiling are hidden away in
menus. It takes several minutes of pulldowns and list boxes before you
know how your program is interacting with the outside world.
Building gui's is a dream. Events, properties, and methods of widgets
are just a mouse click away. Unfortunately they are always just a mouse
click away. You cannot change several things about a gui without
clicking on objects and scrolling through property lists. Trying to
change the tab order in a window is the ultimate exercise in patience.
There are quite possibly 50 properties per widget, so there is
absolutely no way to understand the default state of your gui in a
single eyeful.
It works really really well with Windows. You want a database app
integrating with SQL server, give me five minutes. You want a web front
end, give me another five. Without any extra infrastructure at all, I
can set breakpoints in a backend VB dll for a web server. With a little
more work, you can debug SQL stored procedures. Interfacing with Office
apps is trivial - so easy, in fact, that you have to go OUT of your way
to not integrate with them. If you are working with the average
business customer, this is the world they live in and having a tool
that works with them can save quite a bit of frustration.
And most importantly, it does work. In all the projects I was on,
entire small and medium sized companies were relying on good sized VB
apps. Computers are computers and all these projects had their issues,
but the proof was in the pudding.
sean levin
On Tuesday, March 11, 2003, at 11:47 AM, McLagan, Doug wrote:
> the VB language is a mess, but indeed the IDE is addictive because of
> the
> GUI and the debugger. another nice feature of the VB environment is
> the way
> you can combine user-defined types and the "intellisense" facility in
> order
> to have quick keyboard access to many of your variables. here's a
> made-up
> example to illustrate the technique:
>
> ======================
>
> ' in the declarations section
>
> Type udtOfficials 'user-defined type
> a_President As String
> b_VicePresident As String
> c_SpeakerOfTheHouse As String
> d_SecretaryOfState As String
> e_SecretaryOfDefense As String
> f_SecretaryOfTheTreasury As String
> End Type
>
> Dim us As udtOfficials 'an instance of the udt
>
> Public Sub Officials()
>
> us.a_President = "Bush"
> us.b_VicePresident = "Cheney"
> us.c_SpeakerOfTheHouse = "Hastert"
> us.d_SecretaryOfState = "Powell"
> us.e_SecretaryOfDefense = "Rumsfeld"
> us.f_SecretaryOfTheTreasury = "Snow"
>
> End Sub
>
> ======================
>
> after you define udtOfficials and us, when you start typing the
> subroutine
> Officials, all you have to type is "us." and the system shows you a
> list of
> the members of the type, in this case from a_President through
> f_SecretaryOfTheTreasury. then you only have to type the first letter
> of
> your selection and hit the tab key and it completes the variable name
> automatically. this way you can use long, descriptive variable names
> without having to remember them or type them out each time. [if memory
> serves, i learned this trick from francesco balena's book.]
>
>
> -----Original Message-----
> From: Guillaume Marceau [mailto:gmarceau@cs.brown.edu]
> Sent: Tuesday, March 11, 2003 10:02 AM
> To: ll1-discuss@ai.mit.edu
> Subject: About Visual Basic [Was: Industry versus academia]
>
>
> 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
>
>
= = == === ===== ======== =============
NAME: Sean Alan Levin
EMAIL: slevin@alum.mit.edu
HOMEPAGE: http://homepage.mac.com/seanlevin
PHONE: 212.995.1913(h) 646.209.0720(m)
BODY: 11 Waverly Place #4F, New York, NY 10003