.NET Hobbyist Programmer

Staying Confused in a Busy World
posts - 254, comments - 192, trackbacks - 674

My Links

News

Neat Stuff Read all my hurricane entries While you are here, visit the Geeks With Blogs main feed
Advertising
Links Status of the Navy
Channel 9

Tag Cloud

Article Categories

Archives

Post Categories
<< Google's Eyes | Home | On Meetings >>

Recalling Visual Fred

Recently, Eric Gunnerson posted code on how to create an array with a non-zero lower bound.  Paul Vick brought up the AndAlso and OrElse operators which are new to VB.NET.  This got me to thinking of the state of affairs way back in 2001 when .NET was still in its beta phase.

Three years ago, Visual Fred was the derisive name given to VB.NET 2002 by VB6 programmers who did not like the changes to the then forthcoming programming language.  The VB6 programmers of the time had the sentiment that it really wasn't VB anymore, and perhaps should have been given a different name.

Microsoft did that when it created C#, but it kept VB as is.  Much the same sentiment was probably voiced when people moved from C to C++ or from C++ to C#.  Admittedly, my memory is hazy here.

I scanned through the list of concerns/complaints (reproduced below) with three years of hindsight to see if all the fuss really mattered.  From my point of view, it didn't.  Many of the items listed have simple substitutions in .NET.  My evaluation is tempered by the fact that I did not have a huge investment in existing programs to maintain and upgrade.  I have just one big one (EDR) out there in VB6.  I thought at the time that both the discussion and the list was a bit overstated.  I recall that several developers said they would no longer use VB and would switch to Delphi.  (Hmmm, isn't Delphi object-oriented Pascal?  It seems strange that people would switch away from OO VB to OO Pascal.)

This list comes from Karl Peterson's website.  From the numerous nots in the list, you can guess Karl's position in the argument.  Since there are so many ways to do things in .NET, the ultimate implication of the changes were not much.  Several of the listed items were peeks into the behind-the-scenes way that VB6 did business.  Everyone knows that it is a Bad Thing to continue to assume undocumented behavior will continue to be supported.  They were convenient methods for a slick piece of code, or a small optimization, or even the only way to achieve a goal.

I guess much of the furor was because many of the items listed changed or removed many a favored programming feature.  In the intervening years, we have found many ways of doing the same thing a different way.  This implies that we have learned something in the intervening time.  I see that as a good thing.  Plugging away at the Same Old Thing, while potentially putting food on the table, is not continually emotionally satisfying, nor does it provide for keeping up with changing customer requirements.

As for the array issue mentioned above, it appears as #7 in the list below.  The implementation is easy and can be adapted as required.  The forthcoming VB 2005 will support generics which will make it even easier.

