Re: hosers-talk: Duh.

["Jon Stewart" <stew1@xxxxxxxxxxx>]

> Personally I like C better than VB because it gives you infinitely more 
> control than other languages.  But, depending on the application, it makes 
> much more sense to use something like VB or perl.  I am dealing a lot with 
> VB and strings and integrating with C right now, and with the pattern 
> matching libraries that emulate Perl functionality, it is very powerful and 
> easy to use (for GUI's, I know about the HUGE memory and processor hits, 
> already - don't mention it!).  Even when using both VB and C functions, you 
> get the best of both worlds.  Making a GUI is so much easier in VB, and 
> when you interface with C for the real work, you get huge time-saving 
> advantages.  There are some pains because the size and type of variables 
> are different (VB booleans are 8 bits with 0 and -1 as false and true 
> respectively!), but on the whole it works quite well (as long as you don't 
> try to do anything ridiculously huge with VB).


My current "project" this summer is to develop a custom form in Outlook 
98/2000 that replaces a big paper form, which is general enough to cover 
everything we do at my company that only part of it is ever used by any 
one circumstance. So, I do a lot of showing and hiding, depending on user 
input, so the form shows only possible input options based upon previous 
input. 

All of this is done with VBScript, as Outlook doesn't get a full-fledged 
VBA environment.

It has been nothing but a constant source of pain and despair for me. Most
of the programmer's documentation is copied from all the other craptacular
Office apps without regard to its usefulness in Outlook. Want to use Tab
strips in Outlook? I can show you documentation how to do it. I can show
pages in a book (_Building Applications with MS Outlook 98_) about how to
do it. And then I can show you a "knowledge base article" on MS' website
that tells you, "oh, yeah, you can't do that in Outlook".

Today, having gotten past many of the glitches along the way, having had a 
few days of good productivity, Outlook just started crashing and crashing 
and crashing. And when it didn't crash -- remember, it shouldn't crash; 
VBScript is in a sandbox, and I'm just twiddling bits on GUI objects which 
already exist anyway; I ain't managing my own memory or anything -- it 
would wipe out GUI widgets when I would save the form, specifically the 
controls of a multipage which was inside another multipage. What have I 
guessed superstitiously from this? Multipages shouldn't be embedded inside 
other multipages, because Outlook is too dumb to know how to save the 
state of controls more than one level "deep". 

All of which means that at least another day (probably two) has been lost 
due to a faulty programming environment. The nature of the shit I'm doing 
is fairly simple; I'm just doing a lot of it. But not an inordinate 
amount. And not only has it become intolerably slow on my old ThinkPad 
166 (I wait minutes to launch it), it's pushed the limits of Outlook so 
far that it just causes irrational behavior. And it's not just that I have 
a shitty old system that can't cope. I get the same thing from Outlook 
2000 running on Windows 2000 running on a nice Dell tower with 256MB RAM.

At this point in time, I think the argument that VB increases productivity 
is specious. Sure, I get decent GUI layout tools (they're not great), but 
I'm not guaranteed that things will work. If I'd started working in Java 
in June, simply coding everything, I'd probably be farther along than I am 
now.

Another fault I find with VBScript, ignoring the cruftiness of it all and 
lack of coherence amongst its control structures, is that, for a scripting 
language, it lacks any kind of programmatic feature that smacks of 
dynamicity. I mean, hell, you can call functions by pointer in C, which is 
decidely not a scripting language. Do I get any polymorphism? No. Can I 
declare my own classes? No. Are functions/subroutines treated as first 
class objects? No. So already I am wasting code, and when I counteract it 
by making my subroutines small and as reusable as possible, I get hit hard 
with the overhead from the call-stack.

If you want GUI layout tools, use fucking NeXTStep/OpenStep/Cocoa and 
Project Builder. That way you'll get code generated in standard 
languages and your shit will actually work.

I feel like taking VBScript off my resume.


> Most of this argument is from a business and cost-savings standpoint to get 
> the best work for the least time/money.  But I think it is sound.  Have you 
> tried using the BSTRING libraries?  I have not used them very often, but 
> they seem simple and powerful to use.  They emulate BASIC style strings and 
> the libraries are apparently written in assembly for maximum speed.  I 
> don't know how they handle NULL charactors, though.  Why are you putting a 
> NULL character into a string, if I may ask?


BASIC style strings in *C*? That just sounds like a bad idea.

As for null characters, by convention, all strings in C are terminated 
with a null character. At least, they are if you want to use any of the 
stdlib functions. Thus it's very important if I can get a C style string 
out of my string class (in C++) as quickly and painlessly as possible.

Btw, I am slowly putting some generic classes on my homepage. A simple 
Vector class is up there already. My Deque class will be up within a day 
or two, and then my String class. If you can't use the STL, for whatever 
reason, feel free to plunder and adapt.

_Design Patterns_ is worthy of the praise it receives.



Jon
-- 
Jon Stewart
stew1@xxxxxxxxxxx

"Survey says: it was a bad idea in the first place."

	-- The Dismemberment Plan