Lambda the Ultimate

pragmatism: What language doesn't have this as a priority?

Off the top of my head, I doubt if I could come up with two hundred. There are a lot of languages in whose design pragmatism is trumped by ideological purity or ease of implementation, and many more where a desire for pragmatism is rendered moot by the designers having little to no idea of what working programmers actually do with their days.

You forgot to include VB.Net in the link you posted. If you had, you would have seen it ever so slightly ABOVE C#. (And Java way above of both of them.)

Not that it matters, as those are google searchs, not jobs.

I thought "vb" would have picked up both VB and VB.NET -- gotta remember that. Trend line is still 50% of three years ago. It is just because developers are retaining information better and having to resort to Google less often?

It may also be slightly interesting that the top four languages of people searching for VB-related items are non-Western, and they search for VB more than twice as much as C#. Could this be something to do with syntax, or just job opportunities?

I still think VB is the red-headed stepchild at Microsoft.

"bends over backwards trying not to scare the novice programmer"

Perhaps this is a good principle for language design? :-)

Or are you just moonlighting as a troll, Ehud.

Actually I think this is a legitmate question, even if I have my preferred answer of course.

Okay, I'll bite. I don't agree with the "languages for smart people" camp, and Microsoft certainly doesn't have that luxury anyway: writing off their millions of novice users would mean instant death.

On the other hand, Microsoft has an incredible opportunity on their hands. Catering to the lowest common denominator of novice users might lower the bar, but unless a technology allows users to grow and grows along with them, it becomes an obstacle. Microsoft can seize this opportunity to educate millions of users and increase their productivity, or they can simply pacify them with C# lite. I actually see encouraging signs of the former, but I don't find Paul's declaration of "principles" convincing.

People gradually mature in sophistication as programmers, as users of a programming language and its tools, and as software designers in a particular problem space. In fact, the latter is true not just of novice programmers, but of everyone--this is the insight of iterative development.

At one end of the spectrum, if a technology requires too much initial cognitive investment (e.g., Eclipse or Developer Studio) it shuts out many users at the gate; at the other end, if it's too restricted in the name of simplicity (say, Notepad), it simply doesn't scale up.

I believe the "gentle ramp" is the solution (to complete the analogy, DrScheme). See also "progressive disclosure."

In at least one way, VB7 gets this right: optional static types are an example of a language feature that facilitates gradual migration from small scripts to large programs, allowing software designers to grow along with their programs.

No, it is a good principle for language presentation. It sounds to me like you are saying we should all walk around speaking like 5 year old's so that they are not scared into being mute.

Now I have to ask, since syntax of a language has never scared me, what is an example of scary language constructs?

Accessability of the documentation and introductory materials are what attract me or scare me away. For instance, the draft inroduction to Lisp recently discussed here was a real eye opener that made we want to take another go at a lisp dialect. The syntax (symantics?) of lisp couldn't be simpler, yet there are deep concepts and cognitive frames that need to be grasped.

I don't beleive in an ideal noob language, rather an ideal noob environment. I think scripting of almost any kind (shell, http server pages, web browser client) provides a simple enough environment and challenges for anyone to get their feet wet, build confidence, and gradually increase complexity.

I can't imagine recommending ASP.NET as a noob platform.

Now I have to ask, since syntax of a language has never scared me, what is an example of scary language constructs?

Ever programmed in C++? Perl?

I love Haskell's syntax, but I have to say monads are a scary feature. The real heart-pounding moment comes when you get past all the tutorials telling you how simple they are and realize what they're actually for. It's like a really, really good horror movie.

...Anyway, the most important feature for new programmers is a simple interactive prompt (a REPL). The progression "nothing -> command line interaction -> writing scripts -> writing programs" is very natural, compared to "nothing -> driving a gigantic IDE".

I think the scary thing about monads is the amount of power there - I agree, the tutorials don't really set you up right for that at the moment.

The essence of functional programming is one of the better lead ins then if I'm getting this right.

I'd say these principles must have some merit given that VB is by far the most popular language (in terms of user base) in history. Have you created such a popular tool? I think not.