Popular myth has Microsoft's products achieving maturity at version 3.  This happened with VB3 and again with VB6.  The forthcoming Whidbey release will be called VB 2005, but it is essentially VB9.  Perhaps it will be time for the new .NET to be considered mature.

  1. VarPtr is not supportedavailable.
  2. StrPtr is not supportedavailable.
  3. ObjPtr is not supportedavailable.
  4. As Any is not supported for API Declares.
  5. Use of ByVal/ByRef directly within API calls is not supported.
  6. Private class variables are not private to the class instance.
  7. Arrays may not have a lower bound other than zero.
  8. Dynamic arrays are not allowed within structures (UDTs)
  9. Arrays are not declared using the upper bound. (Addressed in Beta2)
  10. Option Base is not supported.
  11. Variants are not supported. Object is now the default data type.
  12. Currency is not supported.
  13. Dates are not stored internally as Double values.
  14. Longs are not 32-bits; they are 64-bits.
  15. Integers are not 16-bits; they are 32-bits.
  16. True, coerced to an Integer, is not -1, but is 1 instead. (Addressed in Beta2)
  17. The Imp and Eqv operators are not supported.
  18. Fixed-length Strings are not supported.
  19. DefInt, DefLong, et al., are not supported.
  20. Dim may not always create procedure-level variables.
  21. Redim will not create arrays not already declared.
  22. Local variables are not necessarily visible (in scope) throughout a procedure.
  23. VarType is not supported.
  24. Empty is not supported.
  25. Null is not supported.
  26. IsEmpty is not supported.
  27. IsMissing is not supported.
  28. IsNull is not supported.
  29. IsObject is not supported.
  30. Let is not supported.
  31. Core language constants do not have a "vb" prefix (vbRed becomes Red).
  32. Terminate will not fire when an object's last reference is released.
  33. Object finalization code will not execute in a predictable order.
  34. Implicit object creation is not delayed until first reference.
  35. Public object variables are not safe from alteration when passed as parameters.
  36. Can not expose Property procedures with mixed visibility (Friend Set/Public Get).
  37. Procedure parameters are not by default passed ByRef anymore.
  38. ParamArray arguments are not passed ByRef anymore.
  39. Property parameters may not be passed ByRef anymore.
  40. Implements is not implemented the same, so must be rewritten.
  41. Static is not supported as a procedure level modifier.
  42. Use of As New does not force auto-reinstantiation when an object is released.
  43. Parenthesis are not optional when calling procedures.
  44. Set is not supported for object assignment.
  45. Parameterless default properties are not supported.
  46. Default values for Optional parameters are not optional.
  47. Code is not compiled to native, thus making decompilation much easier.
  48. Resource files have changed format and old ones are not supported.
  49. LSet is not supported.
  50. RSet is not supported.
  51. UDTs are not Types, but are called Structures instead.
  52. UDTs are not by default contiguous blocks of memory, but are objects.
  53. Enums will not be recognized unless fully-qualified.
  54. While/Wend loops are not supported.
  55. GoSub/Return is not supported.
  56. On/GoTo is not supported.
  57. On/GoSub is not supported.
  58. Line numbers are not supported. Labels may be numeric.
  59. Erl is not supported.
  60. The MsgBox function is not supported.
  61. The DoEvents function is not supported.
  62. The Date statement is not supported.
  63. The Time statement is not supported.
  64. And, Or, XOr, and Not are not bitwise operators. (Addressed in Beta2)
  65. Comparison operators are not evaluated before logical operators. (Addressed in Beta2)
  66. Sqr is not supported.
  67. Sgn is not supported.
  68. Atn is not supported.
  69. The String function is not supported.
  70. Control arrays are not supported.
  71. The native Forms collection is not supported.
  72. UnloadMode detection is not offered, as QueryUnload is history.
  73. ListBox controls do not offer an ItemData property.
  74. ListBox controls do not offer an NewIndex property.
  75. Windowless controls are not supported.
  76. Image controls are not supported.
  77. Shape controls are not supported.
  78. Line controls are not supported.
  79. OLE Container controls are not supported.
  80. Label controls will not have a Caption property.
  81. The Tag property is not supported. (Addressed in Beta2)
  82. The ToolTipText property is not supported.
  83. The TextHeight property is not supported.
  84. The TextWidth property is not supported.
  85. Setting a Timer control's Interval to 0 does not disable it.
  86. Top-level menus may not be used as context menus.
  87. Old forms using vbPixels for Scalemode will not upgrade correctly.
  88. DDE is not supported.
  89. Circle is not supported.
  90. Cls is not supported.
  91. Line is not supported.
  92. PSet is not supported.
  93. Point is not supported.
  94. AutoRedraw is not supported.
  95. PrintForm is not supported.
  96. Scale is not supported.
  97. The Name property for forms and controls is not exposed at runtime. (Addressed in Beta2)
  98. Print will not include a linefeed at the end of a line.
  99. File I/O will not be compatible, at all, and must be rewritten.
  100. Printer object methods are not automatically upgraded and must be rewritten.
  101. Clipboard object methods are not automatically upgraded and must be rewritten.
  102. The Err object is not shared between managed (.NET) and unmanaged (ActiveX) code.
  103. The App object is not shared between managed (.NET) and unmanaged (ActiveX) code.
  104. Screen.MousePointer does not have a direct replacement.
  105. Webclasses are not supported.
  106. DHTML projects are not supported.
  107. UserControl projects are not supported.
  108. ActiveX Document projects are not supported.
  109. The IDE Extensibility Model is not backwardly compatible.
  110. Run->Break->Edit->Continue development is not supported.
  111. The Immediate window will not work in Design mode.
  112. SDI will not be an option in the IDE -- MDI or nothing.
  113. Debug.Print is not supported.
  114. Debug.Assert is not supported.
  115. Data binding with DAO is not supported.
  116. Data binding with RDO is not supported.
  117. ...
  118. ...
  119. ...

