Fog Creek Software
Discussion Board




Anti Visual Basic

In the spirit of recent discussions, why not let me know what you think about the opinions found at http://www.geocities.com/antivisualbasic/ ?

Frederik Slijkerman
Monday, April 15, 2002

Because I don't use Visual Basic.

Christopher Wells
Monday, April 15, 2002

These comparison are awlays so pathetic. If all things were equal, sure, Delphi may be better. But all things are not even remortely equals. There is a massive infrastructure around VB in the form of books, libraries, training, consultants, contractors, Microsoft, etc., etc., etc.

pb
Monday, April 15, 2002

VB was one of my entry-points into programming. After having a few years experience with HTML, I got a job as a technical writer. As a part of building our technical documents, I had to do some incredibly redundant stuff in Word. When I found out I could write macros to automate some of that stuff, I was ecstatic.

Then, after seeing some of the tools that I was writing in Word VBA, my boss asked me to write a utility that would convert some of our documents into an XML document with a very particular schema. 2000 lines of code later, I was done and I had a much improved understanding of programming.

Then they asked me to write another tool that would take the special XML document as input and spit out a perfectly formatted Word document. After another 1000 lines of code, I was finished with that project and was really enjoying myself.

Since then, I've completed a few other Visual Basic projects and several large-scale web projects in PHP. I've decided to go back to school to get a degree in software engineering.

I'm not crazy about the VB syntax. I've worked a little bit with Java and have read through a bit of C# code. I much prefer the C-style syntax of PHP, Java, and C#. But, there was no way for me to stumble into a project that involved any _more advanced_ languages than VB.

I doubt that I'll seek very many VB projects in the near future. But I see it more as a matter of personal preference. My company is at the tail end of developing a fairly large (over 100KLOC) project in VB, and VB has been easily powerful-enough to finish the project.

Like it or not, VB is an easy programming language to learn (although VB .NET looks like it will raise the bar a bit). Perhaps Delphi is better. Maybe Ruby or Python are the best beginner-oriented languages ever invented. But NOBODY ever has the chance to learn these as their first languages. You can't just stumble into Delphi programming like you can with VB.

Benji Smith
Monday, April 15, 2002

The real issue in this and similar discussions is why Delphi enthusiasts insist on trying to ram their own preferences down everyone else's throats.

This is a phenomenon that previously afflicted Macintosh enthusiasts, OS/2 believers, Smalltalk proponents and at one stage even DOS believers. It's called intolerance.

Hugh Wells
Monday, April 15, 2002

Well put Hugh!  I would add Linux bigots to this list too.

A programming language is a tool, not a religion.

anon
Monday, April 15, 2002

Or alternatively, I think VB Sucks and Delphi Rocks - why, because I'm a simple minded idiot.

Tony
Monday, April 15, 2002

Well, lets look at http://www.geocities.com/antivisualbasic/thirteen.html for a start (my numbers will relate to his 13 points):

1. He says that FuncName(Param1, Param2) will work and that Param1 and Param2 will be passed byval. This is untrue - it wouldn't compile! His point would be valid if there was only one parameter though...

2. Variable declaration is hardly rocket science - that issue is generally picked up pretty quickly. Hardly worth a mention.

3. So what.

4. It is common practice in VB to always include lower and upper boundaries for an array. If you do that, his point four is an irrelevance.

5. Collections are a source of confusion sometimes - but some of the collections are outside the VB runtime, so you can hardly blame the language for that...

6. Very meaningful argument. No sane person would claim VB was completely object-oriented, so what is he saying that everyone doesn't already now?

7. Initialisation of arrays is annoying. You can use the Array command, but admittedly it isn't much (if at all) better than his example...

8. Fair point. Not that I use arrays much.

9. Maybe he should read up on the Long / Currency / Decimal / Single / Double datatypes.

10. If you want default properties, you need the Set statement. Hence the change in VB.Net where the Set statement no longer exists. Again, hardly rocket science.

11. I would expect that to be the behaviour. Or does he forget that checkboxes have three states (not two)? Reading the manual might have helped him there.