The fundamental problem is that there aren't enough fulltime/professional programmers to go around, essentially, so any tool that allows a reasonably smart non-specialist to whip up some software is a lifesaver in many places. I've worked at a scientific research center before and seen a *lot* of very, very ugly VB apps written by very, very smart scientists who needed to simulate their latest theories or power some simple hardware they'd built. A tool like VB but that provided more guidance with developing correct/maintainable code would be a great thing.

There's a huge opportunity for a small company to come in here and reimplement Visual Basic, effectively carrying on where MS left off.

This isn't as hard as it sounds, as part of the Wine project we've had to clone large parts of the VB runtime in the form of oleaut32.dll (which provides the variant type and therefore much of the VB type handling code, Picture and Font objects, etc ...)

I think there are many developers who would jump at the chance to get Visual Basic 7, fully compatible with 6 but with extra features and tools. Even if the IDE isn't as powerful as Visual Studio is, it could still have potential.

Mike Hearn: There's a huge opportunity for a small company to come in here and reimplement Visual Basic, effectively carrying on where MS left off.

You mean like REALbasic?

Their website seems to take the approach "You've got to rewrite a ton of code anyway, so it might as well be for us, that way you're portable!". But if that's the case you may as well just port to VB.NET and use Mono, so I'm not really sure that a same-but-different dialog of VB is what people will want here.

If REALbasic was focussed on compatibility and adding compelling new features for Windows developers it would be closer to what I had in mind ...

Mike Hearn: Their website seems to take the approach "You've got to rewrite a ton of code anyway, so it might as well be for us, that way you're portable!". But if that's the case you may as well just port to VB.NET and use Mono, so I'm not really sure that a same-but-different dialog of VB is what people will want here.

If REALbasic was focussed on compatibility and adding compelling new features for Windows developers it would be closer to what I had in mind ...

I'd be willing to bet good money that REALbasic with its converter for Visual Basic is an easier port than VB 6 to VB.NET, with the added bonus that you can actually ship standalone apps across platforms without trying to decipher the licensing issues around Mono and the .NET framework. But if you define "compatible" to mean "sold by Microsoft," then of course you're right, by definition.

I have no idea how good their converter is, I was going by the porting document on their website which implies some pretty extensive changes to the code. Given that portability isn't a priority for many VB projects (in some cases, not even possible due to reliance on 3rd party COM objects), I don't see REALbasic as being especially compelling over a 100% compatible extended VB6.5

I cannot believe you think anyone is going to take you seriously when you complain about the Integer/Int32 issue. Anything that can be accounted for with a trivial search and replace is a non-issue.

And besides, traditionaly VB has always used Integers for array indexers. If we didn't make Integer 32bit, then we would have to start using Long for all of our indexers and you would be complaining about that.

As for GoSub vs On Error support, there is a clear explaination for that. The use of On Error was unavoidable in VB6. GoSub, on the other hand, was a remnant from the original BASIC days when we didn't have real subs. You should have stopped using it when QBasic was released.

Yes, there are some real compatibility issues like the Printer object that MS needs to address. But then again, it only takes about an hour to write a VB6 DLL that wraps the Printer object. Add a matching Module on the VB.Net side, and the syntax is EXACTLY the same.

So far you have given us a non-issue, an example of poor coding style, and an easy workaround. I'm sure there are plenty of real issues, but most of the people complaining are not presenting them.

Jonathan

P.S. Stop lying about the QuickBasic to VB6 conversion. Everyone knows you simply cannot write Console apps in anything before VB7. You can, however, convert most QuickBasic to VB7+ using a bit of creative regular expression work.

Jonathan Allen says

So far you have given us a non-issue, an example of poor coding style, and an easy workaround. I'm sure there are plenty of real issues, but most of the people complaining are not presenting them.

robertsconley's post is absolutely on point and absolutely, utterly, sadly correct. Jonathan Allen is incorrect. And while Jonathan Allen claims people are not presenting complaints, that is not so. The latest "Visual Studio Magazine" alone contains numerous complaints about the direction of VB7 and Microsoft tools by both readers and editors and that is a publication sympathetic to Microsoft. The Microsoft's MVPs petitioned Microsoft to further develop VB6 to no avail. The petition has had 10850 signatories, including 264 Microsoft MVPs, since March 8th, 2005. There have been thousands of complaints about the direction of Microsoft development tools everywhere: newsgroups, blogs, conferences and personal correspondences. With .NET Microsoft has shot itself not in the foot but in the stomach.