Print | posted on Tuesday, April 20, 2004 4:42 PM | Filed Under [ Programming ]

Feedback

Gravatar

# re: Recalling Visual Fred

Hi, Mark: Thought I'd mention that I posted a VB.NET implementation of Eric Gunnerson's array technique on the new VB FAQ blog: http://blogs.msdn.com/vbfaq/archive/2004/04/20/116660.aspx
4/21/2004 2:17 PM | Phil Weber
Gravatar

# re: Recalling Visual Fred

I hate to nitpick but Pascal was my first language. Pascal itself, not Delphi, is OO.

I consider Delphi "Visual Pascal" but not in the way I consider Visual Basic an extension of Basic. Basic was never OO as a language, yet Pascal is.

Delphi is very fun and there's a lot a VB programmer can do with it. I dabbled some with VB before I really got into programming and the transition to Delphi was painstakingly easy. I'm now transitioning to C# which is roughly the same learning curve as from VB->Delphi. There's a ton of similarities between Delphi/Pascal and C#.
4/21/2004 4:59 PM | Jeremy Brayton
Gravatar

# re: Recalling Visual Fred

Jeremy: You are correct, but my intent was to gloss over the finer points of the relationships and concentrate on the OO nature of the two (Delphi and VB.NET). Why dump a non-OO language as it is being updated to be OO for a completely new OO language. I never thought those discussions made sense.
4/21/2004 5:52 PM | Mark
Gravatar

# re: Recalling Visual Fred

>Three years ago, Visual Fred was the
>derisive name given to VB.NET 2002
> by VB6 programmers


This is incorrect. A MS employee suggested Visual Fred might have been a better name for VB.Net, given its lack of similarity to Visual Basic.
1/10/2005 7:08 PM | birchr
Gravatar

# re: Recalling Visual Fred

It seems like MS wants to make the language less important than the IDE, that way they only have one product to maintain. I guess we didn't realize how good we had it with VB6.

This is progress?

VB6:
screen.mousepointer = vbDefault

VB.NET:
System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default
4/5/2005 4:25 PM | Disgruntled
Gravatar

# re: Recalling Visual Fred

huh?

You mean
#using System.Windows.Forms

...

Cursor.Current = Cursors.Default

not so very different - most UI components of a forms app will have the #using line at the top anyway.
6/21/2005 6:19 AM | George
Gravatar

# re: Recalling Visual Fred

Get over it people...times chage, tools change, customer requirements change. VB6 is a dinosaur long in search of extinction. Thank god Microsoft killed it. Now if only they would kill off BASIC, period
8/13/2005 9:22 AM | Manuel
Gravatar

# re: Recalling Visual Fred