12. All four of the constants have distinct and important uses. Not that I have ever used Error.

12.5. Disable the option. It is configurable.

12.7. Never seen that - unless he does a plain Run, rather than a Run With Full Compile. And if he does that, well he deserves all he gets...

12.8. Static subs are pretty useless. So don't use them. I think I could find 'useless' features in most languages...

13. Yes, very sound argument. Not.

Thats about it for me. ;-)

Seeya

Matthew John Wills
Monday, April 15, 2002


I would like to point that, usually, among the most fanatic Delphi evangelist, there is a lot of ex-VB programmers.

When asked which tool I recommend, I always asks about budget. If they can pay a little more on salaries, then I prefer to hire Delphi programmers; usually, they have a stronger background than VB programmers, you can be a little more relaxed on managing and we still can deliver a good product soon. If they have a tight budget, I prefer to hire VB grunts, because there is a lot more VB knowledge around, and the salaries are lower. You can still deliver an adequate product on time, but need to be more careful with planning and management.

My two pesos.

Leonardo Herrera
Monday, April 15, 2002

In reply to Matthew John Wills

FYI, Verity Stob is a female humour columnist currently writing for Dr Dobbs. As such, I imagine that her article should be taken as poking a bit of fun at the quirks of VB, rather than as a serious critique requiring such an in-depth response.

Andrew Simmons
Monday, April 15, 2002

"2. Variable declaration is hardly rocket science - that issue is generally picked up pretty quickly. Hardly worth a mention."

Nice source of bugs though. There's nothing like making it easy to write buggy code because... well. I dunno how to phrase this, maybe VB developers actually are super-human and don't make mistakes and don't need all the help they can get to catch them, but I doubt it.

"3. So what."

The fact that by looking at a line saying

  value = foo(27)

doesn't tell you if it's a function call (with possible side effects) or an array reference, is a "So what" point?

Oh my god, this explains SO MUCH about why writing code on large projects is hard. One person working with logic like that behind turns all the code into this complex unfathomable mess. It explains this whole "no operator overloading because people don't use them right" crap that comes with Java. At the time I'm going "Who the hell would deliberately use obscure definitions for the operators?"

Now I know. People who think having to click on something and ask "find definition" to work out what a single line of code does would do things like that.

Coding is already hard work, why go out of your way to make it harder? I've never understood why people do that, but your comment provides a little enlightenment. You do it because you simply don't care.

"So what?" Yeah, so what. *YOU* wrote that code, you know what it does. Anyone who can't merely read your mind and guess the intention isn't worthy to touch the code.


Code should not be written for the compiler's convenience. The compiler has all the time in the world. The person who has to fix this code in a year does not. Write the code for them.


"6. Very meaningful argument. No sane person would claim VB was completely object-oriented, so what is he saying that everyone doesn't already now?"

No sane person would. Unfortunately management don't read the same journals as the rest of us, and when you say things like "we need an OO language to make sensible headway on this project" are in fact in dumb enough to pull out a copy of VB with it's "Now with Object Orientation" sticker on the front.


"11. I would expect that to be the behaviour. Or does he forget that checkboxes have three states (not two)? Reading the manual might have helped him there."

Then getting them as a boolean value should not be possible. If this:

  boolean v1 = get_a_given_boolean_value();
  boolean v2 = logical_not(get_a_given_boolean_value());
 
  if (v1 && v2)
    say "true"

EVER says true, there's something wrong with your type system, or your compiler, or your type enforcement or your idea of what "boolean" means or possible all of them.

"12.5. Disable the option. It is configurable."

It took ages for me to find it. It's bloody annoying. Why is the default behaviour of the editor annoying. My mother might find that useful. My mother doesn't develop code. Every serious developer turns the option off. WHY IS IT THERE THEN?

"12.7. Never seen that - unless he does a plain Run, rather than a Run With Full Compile. And if he does that, well he deserves all he gets..."

Why does it even HAVE an option that produces bad effects. It's all very well to say "no-one uses that, everyone knows it's broken"... why is it /THERE/ then?

