Kids today probably don't realize, but for its purpose, VB pre dot net 2001 was really really good. Especially compared to the c plus plus alternative available at the time, atl, and so forth. I know the criticisms of basic as a language, technical snobbery, etc.. But for building stuff quickly, it worked. And for an ide, was really snappy and fast. That deteriorated when the VM was introduced, dot net.
You start a project, a form appears. You drop controls on it. You set their properties. You code their event procedures. Press the play button. Compile. Exe. Done. It was a great product in that it abstracted the messy stuff well, and presented a programming environment that was intuitive and powerful.
Not only that. Compilation was super fast, the debugger was pretty damn good, creating OLE objects was a breeze (every class had the full machinery to become an OLE object just by flipping a flag in the properties editor), writing networking code was super simple (VB's built in events would take care of the asynchronous nature of receiving data), installation builder... I could go on. It was light years ahead of the closest competitors (Visual C++ and Delphi.) People love to hate Visual Basic, but for its time it was revolutionary.
I agree with most of what you've said, except for it being light years ahead of Delphi. I used both tools extensively in both a hobbyist and professional capacity from 1997 onward (VB 5, Delphi 3) and I couldn't say that one tool was significantly ahead of the other. They were both hugely similar and fantastic for rapid development. In fact I'd go so far as to say I preferred Delphi as its database capabilities were better (at least, in my experience) and I liked not having to package my software with a set of run-times. Although the latter was more important to the hobbyist side of me. Commercially, demanding a client had the required VB run-time files was no problem.
Delphi was a great tool! The database support was way ahead of VB, specially support of MySQL and other third party databases. I guess I always preferred C/C++ over Pascal for low-level stuff though, so even though I played around with it for quite a bit, I never became too proficient.
I hoped C++ Builder would close that gap with Delphi, but then .NET took over and the rest is (kind of) history.
What's fascinating to me is that some countries (Brazil, for one) still have a very active Delphi community, while in a lot of places it was more or less forgotten.
That's right, Brazil, Russia and China still have huge amounts of Delphi developers. To a lesser extent so do South Africa and Australia.
Would you believe me if I told you I currently work in a software house whose main suite of desktop products is still in Delphi? We've been using .NET since the mid-2000s (before I started here) for a few of our products, and all new development for desktop products in the past few years has been .NET, but the company's bread and butter and highly successful products are Delphi applications through and through.
It's still a capable development tool but the language is showing its age. I very rarely have to touch it any more but when I do I always get mixed emotions of "argh, Delphi sucks ass, I wish it had <insert any .NET language feature here>", and "oh man I forgot how awesome Delphi was, I wish it was this straightforward in .NET!" Comments such as the latter are few and far between, these days.
That's not surprising! Some really good enterprise and POS software got developed in Delphi (and other desktop frameworks/IDEs) back in the day. In Brazil a lot of businesses were starting to adopt POS, and having someone building a billing program for you was all the rage. There's little incentive to update such systems as long as they work. Not everything needs to be a website! (shakes walking stick and shouts to kids to get off his lawn)
I remember hating .NET in the beginning. Performance was abysmal and anything mildly low-level took a lot of work. I made some good money as a freelancer writing COM libraries or C++ libraries with a thin C# wrapper so that they could be used by companies that had bought into the whole .NET thing.
Then C# introduced generics, and it started breaking away from the similarities to Java. Things improved and in time .NET became a very capable runtime/framework. I'm actually excited to see Microsoft finally opening it up. As much as I love Python, the cloud and all the fancy new stuff we have nowadays, I occasionally long for the good old days when desktop software reigned supreme.
OK, better go to sleep now. I'm starting to sound like an old fogy :)
Interesting bit aside: The current Delphi versions are becoming better again, to the point of actually being usable. Now it's just that its reputation was ruined when Borland decided to f*ck it up. I'm using it at work to build an Android app, and despite the slow buggy IDE, I'm more productive with it than with IntelliJ (for Android dev) or Visual Studio (for Windows apps)...
That is an impressive statement. Can you share some link about Delphi new Android capabilities, I was not aware it could handle mobile. I think I am stuck in the 90s Delphi.
On Windows, Borland was always late with SDK support so we were forced to write our own wrappers. I gave up by Delphi 1.0, after being mainly focused on Turbo Pascal since the 5.5 version.
Regarding Kylix, I would say it was badly managed from the start.
So yeah, eventually the way out for better Windows support was C++/MFC, as even Borland's C++ compilers had their own set of issues.
But, this is a big but, if Borland managed to push Delphi the same way Sun pushed Java, then I think the mindshare story would be quite different.
A memory safe programming language, with RAD tooling support, capable of system programming tasks with native executables.
VB (and developers like me) always took a fair amount of heat for a "toy" development tool. Likewise HyperCard, which I used before VB. Yet the productivity achievable with those tools, for the right kind of project of course, was game changing for those of us who otherwise found UI development to be either onerous or forbidding.
I had simply assumed that VB was Microsoft's attempt to one-up HyperCard, and it's very interesting to learn about VB's real origins.
I developed industrial process controllers using VB. A stripped down Win3 or Win95 system running VB was actually virtually crash proof. Of course this didn't prevent me from incorporating redundancy into the hardware, to take the machine into a safe state if the PC stopped working for any reason.
What the dot net version seemed to do, was to make VB the equal of the other Microsoft languages, feature by feature. The result was that they lost the reason why VB developers loved VB. I continued using version 6 (pre dot net) for several more years after that.
I agree with you, but there are some interesting gotcha's in this. Windows 3 accumulated cruft and needed to be cleaned or rebooted regularly. The company I worked for in the late 90's had a public safety customer that ran our code on a Windows 3.0 box, I can't remember the time interval, but periodically one of our developers would go on site and (in NuMega SoftIce - which we habitually ran everywhere) would reset the windows tick counter, and flush crap out of various OS handles tables.
Having done low-level messing about on 16-bit windows, when I moved to Redmond and started working for MS it was hard to drive past BurgerMaster without buying something in homage.
That's a good point, and I may have done inadvertent cruft cleaning just by updating my program periodically, since it was so easy to just reboot the system.
VB 6.0 was what got me into coding when I was thirteen. I am infinitely grateful to it. So many memories working with WinSockets, OCX, and pressing that play button.
VB.NET is all of that except even easier to work with and more sensible, plus interop with any other .NET language. VS for VB.NET is not slow at all. I used VB.NET throughout a high school class and recently had to modify some VB.NET I found in an open source project to adapt it to my project. It was a very smooth procedure even after not having used the language in years. But with having C# now, I don't think there's much reason to write VB.NET instead of it unless you're working on existing VB.NET code, even though it does have a few nicer spots like the convenient Sub ... Handles myEvent where in C# there has to be an explicit += somewhere, and a few other small things; however, overall C# is more powerful.
C# is not really more powerful. Functionally, there aren't really anything you can do in one you can't in the other.
I personally got used to the convenience of a case insensitive language and I usually write throw away scripts/analysis more than systems, where having a language you can type fast with few bugs is important. For that purpose VB.net is fantastic.
No, no, no! I work in both on a daily basis, and have done since 2006/2007. Around 2006 I started migrating Delphi code to .Net for an employer (they had a lot of VB.Net already through acquisitions). Then circa 2007, I started at a company that used a VB.Net 1.1 codebase, upgraded it through to 4.0 adding in a lot of C# assemblies and extensions along the way - culminating with a complete refactor of all key components in to C#.) Now I work with a codebase that is mainly VB.Net but all new code is in C#.
VB.Net is a horrible language that lets developers get away with some really awful practices. The fact that the various Options are still present, and not on by default, is a recipe for disaster. That this is legal:
Sub Main
dim x as boolean = false ''or true...
dim y as integer = 0
select case y
case x
Console.Write("What does this even equate to???")
end select
End Sub
end case
or that this is legal:
Class SomeArgs
Inherits EventArgs
public Property Message as String
End Class
Class HorribleCode
Public Event Blah(ByVal sender As Object, ByVal e As Someargs)
Public Sub Doit()
RaiseEvent Blah(Me, new SomeArgs with { .Message = "Wow... YUCK!!!!"})
End Sub
End Class
Public WithEvents ThisSucks As HorribleCode
Public Sub ThisReallyWorks(ByVal sender As Object, ByVal e As Someargs) Handles ThisSucks.Blah
System.Console.WriteLine(e.Message)
End Sub
Sub Main()
Dim h As New HorribleCode
ThisSucks = h
ThisSucks.Doit()
End Sub
Yes, I dealt with code that had both of those "techniques" in it... ugh.
The second example was mainly because the off shore coders didn't realise AddHandler/RemoveHandler existed... le sigh
Not sure I follow your point. You can write really bad C#. And you can write even worse c++. The quality of a language isn't about how bad you can twist it if you decide to be reckless.
In fact I must say one of the things that I appreciate the most about VB, beside case insensitivity is the IDE. I think c# is catching up now but the VB IDE is incredible in term of how much help you get, immediate feedback on what went wrong, rich auto-completion of code.
I got my start into programming with VB6 (or maybe it was 5). After reading through a Windows programming book for C++, which I understood nothing from, I almost gave up. Until my father got me a wonderful tutorial Visual Basic 5/6 for Kids (http://www.kidwaresoftware.com/vbkids.htm).
First day in, I had a form with a button. Clicking the button would change the form background colour to blue. I had to restart the app to get the form background back to the default one so I could demo it again, but I still remember how excited I got over that one simple thing. I would show it to everyone in my family.
If it hadn't been for that, I'm not sure I'd be a programmer today. Just an amazing product for it's time.
I loved VB6. Programming games in it using DirectX, in my cracked copy of VB6 when I was 13 was one of the first forays into real programming. I still remember being super confused about double-buffering way back when; my initial game programming in VB started with picking up key events and moving an image around, but it was blurry and laggy, afterimages galore and impossibly to composite correctly. That's when I found DirectX. Not long after I moved into working with web technologies, and the rest is (my) history.
It definitely depended on whom you talked to. Folks in the "business" world generally respected the productivity of VB, as it was used for a lot of the little custom apps that people depended on.
But there were also a lot of developers who thought that VB programmers were the script kiddies of the day.
You start a project, a form appears. You drop controls on it. You set their properties. You code their event procedures. Press the play button. Compile. Exe. Done. It was a great product in that it abstracted the messy stuff well, and presented a programming environment that was intuitive and powerful.