Not only did Microsoft kill off VB6, they killed off VB, period, and they did so starting with VS2002 (a truly *wonderful* product - but who uses it any more?)
VB was always a RAD tool not an OOP tool, and every version since VB6 takes us further and further from that - it is absurd to call VB.NET "BASIC" as it very clearly is not. Visual Fred was the right idea, or maybe "B#". If I wanted to program Java, I'd use Java, not Microsoft's rip off product.
And since 2002, the .NET framework is still unsuitable for use with any app that requires a stable foundation - how long are we supposed to wait? And if .NET is so great, why does Microsoft not practice any form of dogfooding with it? No, even Microsoft has no .NET-based software, which tells me all I need to know - if the authors don't use it themselves, they must KNOW something!
1/13/2006 12:40 PM | NoMoreVB
Gravatar

# re: Recalling Visual Fred

"Much the same sentiment was probably voiced when people moved from C to C++. Admittedly, my memory is hazy here."

Well, mine isn't, so let me explain.

C++ is a superset of C and that meant C programs upgraded without changes. VB.NET is not a superset of VB6 so upgrading takes about 5% to 10% of the original effort to write the original program. Why should we have to spend that sort of money, just so Microsoft can save by harmonising on one runtime?
2/23/2006 8:42 AM | Mark
Gravatar

# re: Recalling Visual Fred

VB6 still makes our team a ton of money. It may be dead to you - but we're having a blast and plan to use it as far into the future as possible. That ole' saying that DOS was dead - but we still have users using it also!

VB.Net (in 3 flavors) - all different from each other - when will the final product be ready?
Net, 2003,2005???

I must admit we are slowly learning VS2005 - (not without a few cus-words) - and as lost as we are in this new language - we realize that with enough trial & error - we might get some point to where we know if what we are typing actually does something!

The VB.NET language is greek, unless.you.know.what.you.are.doing()
The help file is of little help - which refers you to other topics which you know nothing about also - which refers you endlessly to knowwhere! Great! Let's get started.








3/13/2006 11:04 PM | YongYe Meeks
Gravatar

# re: Recalling Visual Fred

Does anyone remember going from BasicA or GWBasic and those compilers to QuickBasic and then to Visual Basic? Embrace the .Net path to 2005 like we did Visual Basic back when and you'll come to realize a longer and easier future in this industry. Or not... But when was the last time you heard of product development being done in QuickBasic? Besides which, this thread is about two years only already. ;-)
3/19/2006 2:18 PM | old fart
Gravatar

# re: Recalling Visual Fred

Yea ... my eternal blog entry. I've done all the Microsoft Basics, including VB-DOS. I like the new VB, but then, I do not have a pile of code out there making money. I do support one middling size VB6 app, but there is no db behind it -- it's all text files. I'd love to move it on, but there is little drive for that just yet.
3/19/2006 5:27 PM | Mark
Gravatar

# re: Recalling Visual Fred

Change is good, but this is ugly. WithVB6, a down and dirty app took minutest to write and made clients happy. OOP is for programmers who have time...it's not a RAD tool...

Frankly, I'm afraid to get too tied to 'intrinsic' OOP libraries...God know when and how they'll change...databinding was a good thing, until they changed all of the controls at one point...

Oh well, back to the book.
4/28/2006 1:46 PM | tr
Gravatar

# re: Recalling Visual Fred

>But when was the last time you heard of product development being done in QuickBasic?

still have a ton of apps running in quickbasic pds 7.1 video shops and service management software. some of the staff have said to me that they prefer the dos console apps to shiny window apps as the they had higher throughput on apps 100% used by keyboard rather than the keyboard mouse combo used by windows databases.
11/10/2006 5:23 AM | moylan
Gravatar

# re: Recalling Visual Fred

From what I have seen and used I know that this is not the 'basic' I fell in love with back in BasicA (the IBM version; the one with the chip requirment) all the way to Visual Basic 6. (Yes, I use DOS still on my new shiny sony vaio 2g duo) I am an Open Source Developer and I do have code in VB6. To upgare (as we all have done in the pass) to the new VB would mean major rewrite of main code. It might just be easyer to code it afresh. From my point of view the magic has been lost, but maybe it is the 'can't let it die this way' dream in my brain that makes me think to my self... maybe there is a new type of magic over the hill? As the old saying gos "Two steps forward, one step back" Maybe VF will become VB again some day... until then I will still love and use VB6(SP6) where and when ever I can.
12/16/2006 4:50 AM | Cip2
Gravatar