Katie Lucas
Tuesday, April 16, 2002

anon - the thing about tools is that to be useful they have to work. i cannot put up a picture with a hammer whose head keeps dropping off. as one tiny example, i am pretty pig sick of having to quite visual studio, deleting the .ncb file, and restarting, just to be able to use one of its most basic features. that doesn't make it a tool, it makes it a liability.

nope
Tuesday, April 16, 2002

regards 12.7 - it is similar in vc++. there is a "build" and "rebuild all". sometimes "build" just doesn't get it right (and even if it does, it can leave you with debug symbols which don't match code).

damn, i wish this board had proper threading
Tuesday, April 16, 2002

> it is similar in vc++. there is a "build" and "rebuild all". sometimes "build" just doesn't get it right

I can't be bothered with tool errors, so I switch off "edit and continue", "minimal rebuild", "incremental compilation", and "link incrementally"; that removes the need for a perpetual 'rebuild all', in my experience, except for in some complicated resource-only DLLs.

Christopher Wells
Tuesday, April 16, 2002

christopher - don't your co-workers get the hump? most of those settings are in the project (if i am understanding you correctly), so anything you do there also affects them. presumably some people want the features you switch off? i guess as long as you don't check in those changes it doesn't matter, but then every time the project file changes for a legitimate reason it is more work. i find experience usually allows me to detect when something strange has happened as a result of this kind of thing, but to be honest i am more worried about the non-usual times.

i have to echo katie lucas' question here - why does it even have an option that produces bad effects? either the option is worthwhile, in which case it should work, or it is not, in which case wtf is it doing in there in the first place. i can't build a house when the foundations are in sand.

fsck it. i've had enough for one day, i'm going home.

nope
Tuesday, April 16, 2002

pb wrote:
"If all things were equal, sure, Delphi may be better. But all things are not even remortely equals. There is a massive infrastructure around VB in the form of books, libraries, training, consultants, contractors, Microsoft, etc., "

Ehm, have you ever stopped to think about just why that is? Why are all those books, libraries and training necessary to get the job done?

Different target audience perhaps? (as in Delphi targets professional developers, VB targets newbies)

Different foundation? (writing Delphi code is more predictable, the compiler catches more mistakes than VB does during the compile/pre-run stage)

And how many of those VB books rehashes topics already explained to death in virtually hundreds of other VB books? (and how many VB books are there around to cater for the more experienced developers?)