My diagnosis: a slow, lingering, painful death in the software development sector. There is no surgeon who can treat the patient and the patient cannot heal himself - it is too late, the die is cast.

Jonathan Allen says

P.S. Stop lying about the QuickBasic to VB6 conversion. Everyone knows you simply cannot write Console apps in anything before VB7.

Not so on both points: I've been there and done both. If anyone is lying here it's Jonathan Allen. Again, robertsconley is absolutely correct.

Perhaps I am mistaken. If you can translate this code from QBASIC to VB6 for me, I will appologize.

INPUT "What is your name" ; NAME$
PRINT NAME$
END

VB7+

Sub Main
Console.Write("What is your name")
Name = Console.ReadLine
Console.WriteLine(Name)
End Sub

As for the petition, it doesn't actually address the compatability concerns. Rather, it is a request to continue development of VB6 in parallel to VB.Net. The petition had no chance because the resources needed to develop new features for VB6 far exceeds the returns they would get.

THAT STUPID PETITION IS DISTRACTING PEOPLE FROM THE REAL ISSUES.

What I want to see is a list of real issues that prevent users from migrating from VB6 to VB8. I would sign a petition that asked MS to address that, because it is important.

Likewise, I would have signed a petition to open source VB6. But to have them try to cram it into Visual Studio without actually making improvments to it is pointless. The VB6 IDE is still solid, and I see no reason to stop using for legacy development.

Well, you just got me there. VB6 doesn't write Console applications. Of course if you are talking functionality you can use.

'Note the lack of Option Explicit
Sub Main()
Name$ = InputBox$("What is your name")
MsgBox Name$
End Sub

What if you wanted multiple output?
Well start a VB6 project

Put a command button in the upper right corner

Double click on said command button
'Still No Option Explicit
Private Sub Command1_Click()
Name$ = InputBox$("What is your name")
Cls
Print Name$
Print Name$
Print Name$
Print Name$
End Sub

Oh while is not a Console application VB6 can execute QB's print statement virtuall unaltered by printing to a form or a picture box. Something I used to convert a QB Utility. I took a VB form set the scaling to mimic DOS Character mode. Wrote a few helper fuction to emulate some of QB functions (like LOCATE, INKEY) and was able to run the Utility with the code unchanged.

Why? Because it was a old RPG utilityt hat I like the look and feel of and because well... I wanted to see if I could do it.

Oh and if you wanted to write a Console application using VB6. Use this code and instructions from Mattias Sjögren

http://mvps.org/st-software/Code/all.zip

Unless "most" QB code uses the console this directly, your claim is still unfounded. However, I'll be charitable: that doesn't make you a liar, merely someone who made a mistake.