# re: Recalling Visual Fred

I'm sitting here, earning my money with programming in VB6.
It'll be so in 2009 i think.
DEAD? Not really ;-)
11/4/2008 8:23 AM | SK
Gravatar

# re: Recalling Visual Fred

I was totally annoyed with VB.NET at first having used VB6 for ages.
Recently, having worked with VB.NET for years, I worked two months on a VB6 app for maintenance.

I simply could not *believe* how many things you could *not* do in VB6 which are so easy in .NET these days. No constructors, no dialogresults, no variables local to loops, no boolean shortcircuits, no shared eventhandlers, the list goes on and on.

I can not recall my early anger at all, I'm afraid.
2/4/2009 9:38 AM | Tinnderbox
Gravatar

# re: Recalling Visual Fred

I moved to delphi because borland/imprise/embarcadero did incremental upgrades to the language (much like early vb) and never massively broke my projects

I do program nowadays in .net using C#, wasnt that hard because the framework its similar to the delphi vcl and the ambient to java the two other languages i had used at the time

But vb5 and 6 where good enought, even now... some times i feel i can do things more easily if i where using vb. Things that people say wheren't posible using classic vb, in fact are simple to do... Constructors? just mark the class public not creatable and return instances from one constructor function in a global multiuse factory class. shared eventhandlers? define a event_controler interface, define event_listener class for every control you care (having implements event_controler interface) add your controls to some collection of event_listener class

I did have a home build vb6 framework, and to date havent found something i couldnt do using vb6 with a little delphi help (or freewares: multi-threading -> DirectCOM.Dll; asm -> ThunderVB Add-In; RPC -> wodBeep.Ocx, etc)
2/7/2009 12:00 AM | Aging Coder
Gravatar

# re: Recalling Visual Fred

You see, what is being destroyed here is not a language really, but a simple concept. With the advent of BASIC came, for the first time in the history of the programming world, the element of reasonably human choice! For the first time people could program their computer in a way similar to how they would, say, write a letter to a friend. This is not just about syntax constructs or what works 'better'. BASIC is the most human-readable language on the face of the earth! This sold to millions, and is STILL selling, because it gives many more users A CHOICE! History has proven, when you tamper with that, you lose exponentially, and Microsoft WILL lose. I just hope, for their sakes, it isn't too greatly before they come to their senses.

As for me, I totally agree with the aging coder. I will not totally depend on any Microsoft tool for anything! When I found out that BASIC was still not yet a standard (ISO or otherwise), almost NINE years after it's creation, I knew the writing was on the wall. I did what any forward-thinking developer would have done, and started to look into ways to maximize on my investment as best and as independently of Microsoft as possible. I started to look into breaking the habit of depending on active x and anything that had to do with the registry and started making my applications to just depend on the vb-runtime by building my own class libraries. Now I work on eliminating the need for even that. Why? because the syntax construct still works and I still love it; it is MY choice! Years after vb6 came out people were, and still are, finding out the amazing capabilities of this tool. I am one of those people who love this language construct and will continue to love it. When they find a way to break the old code totally, I will make the full move to Delphi or Powerbasic, and when they break the old way altogether (by removing things like the Win API) I will move to a next OS (RealBasic, etc). For my own use I'm seriously looking into building my own compiler or even my own OS as not one of these corporate bodies can be trusted. This is about choice people, choice!
3/6/2009 4:08 PM | TruthTheoryAndFact

Post Comment

Title  
Name  
Email
Url
Comment   

Powered by:

Copyright © Mark Treadwell