As for the alledged number of contractors... How many of the VB contractors out there are really qualified to do anything beyond putting pretty buttons on a form? (btw: it'd be interesting to know who in this thread have experience with more than one development tool...)

--
Rune who've worked professionally with C, VB and Delphi.

Rune Moberg
Tuesday, April 16, 2002

"No sane person would. Unfortunately management don't read the same journals as the rest of us, and when you say things like "we need an OO language to make sensible headway on this project" are in fact in dumb enough to pull out a copy of VB with it's "Now with Object Orientation" sticker on the front. "

People saying things like "we need an OO language to make sensible headway", shouldn't put the blame on management for being dumb. You can write OO in any language (Fortran and 6502 assembly language included!). In languages with strong enough pointer semantics (_original_ Wirth/Jensen Pascal, or plain old K&R C), you can even do that sensibly without much work.

If management pulled out Smalltalk, would that have been better? How about Beta? (That takes object oriented programming one step further, in what I consider to be the right direction for a change ....).

Saying "an OO language is what we need to make sensibly headway" deserves Object Oriented Visual Basic as a reply. OO is not a magic bullet. If you need total control than C or C++ is the only choice (with C++ being _less_ attractive - despite what you may want to believe, controlling e.g. STL allocations or allocations inside abstraction is more pain than mere mortals usually want to put up with). If you want a sandboxed environment for Web processing, then Java and Python fair well, but ASP/ADP/PHP style solutions are probably better.

Can you quantify the "sensible headway" an OO language can give your project? Any project? Anyone has pointers to the "common knowledge" that OO as a methodology is superior? For heaven's sake, it's just a tool, and it's more often abused than properly used.

Ori Berger
Tuesday, April 16, 2002

> christopher - don't your co-workers get the hump? most of those settings are in the project (if i am understanding you correctly), so anything you do there also affects them. presumably some people want the features you switch off?

Absolutely: our *.dsp files are version-controlled ... and standardized, and change relatively rarely. If anyone wants "non-standard" settings, they can have them on their machine but they're not supposed to check them in.

> why does it even have an option that produces bad effects?

Some things work for some people and not for others; if it doesn't work for us, we don't use it. <shrug>

Christopher Wells
Tuesday, April 16, 2002

``People saying things like "we need an OO language to make sensible headway", shouldn't put the blame on management for being dumb. You can write OO in any language (Fortran and 6502 assembly language included!). In languages with strong enough pointer semantics (_original_ Wirth/Jensen Pascal, or plain old K&R C), you can even do that sensibly without much work.

Saying "an OO language is what we need to make sensibly headway" deserves Object Oriented Visual Basic as a reply. OO is not a magic bullet. If you need total control than C or C++ is the only choice (with C++ being _less_ attractive - despite what you may want to believe, controlling e.g. STL allocations or allocations inside abstraction is more pain than mere mortals usually want to put up with). If you want a sandboxed environment for Web processing, then Java and Python fair well, but ASP/ADP/PHP style solutions are probably better."
''


OK, my original comment was a paraphrasing of the kind of arguments that go on. The point I was making, which you seem to have missed, is that language decisions don't get made by competent developers who understand the issues. They get made by management people, who read the stickers on the boxes. Claiming a language is OO when it doesn't support niceties like constructors and essentials like inheritance is, basically, lying. And it's damaging because it gets believed by people who don't understand enough to notice it's a lie.


Why am I writing my current project in C++?

It's not because C++ is the best tool for this job. Good god almighty, it's a THROW-AWAY TOOL to test another project involving lots of text manipulation.

Why am I, then, writing it in C++?

Because the choices available are: Lotus Notes scripting, Microsoft Access or C++ Builder. No, seriously.

Perl is the obvious choice, but Perl isn't allowed. Perl isn't allowed because no-one else here officially speaks Perl. They can only official speak it after they've been send on a suitable training course. Lots of people do speak it, but that's not official, so there'd officially be no-one to maintain the code. Hence: no Perl.

Yes. You should be going "but.." here, because yes, this is a throw-away test tool. A complicated one, but a throwaway all the same. It's not going to need very much maintaining. And anyway the order-of-magnitude reduction in line-count would help on that front...

That decision was not taken by anyone who has ever used C++ or Perl... The same sort of person who could well pick VB as the companies OO development tool because it says it's OO on the box when it isn't.

That was my point. Thank you for missing it.

Katie Lucas
Tuesday, April 16, 2002

Rune, more is definitely better in this case. Sorry.

pb
Tuesday, April 16, 2002

pb, in my far from humble opinion, you're wrong. Unless you agreed that experience with more than one tool is good, in which case I agree with you agreeing.

Thanks for not contributing anything to this discussion pb. :-)

--
Rune

Rune Moberg
Tuesday, April 16, 2002

Hi Rune,
"How many of the VB contractors out there are really qualified to do anything beyond putting pretty buttons on a form?"
The language used neither qualifies nor disqualifies the developer in either way. I've used Delphi, Powerbuilder, Gupta in the last 6 years and buttons are about the same degree of complexity in all of them, If its not then somethings badly wrong with the product.
If we change the comment to
"How many of the contractors out there are really qualified to do anything beyond putting pretty buttons on a form? "
the answer remains the same.
For some reason VB upsets you?

Tony
Tuesday, April 16, 2002

"That was my point. Thank you for missing it. "

I apologize for that - now I get your point;. But you state yourself that "perl would have been the obvious choice". Perl OO is only slightly better than VBs, and is being redone completely for Perl 6. Perhaps you're pulling the wrong arguments (lack of OO) to your managers as well, and if you use the right ones (right tool for the job), you would have been more successful. Mind you, this has been a VB vs. Delphi/whatever discussion. And Delphi wouldn't have been a good choice either, it seems.