Trival issues is an interesting point. The product I manage has been in use since 1985. Since that time I have written two major conversions. The first from the HP Rocky Mountain Basic version to VisualBasic 3.0, the second from the modular structed VB 3.x version to a pure object oriented design in VB 6.0. The software is a CAD/CAM package that designs and cuts parts to use on metal cutting machines. (http://www.plasma-automation.com)

The first was first driven by the need to have a Windows version of our software. The second was due to the need of reorganize our use of memory to escape limitations of fixed arrays data structure. (Which came about in the first place because we developed the first version of the software on PC in 1985).

In both cases the methodology was similar. I planned the new design, got a few basic things going, then copy,paste, and change the core routines that drive the our software, and finally running the automatic and manual tests to confirm behaviour has been preserved or altered the expected manner.

The core routines are very math or function oriented, like calculate the layout of a box, calculate a spline for a edge of a part, trim a part into two or more pieces, arrange a 100 parts on a sheet to minimize waste. Routines that are not really dependent what current graphics or hardware you are running on. Routines that for most langauge generally are only dependent on a math library and not much else.

HP's Rocky mountain BASIC is very different than Microsoft Basic. Had to do a lot of search and replace and reorganization to preserve behavior.

The transition to our VB6 based object oriented design required very little change. Mostly the changes were in the fact that the data being passed were collection class based not array based and.

The VB3 to VB6 transition took half the time the HP BASIC to VB3 basic. Also in the VB3 to VB6 transition the VB3 version ran in VB6 after a day's worth of fixing. So each phase of testing was a lot quicker we were more confident of the result because we knew when was a result of our software change or because VB6 ran differently than VB3.

The task to upgrade our software to .NET is the same time and testing requirement of the HP BASIC to VB3 transition INSTEAD of the VB3 to VB6 transition.

When I realized how .NET compiliers actually worked. I was pissed, as Microsoft decision has just now costed my company a lot of money. When I started dealing with the VB Team member and encountered their attitude to the issue. I became even more pissed but this whole problem is because of the damn langauge religion idiocy. Basically a bunch of semi-colon guys re-wrote VB.

And for the record I am proficent in C/C++ as well. Some of my company's libraries are C++ libraries and I wrote an open source simulation with every switch working of the Mercury Capsule and more basic simulation of the Gemini Capsule in C++. This includes ascent guidance calculations, and spacraft attitude control (http://www.ibiblio.org/mscorbit)

So I think I am qualified to say that Microsoft is dropping the ball on this issue. That if they don't pick up soon, someone else will and they are going to be in even more trouble in the future.

I am asking for the same treatment and respect for my VB Code they gave to the C++ guys.

The background you gave was interesting, but what I would really would like to learn is the specific issues you encounted.

Graphics made difficulty was required figuring how to translate VB6's scaling to GDI+ scaling. And overcoming all the subtle quirks between drawing in GDI+ versus VB6. Basically involving a lot of hours trying to find the right set of GDI Brush and Pen Parameters to make the different drawing commands work like VB6. Luckily I created a Canvas Class that drawing calls that allow me to switch graphics engine behind the scene.

Printing is still require a total re-write as the whole design flow is vastly different.

It is hard to do incremental testing with Integer and Long being different as copy and paste become a more involved operation.

Same for Gosub although the addition of the Extract Method re-factor made removing Gosub reliable and straight forward.

Having to re-write all the forms is time-consuming. Not being able to run the form code straight from VB6 in .NET make Winform problems hard to find. Plus we are less enthusatic about this since the annoucement that Avalon is going to be the new great form engine. So.. we are changing form engines every 5 years now?

.NET is slower in different areas than COM based VB6. This means we have to re-optimize. But then this would be true even if they have VB6 langauge compiling on .NET.

Plus any of the algorithms using one of the unsupported statements (see http://vb.mvps.org/vfred/breaks.asp) has to be re-written and re-tested. Particulary those dealing with binary data.

Lack of custom Lower Bound for arrays required a lot of math algorithms to be re-written in a matter that was less clear than the original.

Each of them are like little search and replace deal, but when you throw dozens out there it a whole new langauge. There was no reason to make so many change for the CLR.

Thank you. That's exactly the kind of stuff I think we should be screaming at MS about.

(Well, that and the ASP 1.1 to ASP 2.0 compatability issues. WTF were they thinking?)

This is the cost of using a prioprietary language, where you are at the mercy of a single vendor.

I'm curious to know what languages are sufficiently unproprietary and which have multiple really good vendors. Or does Open Source count even if there is really only one vendor? I'm not trying to be a jerk, I'm trying to find out what the options are. The first thing I think of is Lisp, oddly enough. I've been getting enamoured with Erlang, but it ain't perfect.

For open source languages with one implementation like Python and Ruby (well almost only one implementation), if you are upset about directions the language is taking, you can fork. Obviously this may not (and probably isn't) an option for you: maintaining a fork is a lot of work! (And you do want to get other work done, right?)

But it is an option (especially for larger companies). Plus, if there are significant enough changes that it effects you so bad that you would want to fork, then it probably effects other people too, increasing the chances that you could find a fork that is more suitable for your purposes.

So, open source halfway counts, simply because of the fork threat. Plus with open source languages there is always the possibility of modifying the language if you want (stackless Python).

MS Basic dialect has been relatively stable until 2001 until the release of VB.NET. Plus it was the most popular programming langauge ever so there was no reason to think that MS would break backwards compatibility as they did. Maybe a few problem would result but dozens of problems! Now we know. And the sad thing is that .NET adopter are facing this now with the impending advent of Avalon and the downgrading of Winforms.

MS Basic dialect has been relatively stable until 2001 until the release of VB.NET. [..] And the sad thing is that .NET adopter are facing this now with the impending advent of Avalon and the downgrading of Winforms.

Which makes a nice segue into How Microsoft Lost the API War: "The first big win was making Visual Basic.NET not backwards-compatible with VB 6.0."

I know, most of you have seen this before, but this thread wouldn't be complete without it.

I used Gosub for the same reason other languages supported nested procedures. And if you don't know about nested subroutines then you should read up on them.

Rather than axing gosub, microsoft should have supported nested subroutines. Then there would haven a one for one subsitution of the effected code with no behavior change. It would have been an improvement because now I would have scoping and parameters along with the other benifits of using a nested sub routines.

In my own software I used GOSUB as a nested routine because my rule is I don't create a subroutine unless another subroutine is going to use it. When you are trying to managing hundreds of routines across dozens of classes/modules it not always a good thing to just to create another routine. It not a good thing to have sphagetti code either or mountains of repeated code in the same routine, so GOSUBs were a reasonable alternative.

In addition until the first Beta there was no expectation that MS was going to axe GOSUB from the BASIC langauge.

Finally GOSUB is neither good or bad it does what it does. It been a part of BASIC since the earliest days. It should remain a part of the langauge. Arguements of langauge purity smacks of langauge religion and frankly I am not interested in that.

VB is a COMMERICAL product. I need stability and continuty. I don't live on Internet time instead I am just one of many thousands of small VARS that quietly make their living from Microsoft Software.

In my own software I used GOSUB as a nested routine because my rule is I don't create a subroutine unless another subroutine is going to use it.

Speaking as someone who researches coding standards and implements automated validation suites for them as a hobby, allow me to congratulate you on having created the #1 most bizarre coding rule I've ever heard of. It's got everything: crispness, surface plausability, and potential to cause enormous maintainability nightmares. You could even throw in a theoretically-plausible-but-too-small-to-benchmark performance argument, for even more points from the judges.

I'm sure it works fine for you, but... wow. Just wow.

If I've understood correctly, this is much like the way I use nested scope in Haskell - something belongs at top-level if it's going to be called by something that needs it at that scope, but if I can restrict the scope I do. In practice I tend to jump the way of sticking more things at top-level in languages that don't give me that flexibility though.

VB6 was an inconsistent programming environment with poorly thought out features. Any VB6 program that started as a simple concept sooner or later evolved in a messy spaghetti piece of code. VB7 is much better, and a step in the right direction.

What bugs me is why MS did not put out a proper language/decent framework all this time. With their experience, they could have easily put out a very good programming language/environment/framework and save million of people from the problems of MFC/C++ and VB.

I am glad they waited until Java matured.

Java, as you all know, has a lot of problems with its framework. There are classes with nearly every method marked obsolete because they figured out too late they were doing things the wrong way. I'm not saying .Net is perfect, just that it is a lot better that it would have been had it not learned from Java's mistakes.

This is not the first time that Microsoft broke with themselves. The VB3 to VB4 translation was very difficult at the time, as the way that forms and data access were constructed wasn't exactly painless in the transition. There was talk at the time of moving over to IBMs version of Basic, and we see where that revolt ended.

Personally, I think the biggest problem of going from VB6 to VB.Net has more to do with the underlying framework than with the language inconsistencies. The problem is that the way that forms are built and addressed is completely different. A translation requires that you not only get the raw language to map across, you also have to get all the fiddling bits to the components that was working in the old framework.

As Ehud once said (roughly speaking), VB is not really so much a programming language as it is a product. As a product, the goals are not necessarily related to what makes sense as a PL, but rather what makes sense in terms of what one does with the product.

I managed to dodge many of the issues by starting the VB3 conversion with VB5. But while VB5 was better, what was critical for the conversion was ability to run the VB3 code with VB5/6. We could fire up VB3 do the operation in question, do with with the new Software, then do it with the VB3 Code running in VB6.

This way we uncovered all the VB5/6 form quirks and changes and altered the UI code accordingly. This is compared to an earlier conversion where we had to guess is this because of our design? or it because VB3 forms is not doing what we need it to do.