Personally, faced with a situation such as you describe, I would consider looking for another place - using C++ for text processing because "perl is not official" means your company is probably less competitive than it could have been. If it's a market leader, it may be forgiven -- but if it isn't, it's a bad sign. Don't know about you, but I like to do useful work for companies that understand their environment.

[And ... here I go again: Have a look at Python. It is much friendlier than Perl to programmers, maintainers and managers alike]

Ori Berger
Tuesday, April 16, 2002

Well, yes there's a small difference in placing buttons, in Delphi you place a button on the form, it gets the size of a standard windows button but in VB, you got to resize and fiddle around to get it to the right size. I don't know about the latest versions of VB, in VB5 atleast it was like that. And I still don't understand the necessity of resizing non visual controls like timers on form in VB. You can find quite a lot of VB programs (shareware freeware) type getting buttons of all different sizes.
Small productivity advantage when you got to place quite a lot of buttons.

Sunish
Wednesday, April 17, 2002

Back in the day I was at a company that was developing software that was sometimes installed at client sites with the client's techie looking over your shoulder.  We had a VB application that contained several 3rd party components.  The problem was that our install disc failed often on different Windows machines until we finally figured out the file dependencies through trial and error (aka DLL Hell). Needless to say this was fairly embarassing and credibility-eroding.

Once we are able to surreptitiously get a copy of the competitor's app. - we just copied the exe file and a few data files manually... so we were able to install it back at our shop without the actual install disc!  It worked first time.  We found out the competitor was using Delphi.

anonymous
Friday, April 19, 2002

I got so frustrated with the lack of constructors I endedup creating a factory class to construct all my vb classes and building a check into all my objects to break them if they hadn't been constructed... a bit extreme I admit, but you wouldn't believe the reaction from my colleagues - they thought I was nuts.

The real problem with vb is the slovenly culture it fosters - bug heaven. Most vb programmers I know think Hungarian is the pinnacle of programming style, and I don't know how muc time I've wasted trying to explain that it's probably a good idea to hide variables if you can't think of any good reason why any client should see them. And people wonder why I instst on recompiling the whole project all the time.

Barney Finucane
Monday, April 22, 2002

QuickBasic was my first language. After coding in it for 10 years, circumstances dictated that I look at learning C for a new project. My mentors encouraged me to try it. After a month, I never wanted to look at a line of Basic again. In retrospect, working in Basic was like being in a bad marriage but not knowing it, because it was the first and only one I ever had. Now that I've been happily doing C++ since, a huge legacy project in VB surfaces and becomes my responsibility. I must have been an evil person in an earlier life.

Dave DeBenedetto
Tuesday, March 25, 2003

VB is difficult to understand because VB semantics are complex and the manuals are sketchy.  This makes it difficult to understand from the text of a (buggy) program what will happen.  Take just one example from MS Press VB 6.0 Language Reference (vol 1) (page 424) and the explanation of the Exit Function statement:

"The Exit Function statement causes an immediate exit from a Function procedure.  Program execution continues with the statement following the statement that called the Function procedure."

It doesn't say anything about the return value, or if the return value is assigned.  It is impossible to get from the manual description to a total understanding of Exit Function. So I can't reason about the value of a variable, in a  buggy program, that is assigned the return value of a function that exits.  So I can't explain what effects the bug might have had.  I have to run the debugger and experiment.

purist
Wednesday, September 17, 2003

This is my experience to develop application using VB and Delphi.

There is no VB application can not create by Delphi.
There is no Delphi application can not create by VB.

So, both VB & Delphi can write any applications perfectly deliver too my customer.

Wendy William
Thursday, October 23, 2003

No importa que lenguage uses para trabajar; lo importante es que los reuqerimientos que te pidan se puedan realizar correctamente, rapido y con el menor costo posible...

I don't speak english

Alvaro de la Garza
Wednesday, July 07, 2004

*  Recent Topics

*  Fog Creek Home