I started programming in VB6 so this is a little sad, but I'm actually surprised it has made it this far. I see C# everywhere but can't remember the last time someone told me they were using VB.
The end of Visual Basic.NET, that is. "Classic" Visual Basic has been ended for a long time now.
(And VB.NET is much less of a loss -- it was never as popular as classic VB. Even when it first came out, it was clear that if you were a VB developer, Microsoft really wanted you to move to C#; VB.NET always felt like an afterthought, a fig leaf they could use to say they really weren't abandoning VB when they obviously were.)
I totally agree and felt that such that after I went through the pain of learning VB.NET, I felt rather silly when I took a look at C# and realized I had learned like 99% of the whole thing is just the .NET ecosystem, so picking up C# was pretty quick.
Did the same thing, but in my mind, 50% of knowing a language is muscle memory, you type without even thinking about it because there is zero doubt or ambiguity about the syntax, even anticipating the reaction of the IDE as you type.
That’s why when I switched from vb.net to c# (when microsoft announced they were deinvesting in it 2-3y ago), I stopped writing vb completely. It is hard to fit two languages in muscle memory (unless the syntax is pretty close).
For me, the switch to dot-net meant that continuing to upgrade past VB5/6 no longer held any particular advantage over switching to some other language altogether, not to mention possibly some other operating system as well. I ended up in the Python camp, where I reside today.
Edit: I should also mention that VB5/6 got me away from HyperCard. I loved the idea of being able to draw my GUI, and not having to screw around with writing my own event loop.
With VB, I liked that it was "object based," by which I mean that you could use objects provided by the tool without having to create them. This was a great way for me to ease my way into OOP. By the time I wrote my first object, I already understood what objects were useful for.
IIS ASP and the Shell CScript/WScript hosts are just environments for the COM-based Active Scripting engine.
At the time it was very capable as lots of software titles opened themselves up to automation via COM - that's why you could have Classic ASP pages that invoked Office Excel to generate charts dynamically.
Unfortunately it was all a mess, but it was also something beautiful because it meant that a desktop/server OS was more than just a place where heterogenous applications could live: they could truly interact with each other regardless of their programming language or runtime platform.
That grand vision - itself an extension of OLE from the early 1990s - died down with the rise of .NET (this wasn't intentional - Microsoft just had a lot of reorgs around that time and COM was more-or-less feature-complete, and no-one was really using DCOM) - but with Windows 8 and the "WinRT" API I was hopeful that COM would be back and new ways of automating applications would come around, and that Microsoft would have a great system for non-programmer users wanting to build workflows like they can with Apple's macOS Automator and AppleScript.
This also ties-in with the do-as-little-work-as-necessary being done for VBA support in Microsoft's products. While we all wish Microsoft would allow modern JavaScript as a first-class COM automation language - the Office VBA runtime only supports its own VB6-dialect (the VBA language), and while Active Scripting supports JScript (a snapshot of JavaScript version 3 from 1999-2001) it doesn't support static typing nor is any of the tooling inside Office compatible at all. - so instead we have JavaScript, but only for "Office Apps" which don't offer anywhere near the same kind of integration or control over Office applications (or things like filesystem access) that VBA does. It's like it's 2008 again and everyone's excited about the new iPhone OS App Store and thinking about all the cool iPhone OS system extensions they'd add, like a Today screen or a camera app that can record video by using low-level camera hardware APIs - only to be discover Apple will only let-in apps using nerfed and siloed high-level APIs that take away all of the fun from extending an OS.
I wouldn't say that COM died with .NET - .NET had COM support baked deeply into the platform, to the point of language hacks where to this day, you can "new" a specially defined interface in C# (originally it was a way to reference the associated default coclass for a COM interface, if any). It's very easy to use and create COM libraries, and WinForms fully supports ActiveX controls.
Even as late as 2010, COM support in .NET was still being developed - C# 4 got named indexers for this reason alone, and its "dynamic" supported IDispatch out of the box - its main scenario being Office automation.
I argue that COM "died" when .NET rose in reference to the COM ecosystem because prior to the release of .NET on Windows most non-Java developers were writing in either VB6/Delphi or C/C++ for their desktop applications.
VB6 and C++ (specifically, Microsoft VisualC++'s __declspec-punctuated dialect at least) were both intimately connected to COM with their respective compilers have built-in support for DOM/DCOM/etc (e.g. VC processing IDL files and generating TLB files, while the VB6 compiler seemingly reads-in TLB files natively - and can generate its own too) - and all major components for Windows desktop development (such as ADODB for OLE and ODBC database access, the Macromedia Flash player, OLE objects in general, and VB-ecosystem "components" like charting widgets and new styles of buttons were all done using COM - which means programs written in VB6 running in the VB runtime could use the same GUI components and platform feature libraries as C/C++ code running in its own world - that is cool!
While .NET is fully compatible with COM - the ecosystem isn't the same: WinForms and WPF GUI components written for .NET now cannot be used by VB6 forms or C/C++ windows (at least not without hosting .NET in-process and then facing additional issues integrating your Win32/User32 GUI with a WinForms hosting surface) - while hosting COM GUI components in WinForms is straightforward and just like VB6, hosting a COM GUI component in a WPF environment is very, very painful (google "wpf airspace" to see why this is a bad problem).
Additionally, consuming COM from .NET (even VB.NET) isn't as easy or as straightforward as it is with VB6 either - as you have to contend with the ISA of your .NET process (e.g. you can't load 32-bit COM components into an x64 .NET process).
I feel the amount of third-party software on Windows that offered COM automation has dwindled in recent years because of those reasons.
I think we need to distinguish between COM and OLE/ActiveX here. COM interop in .NET is two-way, and the consumer doesn't even need to be aware that there's a VM running the code that they're invoking. OLE is much more challenging, because the UI framework needs to be aware of it, and because it's built on Win32 UI primitives - so any framework that doesn't use those is going to have issues much like WPF (Qt is another example).
Bitness is not a new problem - VB6 similarly has problem consuming COM components written in C++, but compiled as 64-bit. Or, to put it another way: VB6 didn't have a problem, because 64-bit wasn't a thing back when it was popular, and didn't really became common on Win32 until relatively recently. But in a similar vein, if you always compile .NET code targeting x86 rather than AnyCPU (which is the default for new .NET VS projects - not sure when that changed, but it's been several years), you get the same exact behavior as VB6.
Getting back to OLE and ActiveX - I would say that it was killed by Microsoft directly, not because of .NET. Back in the day, most non-trivial Windows apps made by MS supported OLE for embedding - this was most commonly used with IE, but you could also do it with e.g. Word and Excel... until you couldn't anymore. If I remember correctly, it was Office 2007 that killed it as an officially supported scenario (you could still do it, but if anything broke, you were on your own). That roughly coincides with WPF, and I don't think that's a coincidence - but it doesn't mean that WPF/.NET was the primary cause.
> COM interop in .NET is two-way, and the consumer doesn't even need to be aware that there's a VM running the code that they're invoking.
I understand that's because .NET components loaded into a native process via COM are done so in-proc but using a single instance of the CLR, means you can't have .NET 2.0 CLR and .NET 4.0 CLR components loaded at the same time into the same process. I also understand (but am unsure) about what this means for AppDomains.
.NET Core simplifies things considerably: by being utterly broken when it comes to COM support and generally requiring each .NET Core program to have its own independent process rather than supporting multiple AppDomains in the same process (okay, that's a bit of hyperbole: .NET Core supports strongly-typed COM objects but they removed support for using `dynamic` with late-bound COM objects - and I can't find any documentation regarding loading .NET Core components via COM into a native VB6/C++ process.
> But in a similar vein, if you always compile .NET code targeting x86 rather than AnyCPU (which is the default for new .NET VS projects - not sure when that changed, but it's been several years), you get the same exact behavior as VB6.
I understand the default for .NET Framework application projects is still AnyCPU but a new option called "Prefer 32-bit" is selected by default. Whereas for library projects and all .NET Core projects the default is AnyCPU ("Prefer 32-bit" is only an option for *.exe projects).
> If I remember correctly, it was Office 2007 that killed it as an officially supported scenario (you could still do it, but if anything broke, you were on your own).
> That roughly coincides with WPF, and I don't think that's a coincidence - but it doesn't mean that WPF/.NET was the primary cause.
I understand the reason was because very few applications in the wild depended on this functionality (that's what Microsoft's telemetry in Windows is for) - I think the only real application that made full use of this was MS Binder (rip 2002) - and I only ever got annoyed at the times when Internet Explorer would load Office Word or Excel directly into the browser shell.
Office 2007's radically redesigned UI required much more screen real-estate - whereas Office's support for being loaded into an OLE window was back when people were running at 640x480 or 800x600 (if you were lucky!) and Office had 16px-sized toolbar buttons - which is another reason to avoid wasting developer time working on it.
> I understand that's because .NET components loaded into a native process via COM are done so in-proc
That's not necessarily so. By default, a .NET class exposed via COM is free-threaded, so it'll be instantiated in-proc. But you can have all the same complicated apartment arrangements as with native - and marshaling is done via type libraries that are generated from assembly metadata. So if you want an out-of-proc COM server written in .NET, it's quite possible.
> but using a single instance of the CLR, means you can't have .NET 2.0 CLR and .NET 4.0 CLR components loaded at the same time into the same process.
If you use in-proc components, then yes, the runtime is loaded. But .NET 2 and .NET 4 runtimes are intentionally designed to be possible to side-load. They don't see each other as .NET, of course - so if you take a reference to an object in one runtime, and pass it through native code as a COM reference to the other runtime, it'll see it as an opaque COM component.
.NET Core is its own thing - it's clear that everything Win32 is legacy there, including COM. I was surprised it even got WinForms...
The new ways of automating applications is Powrshel with its COM/.NET/DLL integration.
And UWP as modern COM is here to stay, no matter what, Microsoft seems to be willing to spend the money to keep it going, even it requires a new programmer generation.
Exactly. The writing was on the wall all the way back in 2001. It’s basically been a 20-year-long transition, and one has to admire Microsoft’s dedication to their developer userbase in that area.
Definitely. I was a huge fan of VB6, spent thousands of hours writing all kinds of things. When I first heard of VB.NET, I was excited to see what new features were implemented, expecting something like VB4->VB5->VB6. Boy was I in for a surprise. It seemed more like C wrapped in VB syntax. I started looking to other languages at that point, but as some other posters said I never found anything quite able to match the rapid prototyping GUI and debugging features of the VB6 IDE.
I never did VB6 or VB.Net, but I've done VBscript with classic ASP and VBA in Excel. Glad I went with C# instead of VB.Net.
Not trashing VB, but C# was always more capable and fully featured than VB (VB couldnt even do unsigned integers, and I dont it can even now), and almost immediately more widely adopted in even .Net 1.0. Hell, C++ with COM was more capable (if not extremely annoying amd error prone). Of course VBscript and VBA share very similar syntaxes, but they're not the same languages or std object models/libraries, just maybe 95% similar.
Thing is, it was never about language capability. VB6 with COM was still faster in terms of development cycles for people used to the woes back then. Though I'd argue that the few differences there were between VBScript/VBA and VB6 made it much more capable from a development perspective back then... Most of my VB6 bubble moved to VB.Net during the transition, the widespread move to C# with those folks came years later when it became somewhat inevitable. After all, for the typical type of application, language is honestly mostly irrelevant as long as it does not get in your way.
All this feels a little like history repeating itself. We even naively made up a petition back then to keep VB6 around, somewhat glad that led nowhere in retrospect. A few decades ago I loved that the VB ecosystem was approachable and combined beginners and professional users. I somewhat think we have enough other good tools that fit this description these days, some of which incidentally even come with a good programming language.
In terms of data structures, absolutely. Thing is, for a lot of applications you don't need all those extra features. Lots of apps are boiled down to "The user inputs this, I do some crunching, they get this output." Whether your ints are signed or not doesn't matter because you're only counting from 1 to 100 anyway. One thing it did do very well was to make string manipulation and conversion simple.
I loved VB6. Of all the languages and IDE's I've ever used, I've never been more efficient in any other one.
As long as MS doesn't break my workarounds to run that old IDE or its EXE's, I'm happy. VB.NET was a great stepping stone, but after switching to C# I never looked back. The only thing I miss is global functions that don't need a class qualifier in front of them. And I still find the Edit-and-Continue debugging experience in C# hit-or-miss.
I used to think this too, but everything you can do in VB6 you can do in powershell, and do it better. Try/Catch, windows forms.. literally anything you can think of.
You can even mix powershell and C# together in the same script.
Once I realized I had a better version of everything I wanted, it became my new favorite.
Possibly, though bash is from a much earlier time when shell scripting language design probably wasn’t a very well known topic and bash evolved more naturally from open source. Powershell is much more recent plus had much more complete control over the language to prevent the kind of syntax warts bash has. Even then I would still probably take bash over Powershell for scripting but that’s probably more because of familiarity than anything else.
The first release of bash was in 1989. Shell scripting was already a thing at that time. Csh and ksh were also around for roughly a decade at that time. I think you are confusing bash with sh with this kind of statement.
The decision to make the console output as the return value of a function alone almost destroys it for larger scripting projects. It’s a really bad decision and they could still fix it by adding some environment variable that disables this “feature” while staying compatible with old scripts.
It seems like it might make some kind of sense, since it doesn't output directly to the console but rather to a pipe. Bash functions sort of work the same way since they don't have complex return values (aside from exit codes) other than the function's output stream.
Yeah, keep in mind that the output is a fully-fledged object, it is not the text you see. The text is generated by the PowerShell host if the returned object makes it back there and the host is set up to present that object to the user that way.
Take the following in PowerShell:
ls | sort DateTime -d
ls returns an array of objects, sort then sorts the array by each object’s DateTime field (and here I’m asking it to sort in descending order with -d). The point is that sort isn’t depending on any text output, so it works with any array of objects regardless of the command that returned them.
The other cool thing this enables is auto-complete awareness in the shell. If I typed:
ls | sort <Tab>
then the shell knows what makes sense in auto-completion here as ls has an actual return type and in this case it will give me a list of available fields that I can sort on.
For those unfamiliar: ls and sort here are shortened aliases to more wordy verb-noun commands. These (as well as a large bunch of others) are given to you by default.
It isn't inevitable by any means, fish shell scripting is clean and pleasant.
I use fish as my command line, but I still write scripts in bash, even personal ones I only expect to use on my own machine. Just out of a vague sense that I might reuse it, or it might escape confinement, or something.
Is it widespread? I've never seen anyone else using powershell 'in the wild', admittedly for the last 3 years I've mainly worked alone, but I still see people using CMD scripts.
I usually get frustrated with it and bash out a quick cmdlet instead.
It’s pretty widespread if you have to do sysadmin scripting. There are a lot of useful cmdlets. I am embarrassed to admit that I also run it on my Mac with good success.
sysadmins who are fully invested in the MS ecosystem do use it a lot. People doing cross-platform work, don’t.
In terms of wider adoption, it suffered by maturing at a time when a lot of people had moved on to more powerful devop solutions. And of course, being MS tech (although technically it was acquired), it carries a stigma.
I just found it un-intuitive, ugly, and verbose. Compared to my beloved python it looks really really bad.
CMD is the worst language I ever saw. It's full of hacks for simplest tasks. The only reason I'm using it is for old systems where PS is not preinstalled.
I used PS to write small scripts and I actually like it. I'm more fluent with bash, but that's only because I used bash a lot. PowerShell feels more robust, no silly space-in-filename problems, no silly parsing of text output to access fields. May be it's ugly for big scripts, I don't know, for me it looked like a vastly superior version of shell.
I would love to learn why people think that power shell is ugly, especially comparing with bash.
Verb-first was also a bad choice. When I type “get” I am getting thousands of suggestions which makes autocompletion pretty useless. There is also no way to find all cmdlets that deal with active directory. It would be much better if I could type “AD” first and then get all cmdlets that deal with active directory.
I don't think it's that bad. Better than bash where every command has is either something archaic or just what whoever wrote it wanted it to be. It better resembles English than the other way around. Plus you can use "get-command "something`" which gives you everything that contains that string, or search for a certain provider for all commands related to a specific thing.
Autocompletion still works, just type first letter or two after get and filter most stuff out.
Powershell was made to allow launching arbitrary programs with redirections and pipes. That's why some language choices were made and that's why I'm interested in comparison with bash.
For me the big problem is that I know it can do loads, but it's not C#. So between the awkward wait for it to boot, the stupid naming convention, and the knowledge that the whole power of the .net framework should be at my finger tips, but in a really alien and unintuitive way, I prefer to either write a really small bat, or write a small C# console app.
And so I never become comfortable with it, even though I've tried several times since it was released.
The newer IDE is pretty good too.
But C# shows what it could have been if they'd had a talented language designer do it (which no-one can determine if someone is beforehand I admit).
I just wish they'd admit defeat and just use a subset of C# instead of stubbornly sticking with something that seems fairly widely loathed.
I don't find it ugly, just strange. It's optimized for interactive usage though from what I understand. I think of it mostly as calling .NET methods that all have named parameters:
myfunc -param1 this -param2 that
instead of:
myfunc(param1: this, param2: that);
I get the impression it's designed with the intent that you're supposed to type the dash, then hit Tab to get tab-completion in most cases. Same with the verb/noun syntax (I know I want to 'Get' something, so typing Get-<Tab> for the list of things is usually the thing to do). I do find it a bit difficult sometimes to think of an approprioate verb right off the top of my head (is it Get- or New- that I need?).
I'd also love to see the concept of proper namespaces in PowerShell; it seems really inconsistent right now (unless I've missed something). For example, type Show-Command and hit ENTER, then look at the different modules that are available. Some will express a 'namespace' by having it prepended to the noun (see for example, commands from the BitLocker module, their nouns all start with BitLocker) while others express no namespace at all (see for example commands from the 'Dism' module). For everyday use I've gone with the 'add the name to the noun' approach in my own scripts. That does mean I tend to use short namespace names though.
I've mentioned this in an older PowerShell-related thread here - MenuComplete is absolutely awesome and improves the PowerShell experience in the console. I actually think it should be the default. If you havent already, try these commands:
PowerShell is my full-time shell in Windows now (and it will be in Linux also when I get back into it); I rarely use CMD for anything and parsing text in bash just seems antiquated.
Yeah, I write a ferocious amount of PowerShell it's an amazingly bad language. I use it for its API, but its language design is a nightmare.
I'm not talking about its unorthodox syntax - that's the least of its problems. The language is hellishly inconsistent and has an inexcusable number of legacy issues for being so young.
And the quality of the standard library is poor. More and more often I find I have to drop down into .net commands to work around showstopper bugs in their PowerShell wrappers.
>but everything you can do in VB6 you can do in powershell
Excel modules? OK not quite exactly the same but close.
I wrote a finite capacity planner system for a factory a fair few years ago in Excel to replace a huge number of Lotus 1-2-3 thingies with a vast amount of copy n paste from text screens and random sheets and what not.
I started with an automated forecast. We used an (memory may be fading) exponential fit which worked best using previous four weeks. eg last four Mondays would generate next Monday's demand.
The forecast could be tweaked by Planning at any time (aaaaiiiieee - Christmas!) The forecast was then fed into prep, make, bake, wrap and then dispatch. Between each process there is a stock holding. This is food so there are quite a few constraints on time, that's why we are making to forecast and not order. The customer will generally order your forecast if you are good enough and that is the whole point in the supply chain to the multiples: you know better than they do what will sell of your product.
The forecast cranks through the processes and stock points and generates a basic plan. It shows what efficiency is needed from each machine and the amount of manning etc. Oh dear you've got a Rademacher running at 170% which is a bit unlikely (110% is fine because 100% does not mean what you think it does in this industry - its a rate that is easy to achieve and not the absolute max). Oh and that machine is due 10 hours maintenance. Crap. OK, Mel off of Planning: do your thing ... a few parameters are tweaked, some production is offloaded to another member of the group and a packet of Hobnob biscuits is dispatched to a factory 200 miles away. The amended plan is run back through the model to ensure it satisfies the inputs and then when that is OK it is fixed for now.
I have not given too many details here as to specifics. I used a huge number of vlookups and I had a lot of code that ran through tables looking for the word "End" to indicate the last row (but one).
I basically found that VB gave me enough logic and whatever to get the job done in a reasonably safe way but without getting in the way of the business logic. I could concentrate on getting the job done.
Nowadays I'm a Linux (Windows and NetWare (lol)) sysadmin who masquerades as a PHB or MD but I still have a fondness for VBA. I recall getting someone's neural network spreadsheet VBA monster working after the most unlikely helpdesk call ever.
PS wasn't invented when my smart new Pentium 60 was crunching the thing I wrote about above! Cripes: OLE was the latest whizz bang thing in Windows back then.
I'm pretty sure that if you partner with someone that can package your food supply chain knowledge into a nice UI/UX experience (or doing it yourself, idk), you could produce and sell a decent piece of niche software for planning in food plants.
At $work we are into software for managing plants (not in the food industry), and the demand for tailor made planning functions is obvious.
I'm a PHB these days but I'm 2/3 the way through building a Prusa 3D printer so all hope is not lost. Also, unlike most other MDs, I have a soldering iron and a fair few ESPx devices on my desk ...
When it comes to classic VB (aka VB6) it isn't so much what you can do but how you do it. After all everything that was possible with VB6 was also possible with Visual C++.
Working in a windows environment you often end up dealing with powershell already .. which means you don't have to learn another language and ends up simplifying everything.
Quickly and easily design and make a GUI program with n real training?
VB6 got me into programming as a kid.
I mostly use python for stats stuff. I sorta understand how to run up a GUI using tkinter, but it seems like a huge pain in the ass.
I'm sure Visual Studio offers the ability to do whatever VB6 could with a GUI, but it isn't obvious how to get there.
VB6 was one nice thing - build 'a program' as you understand them in Windows. Why the fuck is it so hard nowadays? VS isn't intuitive - it's a firehouse of information and I feel like you need training to use it. That is a bummer.
I just want to Lego-assemble a cute GUI-based program that I can make into a binary and email my wife to use. But I need to dedicate 70GB and two weeks of study to get there, I guess.
HTML/JavaScript. That has the shortest start-making-a-GUI story (plain JavaScript; React/Webpack/etc. absolutely do not have this level of accessibility).
No wonder so many programmers stick to boring business apps! ;-)
I got into coding qbasic (meh) & amiga (yeaaah) game engines in the 80s.
Currently teaching kids with Computercraft, to manipulate virtual worlds rather than boring spreadsheets.
IMO that sort of computer work will be obsolete by the time today’s kid are grown.
I’d probably avoid more than basic coding in general anymore and focus on math-y stuff. Just my take on where need will be, and discussing this with education researchers, and other thinkers.
I have a hard time believing we’ll carry as much code from the last couple decades as we had to from the previous few.
So much of it these days is web ui’s with a short shelf life relative to foundational code we shlepped forward in kernels, banking, and complex industry systems.
Scratch is the easiest way to teach programming to kids in a visual way. Much easier than VB, you can start at a younger age, but you can’t make real apps. You can however make games and control devices like the microbit.
The progression from there is python for those who want to control devices, or web dev for those more drawn to the visual design part. A missing piece is something for making games that sits in the middle of scratch and C++/unity. I don’t know how kids make that transition.
I think Xojo was known as "RealBASIC" in the late 90s/early 00s and was really in the same spirit (but more cross platform) as VB6.
HyperCard occupies the same spot for me that VB6 seems to occupy for you. Today for stuff I'd have used that for in the 90s, I just stand up a quick little web app and text or email a link.
That's in no small part because nearly all of my wife's computing is done on an iThing and not on a computer that she could readily download and run something on. Unless I want to throw my cute GUI in an app store, it needs to be web-based now.
Eh. VB6 was paid too. IIRC it used to be on the order of $600 to get the standalone version.
I downloaded Xojo and kicked the tires. It was absolutely cool to see that an environment like this lives on. It really does feel like a successor to VB6.
Oof. I hate powershell studio. It weirdly splits up the files and none of them are .ps1 and they obliterate all good standards and practices forcing you to leave arbitrary code in the project so that theres no way to know what pieces fit with what. Youd sh*t yourself if you saw how the Sapien community handles not blocking the rendering thread that their GUI forms run on (so it doesnt literally freeze up and crash).
>>VB6 was one nice thing - build 'a program' as you understand them in Windows. Why the fuck is it so hard nowadays? VS isn't intuitive - it's a firehouse of information and I feel like you need training to use it. That is a bummer.<<
Great question. And I agree with the sentiment.
My opinion for "why is it so hard today": it has to do with the way .NET evolved right after its birth. .NET was a response to Java by Microsoft. What Microsoft did in effect was attempt to smother the Java juggernaut by introducing their own Java with J++ (Anders' team) but only available on Windows (their attempt to prevent the allure of Java's platform independence).
By all accounts that attempt was an astounding achievement from Redmond. It boasted interactive tools to create GUI drag and drop features users were accustomed to in VB6 but glaringly missing in the Java world. This was with Visual Studio 97. Then the lawsuits with Sun came. The aftermath of the J++/Microsoft Java debacle was the beginning of .NET. A "Java" for Windows with attendant crazies of the Java world. This is the reason why it is hard. Java was "hard" compared to VB6, therefore .NET had to be hard in the same way.
All analogous complexities associated with the Java world: build tools, runtime versioning tools and intermediate code compilers etc were forever required, keeping this huge katamari ball of technical debt alive for over 20 years.
Now we have .NET Core. So we've just reset the clocks and in one swoop gone right back to 1998 with a new Microsoft Java but this time it is cross platform!
22 years of a meandering path that ends up right where we started!
> ...astounding achievement from Redmond. It boasted interactive tools to create GUI drag and drop features users were accustomed to in VB6 but glaringly missing in the Java world. This was with Visual Studio 97
Thay were not "glaringly missing in the Java world" in 1997 when Visual Studio was released. By that time at least these 2 IDEs with "drag and drop" were released and used already: Symantec Visual Café (a good one!), and a beta of IBM VisualAge (second part of 96). VisualAge came with specific ibm's understanding of drag and drop, however the Visual Café's experience was really similar to VB and much easier than J++ from what I remember. I tried all of them at the time including JBuilder and Sybase. JBuilder was my best for quite time.
In 96 there was also Xelfi which later became Netbeans.
The original version was an attempt at Delphi for Java and I liked it far better than Netbeans later, but I came from Delphi to Java so that makes sense.
Doing .NET and Java nowadays, started using Borland products with Turbo Basic, jumped into Turbo Pascal 3.0, all the way up to Delphi 1.0 and C++ Builder, before caving in to the MFC world back then.
Delphi club membership is only for those who possess a ruthless, deep and time-transcending sense of commitment to these two aspects of software development:
1."No bullshit" - stick to the fundamentals and don't waste time over-engineering, relying on complex builds, producing ambiguous compiles (ok, we're still fixing this), relying on bulky runtime architectures. Have straightforward source code. Native. Straight-talking. Quick-compiling. Hard-hitting. Because Shipping Matters(tm). Only thing that matters. Shipping. No bullshit.
2. "Fiercely independent mindset" - Members know that they must use the right tools for the right job, but members must also display a strong ability to not be swayed by what employers are hiring for. Latest shiny flavour of tech, framework, language, might look good on your CV but many times the conclusion for "What is the right tool for this job?" can still be answered: "Delphi". Stand your ground.
So, if you are a CV-oriented programmer, you will most likely not want to do Delphi. There is an indelible and horribly misinformed meme out there that there are no Delphi jobs or that Delphi is dead, is old, outdated and irrelevant in modern software architectures. I have seen this ageist misinformation come out as lame attempts to ridicule Delphi programmers (jealousy?), branding them luddites and dinosaurs. We never retaliate. Quiet stoicism is a prerequisite for club membership.
Finally, the Delphi club also has a new membership protocol: always buy them a beer. No matter whether they eventually get accepted in the hallowed halls of this quiet corner. :-)
Still delivering stuff on ASP.NET Framework 4.7.x, have delivered a couple of Forms/WPF projects during the last decade to lifetime science R&D labs, own all Delphi books from Packt, I guess it kind of qualifies for the membership pitch. :)
I doubt there any thing today that even come close to Delphi in terms of RAD. It is unfortunate that Software as an industry is even worst than fast fashion.
Correct. I myself used "eclipse's" parent (Visual Age) in the early days but the point I was making was not so much that "drag and drop" was missing - it was just too cumbersome and difficult even in that! In VB6, it was trivial to get a form to look the way you wanted it to look. Gridbag layout on Java Swing maimed many, and those that got off the VB6 boat soon realised that Java land was much much harder even with their GUI drag and drop tools.
BTW, I used JBuilder extensively. What a topnotch tool from Borland. Pity they didn't survive the virulent competition during those IDE wars period. I still remember settling an argument with a colleague about his insistence to use the newly arrived Netbeans, while I fired up my JBuilder IDE (Yellow Porsche splash screen IIRC), created a gui, added jdbc data controls, coded a few lines and hit compile - ALL while his Netbeans was still loading with that dastardly progress bar.
(These comments have been much needed catharsis for me.)
From memory JBuilder did have issues with its GUI builder.
Code emitted JBuilder's tools was not isolated from other code that was written for the application. It was easy to add a line of code that would make the included builder tool to not show the resultant GUI correctly.
This was from JBuilder 9 and JBuilder 2006, other than that issue it was a really nice IDE to use.
That is what happens when one stays with AWT, does everything on the main thread, and doesn't bother to read Java UI design books like Filthy Rich Clients, or integrate component libraries like JGoddies.
However I do agree Visual Basic and Delphi were much better, and if Java hadn't happened we wouldn't have lost 20 years playing around with VMs and dynamic languages, to finally start paying attention to AOT, value types on type safe languages.
It wasn't exactly sure randomness. I was registering for some band forum as an edgy teen and he was on CNN stroking Strom Thurmond's ego
It's wierd enough that any old niche forum friends I've lost touch with would recognize it...and I can't imagine anybody else would use it coincidentally. He's been a non-figure for years and years
Your curiosity demands more upvotes than I've got!
> VB6 was one nice thing - build 'a program' as you understand them in Windows. Why the fuck is it so hard nowadays?
My takes is because it's not modular enough. Sure it's easy to plop this and that components here and there, add events, etc. However as requirement changing each pages / sections need to be changed as well. Not to mention portability to linux or mac. That and we're talking about db access, drivers, and security (in memory data sniffing / tepering).
Of course it doesn't applied to all kind of apps, but those who need constant changing are the one who pays Microsoft bills.
Yeah VB got me into programming as well, there was a book literally called "programming for kids", it came with a copy of Visual Studio 6 and it was a few simple things like making a calculator, making a simple pong clone etc....that was the best thing as a 10 year old. Now I'm a professional C++ programmer, so....yeah, thanks VB! We'll miss you.
Same. My brother brought home an illegal copy of visual studio and I was hooked pretty much immediately. We had no internet at the time so I found myself using the MSDN knowledge base articles for potential explanations.
It really annoyed me that I couldn't get nice bitmaps in menus so I eventually learned about Ownerdraw. That changed my life. Having to hook into the wndproc and all the other windows api calls introduced me to C, and so I naturally started experimenting with C++. All without internet, stackoverflow or groups.
Books! I read one that was all about custom controls, must have been about 300 pages and at the end presented code that provided subclassed versions of all the MS Windows 3.1 controls with 3D effects.
Powershell is a command interpreter like bash at the end of the day, I say use the best tool for the task. I'd hate to do gui with powershell,vb6 let me build simple UI front ends, probably the simplest ever.
The strength of VB6 was a simple and straightforward syntax and a great integrated GUI builder and IDE.
Powershell has none of that. The Powershell syntax is baroque due to the (necessary) compromise between command line syntax and scripting language and there is no IDE/GUI-builder.
Sure, Powershell is much more powerful in many ways, but that was not the draw to VB6 in the first place.
Mixing c# and power shell in the same script is amazing. You can load methods from DLLs on the command line as well. I had to do this when I didn’t have permission to run unregistered exes on a server I was debugging. Luckily the admins didn’t restrict powershell and I ran my main method from a script.
Back in the very old days I wrote Excel Apps in VBA. You could pull an entire range in as a 2d array and dump it back out the same way.
The debugging environment was better than any I have used since. You could drag the execution point anywhere, edit code in between steps, view everything. It was amazing.
> I loved VB6. Of all the languages and IDE's I've ever used, I've never been more efficient in any other one.
Other than the amount of work it would take, what's to keep someone from taking all of the specs and docs, and implementing a language compatible with VB6 and VB.NET?
Nothing, it is just that nobody bothered. There have been a bunch of classic-VB-like languages (even IBM made one with their 'Visual Age for Basic' - though they really missed the mark on the IDE side, but the language and features were very VB6-like), but pretty much all of them either get abandoned or miss the entire point of classic VB by focusing on one thing (usually the language) while ignoring another (usually the IDE or sometimes the fact that classic VB is almost a 'live' system and instead they put a clear C-like separation between editing and compilation)... or miss completely by doing all these things wrong. Assuming they do not die off before managing to make anything usable, of course.
But, ignoring that, almost any app of any complexity in VB6 land will rely on bugs, quirks, and implementation details. (Also, I was never clear if the binary format for editing forms was actually documented somewhere). Someone could implement their own VB6 parser, but it seems like a ton of work for a vanishing market.
All of that said, while typing this, a quick search revealed https://www.radbasic.dev/ , so maybe someone's trying. Well, it's a Kickstarter, so maybe someone just has an idea. Dunno.
My final year project was a VB6 -> JVM compiler. I underestimated how big VB6 actually was and so only had time to implement a small fraction of the language. I did discover a bug in the IDE's code completion/formatter that would cause a compilation failure when the project was next loaded. That code is on a floppy somewhere
For one thing, there was no VB6 language spec, and the docs were rather informal when it comes to syntax definition (which is very non-trivial - all the "special" functions etc).
Exactly! Behind all the churn of new newer newest rehashes of what a programming ecosystem could be hide real hard problems, and they mostly never get addressed.
Are you aware of "using static" in C#? Allows you to use any methods on a static class without qualification. Gives you the appearance of global functions, despite the class scoping.
Interestingly I was in a meeting with Brendan Burns (of k8s fame) last year where he was extolling the virtues of VB. Not that it was the greatest language or anything, but that it brought programming to the masses, the ability for shirt and tie managers to do little things that increased their productivity.
The adblocker doorslammed me. Here's the text of the article.
Microsoft said this week that it will support Visual Basic on .NET 5.0 but will no longer add new features or evolve the language.
“Starting with .NET 5, Visual Basic will support Class Library, Console, Windows Forms, WPF, Worker Service, [and] ASP.NET Core Web API … to provide a good path forward for the existing VB customer who want [sic] to migrate their applications to .NET Core,” the .NET team wrote in a post to the Microsoft DevBlogs. “Going forward, we do not plan to evolve Visual Basic as a language … The future of Visual Basic … will focus on stability, the application types listed above, and compatibility between the .NET Core and .NET Framework versions of Visual Basic.”
When Microsoft released the .NET version of Visual Basic, originally called Visual Basic .NET, alongside C# at the beginning of the .NET era, the two languages were evolved together and had roughly identical feature sets. But this changed over time, with professional developers adopting C# and many fans of classic VB simply giving up on the more complex but powerful .NET versions of the environment. Today, virtually all of Microsoft’s relevant developer documentation is in C# only, with VB source code examples ever harder to find.
Worse, Microsoft in 2017 announced that its original C#/VB co-development strategy was over. Only C# would get all of the new features, while VB would focus on the simpler and more approachable scenarios that it once dominated. But that never really happened, and Microsoft effectively abandoned VB. This week’s announcement just makes it official.
What this means to VB developers is that they might be able to bring their existing codebases forward to .NET Core or, soon, to .NET 5.0, which will replace both the traditional .NET and the open-source and cross-platform .NET Core when it’s released in late 2020. The issue is that not all legacy technologies will be supported going forward, so developers using WebForms, Workflow, or Windows Communication Foundation (WCF) will need to stick with classic .NET. Those applications will continue to work and be supported until the underlying Windows versions are retired; classic .NET support life cycles are tied to the Windows versions on which they were initially deployed.
Microsoft also notes that VB developers will occasionally benefit from improvements to Visual Studio.
“Visual Studio regularly adds new features to improve the experience for developers, including those using Visual Basic and either .NET Core or .NET Framework,” the .NET team adds. “An example is the recent addition of IntelliCode for Visual Basic.”
This is a sad day, and one that hits me personally. I started my writing career with Visual Basic 3, went on to write several books about VB and its various variants, and most recently wrote an entire Notepad clone called .NETpad in Visual Basic, Windows Forms, and the .NET Framework.
I learned how to program in VB4 too. My parents had no idea why I wanted it or what it was for. I used to take the textbook sized manuals with me to read/study while camping and fishing.
I first learned it by myself in VB5. I didn't even understand functions, but writing those MessageBoxes with buttons and then having them create even more message boxes was so great! I remember a high school friend bringing me 5 diskettes with VB4 installer because I didn't have it on my home computer.
Then next year I enrolled in AP Comp Sci - hardcore turbo c++. Just blew my mind!
> Then next year I enrolled in AP Comp Sci - hardcore turbo c++.
Funny enough, AP Comp Sci went the other direction in the early 2000s, switching from C++ to Java precisely because it was too hardcore for the average high school student.
My high school in ~2010 had the progression C -> C++ -> Java. I remember the C++ that we were taught being easy enough to learn after a semester of C, and graduated before I could take Java.
haha. I was so excited to learn about C-style strings in AP comp sci 2 I think. And bitshifting, and crazy recursions, queueing, etc. Good old days... I was so arrogant after that too. C is the best and everything else is garbage because it's "slow".
E.W.Dijkstra would disagree: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Probably just hyperbolic. Bad habits are a common complaint in music and sports education too. Not insurmountable, but not helpful, and it must be frustrating as a teacher to have to unteach bad habits.
Christian theology was historically a great impediment to learning about physics; some Christian cults continue to impede people from learning about biology.
People who are really good at manipulating other people seem to have a hard time learning to do productive things, maybe because it's too easy to manipulate other people to do them instead, but maybe because people sometimes follow the Law of Attraction, where you make wishful thinking come true by believing in it hard enough, while software and Volkswagen engines do, if anything, the opposite.
More broadly, I think any field of learning carries with it a sort of implicit value system: we consider things x and y centrally important, while things a and b are inconsequential details. Much of learning a field involves internalizing these values to the point where you apply them automatically without even being aware that there's an alternative. But often they are suboptimal or even counterproductive in a different field. Volkswagen engines don't care about paint color or whether your grandfather just died, but they do care about thousandth-of-an-inch tolerances and not making mistakes. Interior decorating doesn't care about thousandth-of-an-inch tolerances or clean abstractions, but it does care about paint color and whether your grandfather just died. Debugging software doesn't care about not making mistakes or paint color, but it does care about clean abstractions.
This is even true in subfields within the same field: real-time engine control software cares about memory allocation in a way that seems completely insane to anyone who programs in Python, for example.
BASIC tends to reward novice programmers for banging on a piece of code cluelessly until they get it to work in some cases. Dijkstra, by contrast, believed that what was important was having sufficient logical understanding of the program's space of possible behaviors that you could be sure it would work even before testing it; he in fact designed and successfully taught an introduction-to-computer-programming course that used no actual computers. It's unsurprising that someone who had internalized BASIC's value system would be extremely resistant to Dijkstra's preferred approach, and that Dijkstra's disciples would be extremely resistant to the BASIC approach, even though in fact they are complementary, and each one works best for some classes of problems, so those who are best at one of these ways of working are those who would gain the most from learning the other.
to me, that was always a great example of the difference between IT and CS.
I totally understand how someone trained in VB was "mutilated" for CS. Because the priorities for CS coding are totally different than for commercial coding.
But from an IT perspective the point of programming is to be profitable, not perfect. VB allowed people to write profitable programs quickly. It was a fantastic environment if all you wanted to do was write desktop applications for businesses.
The quote is about BASIC. Visual Basic is a variant of BASIC.
The quote was also thrown around a lot in the late 90's as a "VB sucks, you should use a real programming language" comment in the usual language flame wars.
Yes. And Dijkstra would be wrong. (Or, perhaps more accurately, prone to somewhat bombastic hyperbole.)
BASIC is structurally similar to ASM, moreso than is any other HLL, at least of any popularity. Like almost any language (or paradigm) it is possible to get stuck in its particular ruts, and when BASIC was at its peak popularity there were probably lots of people stuck in those ruts just as later happened with Java and the static, class-based OO paradigm more generally. A learning language isn't something you stock with exclusively, it's something you learn with and then diversify from, ideally, and for that, BASIC (old-school unstructured imperative BASIC) is great.
BASIC (old-school unstructured imperative) is structured as the "ASM" language for an old-school desk calculator from the 1960s, with a few tacked-on features around string manipulation, input handling etc. plus more, depending on the hardware. It was fine for what it was in the 1960s (a simplified "scripting"-focused version of FORTRAN), but the needs of even slightly more modern coding are very different, and BASIC would not serve them well.
IMO it depends what you mean by “good programming”. An Excel spreadsheet with a bunch of VBA macros is by absolutely no means graceful programming or beautiful programming but it’s highly effective and has served as an entry to the world of programming for a huge number of people, myself included. It’s productive programming with little of the bikeshedding you’ll find in much less “mentally mutilated” setups.
When Dijkstra wrote that quote in 1975 he didn't had Visual Basic in mind, he was thinking the much older BASIC dialects that used line numbers and GOTOs for flow control.
Dijkstra was trying to promote structured programming languages like Algol and Visual Basic is based on the QBasic dialect which has full structured programming features like WHILE and FOR loops, IF that would work with compound statements (that is have the THEN part be more than a single command), local variables, functions, recursion, etc. It might be hard to image nowadays but there was a time when those weren't available to all languages. Though note that the next year after Dijkstra wrote that quote, the original Dartmouth BASIC actually got structured features. Though it wouldn't be until QBasic that you'd see a (popular) BASIC dialect having those in home computers.
Regardless, this quote was outdated long before Visual Basic 1 was made, let alone VB6.
GOTO for flow control is not that bad, it's just a tail call after all. The real damage is things like having everything be global variables. But part of that was a technical limitation, as things like "proper" call stacks and reentrant code as the default still had plenty of overhead, and even FORTRAN didn't support them.
I'm not sure what you have in mind but in the 1975 dialects of BASIC the code was something like
10 REM Grab input
20 GOSUB 1000
30 IF VALUE=BAR THEN GOTO 100
40 IF VALUE=BAZ THEN GOTO 200
50 IF VALUE=BLA THEN GOTO 300
60 GOTO 20
100 REM Bar stuff
110 blahblah
199 RESUME
200 REM Baz stuff
210 blahblah
299 RESUME
300 REM Bla stuff
310 blahblah
399 RESUME
1000 REM Code that grabs input
1010 blahblah
1100 RESUME
Note that this is a bit more readable than what people worked with since now you have syntax highlighting.
I'm not sure where tail calls enter in the picture... there wasn't even support for functions, at best you had GOSUB/RESUME which was essentially assembly-like CALL/RET.
> I'm not sure where tail calls enter in the picture...
GOTO essentially involves setting the continuation of your program to something other than the following instruction(s). That's what a tail call does. No "functions" involved except as a high-level description.
I don't think that example you've posted is right (the grab input one, not the game on Github).
Firstly, RESUME was to continue execution after an error (eg ON ERROR RESUME NEXT). I think RETURN is what you might have meant?
Secondly, you cannot RESUME/RETURN from a GOTO. I think you meant GOSUB; which was a crude approximation of subroutines. BASIC did also have GOTO as well though.
Yes you are right, i meant GOSUB/RETURN. Though instead of "RESUME" (which should have been RETURN) most programs would use GOTO 20 (in an opposite expression of what Dijkstra wrote about, i accidentally used a 'function call' idiom instead of a spaghetti 'jump wherever' one :-P).
Goto has its place. It's not evil, but should be used judiciously. After all, C family constructs such as break, continue are glorified/specialized, albeit scoped and unlabelled gotos.
One of the places I like gotos is when I need to break out of a nested loop. A goto to outside of the outer loop is far more obvious than a flag and a conditional to break from the parent nested loop. It also generates better machine code and uses fewer registers, at least in debug mode.
Sure, goto can be abused, just like every other language construct. They have their time and place, though.
The issue was not the presence of goto itself, but the fact that is was one of the main tools for flow control, while as you say it should be used sparingly.
It is like having an army of soldiers armed with a David Crockett[1] instead of a regular rifle. Things may get ugly fast.
Certainly, the next few years of my learning to program was unlearning ideas I had developed from coding in Visual Basic. But it gave me the start in understanding how functions work, how sub-procedures work, and how objects work. More importantly though, Visual Basic gavve me the excitement and possibility that I could make this thing on my family's desk do pretty much whatever I wanted. And Visual Basic made that very accessible.
I evaluated Visual Basic as an alternative to Borland C++ to develop Windows programs. It was just not there. Borland C++ allowed easy GUI design and was easy integrated with Windows APIs for any low-level needs.
Several years later the jump in quality was astonishing. Good ODBC drivers and easy linking between database rows and your UI make it a fast development tool that fit many needs.
I do not miss the big colored buttons that many developers used at the time. Never as bad as Access applications used to be, thou.
I took a VB course in college and was immediately hooked. Then I immediately switched to Borland. There is something about being able to compile a runtime-free, native binary.
Wonder what is going to happen to Visual Basic for Applications? I hope it pushes Microsoft to move toward a new language like Python to automate Excel.
The two are completely district languages. Kind of like comparing Java with JavaScript.
I'm sure in general Microsoft would love to scrap VB in Excel but there's too many companies that run entire areas of business on it, or the whole business itself.
It is the typical legacy/back compat problem. Python or even Powershell would be a vast improvement, but you're going against billions in sunk cost/skills/knowledge.
VB.Net was slowly losing popularity, VB in Excel isn't.
Would it be impossible for Excel to allow coding in multiple languages? I totally get that there's a huge (disturbing) amount of business critical stuff using the current scripts, but they really should move on to something more modern.
Multiple-language runtimes typically don’t get popular - people just end up choosing one language and standardizing on it. See for example Windtows Scripting Host: you could always use Javascript with it, but almost nobody ever did in practice. After a while, typically the vendor sees other languages as a drag on development, and they get dropped in favour of the main one.
Retrofitting a multiple-language runtime under VBA would likely be a big endeavour, and in the end most people would probably stick to the established language anyway.
Microsoft pretty much built it (would allow any .net language to behave like VBA, with an integrated IDE and ability to save code inside the document). Then they killed it. I think that was a huge mistake from a productivity point of view, and also to get a fighting chance to retire VB6.
I had 7 years of C# experience in 2015 when I had to make an unanticipated job change. With some trepidation, I took a position with another company in the same industry whose codebase was all vb.net. I used Telerik's code converter a lot to bootstrap my proficiency with vb syntax. The boss said I could just write in C# if I wanted to, but I saw no need to make more mental work for the rest of the team.
Is there really a lot of production VB.NET? I wouldn't be at all surprised to learn there is more production VB 6 code and development on that stopped two decades ago.
Yes, it is the to go programming language in life sciences corporations when Office users outgrow their VBA skills and get to have IT install VS on their computers.
I know a couple of places like this, no R, no Python, VB all the way.
Python didn't have the developer will to embrace interop between Python 2 and 3 transparently in bytecode, so you had a hard switch over.
CIL doesn't have that problem, you can keep writing in VB.Net without being forced off a supported compiler.
I was in a fork in the road and had the choice between Python or .Net to move forward with my career a few years back, there were a few factors on why I went .Net. Being one of very few pleasing to use and (extremely) widespread languages with static typing, along with MS's early embrace of WebAssembly were both major influences. Yet the biggest was the Python core devs refusal to address Python2/3 in a better way. There's no good reason why you couldn't use the same Python 3 interpreter for Python 2 code. I get the maintenance argument, but this raises questions about the future, and it makes their platform look rinky dink today. I came to the conclusion I'd never build anything important on it, which is essentially everything you write, as projects tend to grow.
My first real job was on a .NET stack that was 1/2 VB.NET and 1/2 C# for legacy reasons. It was weird at first, but I mostly stopped noticing after a few months - the two were completely interoperable and they both compile down to the same .NET IL. In practice, coding in VB.NET was 99% the same as coding in C#, just with a slightly more verbose syntax. Not my favourite language, but much better than its dismal reputation would imply.
Not completely interoperable. At least initially (and as far as I'm aware ever). VB.Net never could understand the unsigned integral & char types. If you used unsigned types in C#, those members wouldn't be BCL compatible and at sufficient warning level, you had to annotate members with [BCLCompliant(false)] if my memory serves correctly.
There were other language constructs at the time that werent 1:1 parity at v1.0, but in nearly 20 years time, I forget.
Well another one is case insensitivity. If you have a property and a function in C# which name only differs by casing, will be a problem to consume in VB. Not that it is good design in the first place.
Visual Basic was one of first languages i have learned. A lots of its spirit was moved into C#. Maybe its good, but on the other hand we loose a good one leaving more Space for JS and the creature called TS.
I loved VB. I don't think I've ever been as productive as I was in VB - I could literally knock together a complete desktop application in an afternoon.
It wasn't perfect. There were lots of problems with it. It would never win prizes in CS competitions. But man you could build shit with it fast.
100% this to a tee! In the mid to late aughts I knocked out soo many junky little desktop apps that scratched very specific business itches we had at work.
A couple hours work in VB saved non-technical people hundreds if not thousands of hours of repeated effort. Killing it is a mistake in my opinion, Even if I haven't touched Windows since 2010, VB.Net is the one wonderful thing it had going for it.
You don't need any of that. VB6 had C FFI (Lib/Alias), structs, and function pointers (AddressOf). So you could just implement a function in straight C, compile it into a DLL, and invoke it from VB.
I know but already function prototyping of a DLL your write to get around language limitations isn't quite in the spirit of "things you can do in VB6". And technical you could do it in VB, but it was pulling teeth. I could just as easily write it in java and shell out to it. In VB it was hard pretty difficult. But you are completely correct, that's the right thing to do. I don't have bad feelings towards VB at all. Even today it was probably the most productive GUI development environment I've ever seen. But function prototypes returning structs / buffers? OnError GoTo <label>? Nostalgia only goes so far.
ps - noticed the employer on the profile. Powershell + .NET assemblies crushed it, and VB.NET was a far superior language (though, just like all the jvm languages have the same feel, all the IL based ones did and why not use C# at that point?)
In about 1998 I got introduced to programming beyond CMD prompt through VB. My first form was just an input box, a button, when clicked, alerted the box contents onto a dialogue box. My mind was blown when I found that using & in label makes the Alt+ keyboard shortcut.
"There’s something deeply right about how list indexing and function application are the same operation". That is a quote from a recent submission about K (https://news.ycombinator.com/item?id=22504106), and that is a perfect example of how I usually get VB nostalgia attacks: somebody talks about a thing in other language they consider amazing implying that that thing is unique for that language despite it was implemented in VB and earlier. Sometimes that somebody can ever be Microsoft as they brag about adding more features into C#'s switch statement with increasingly ugly syntax in every new version completely ignoring that they did them better in VB.
I'm pretty sure that there are a few languages where array indexing is basically calling a function that returns a reference to the cell you're accessing.
Since C# 1.0, any type can have an indexer property defined that can accept any parameter types and can can return anything - though it wasn't until C# 7.0 that we could return a first-class reference to a value, including array members (`public ref int this[int idx] => ref this.someArray[idx]`).
Parentheses for array indexing dates all the way back to the original Dartmouth BASIC, and from there to the very first FORTRAN. It's one of the oldest pieces of PL syntax still around in its original meaning.
VB uses the same syntax for array indexing and subroutine invocation, but they aren't the same operation; you can't define a parameter that is either an array or a subroutine. So the extra expressive power that this unification provides in K is absent in VB.
As long as they give me something to use in the place of VBA, I can't wait for all forms of Basic to die. It hurts to use it, but I have to because there isn't anything else in Excel.
I thought HN was supposed to collapse duplicate submissions to a single topic? URL appears to be identical. Is there some kind of cache issue in HN's backend?
Caching issue is unlikely, given that HN runs as a single thread on a one server, writing to a flat-file backend. As far as I'm aware the main cache involved is the OS's page cache.
To your main point, the dupe detector seems to be fairly limited; I think it only checks for the same URL in the past 12 hours or 100 posts or something. It seems to be just to keep the same post from showing up multiple times in /new.
When the resubmission is very soon, they are collapsed. After some time, the new submission lives. The exact time is not officially available, and the mods may tweak it from time to time without warning.
VB3 was my first real language. I'd attempted stuff before on spectrum and BBC BASIC and later QBASIC, but VB3 not only allowed easy development of a GUI application, it allowed you to distribute an EXE -- a real grownup program, not a ".bas" file. I wrote my first commercial program in VB3 or VB4, to look after book orders, had an access database behind it, and all sorts of oddness to do printing if I recall rightly. Used VB4 as well, and I guess I used VB5 as well.
I moved on, to the web, to things like TCL/TK, Java, and Perl. Some things never change, I have a full screen vim window with a brand new perl script on my right-hand monitor as I type this.
Despite having dumped windows 20 years ago, I've still got a place in my heart for visual basic.
I'll always fondly remember Visual Basic as the language that let me make real Windows applications with the language I already knew and understood.
I was just a kid, maybe 10 or 12, when I learned to program with QBASIC and later VB5. I remember strongly feeling that a ".bas" file wasn't a real program. I so much wanted to be able to run my programs as real .EXE files. There was some kind of QBASIC compiler that made an .EXE but I felt like that was just... still not real enough. That desire for making a real bonafide .EXE was one of the driving reasons I (tried to) learn C.
I never understood the purpose of VB.Net. My second job out of college was a mixture of VB6 and C++ where we would use C++/ATL (COM) to mix and match languages. Of course the VB6 IDE was miles better than the C++ IDE.
But, Windows Forms with C# was just as easy as VB6 and VB.Net was just as complicated and more verbose than C#.
Microsoft politics after hiring Anders Hejlsberg who designed C# as a competitor to Java so Java's compile-once-run-anywhere wont take a foothold on the desktop market and thus endanger the dominance of Windows, required that everything related to developing software for Windows was focused on C# and .NET to drive home to ISVs that this is the future, but up until that point VB6 was wildly popular - and absolutely incompatible with anything related to C# or .NET. So they reskinned C# with some VB clothes and paraded it in front of VB6 developers, hoping they wont notice the sharp bits sticking out - which worked as well as you'd expect. But with Microsoft having full and absolute control over VB6, it isn't like anyone could do anything about it, so over time people moved on. VB.NET never managed a hint of VB6's popularity and was always in the shadow of C#, which made perfect sense since outside of liking QBasic-like syntax more than C-like syntax, there wasn't any reason to use VB.NET.
VB was a great and successful language. It empowered a lot of departments to create bespoke programs that, while not having been built on solid comp sci principles, were good enough and solved real business problems without having to involve the IT department. That’s a strength and a weakness.
VB is one of those things that let the determined create useful things. Not unlike Microsoft Access.
Instead of actually learning principles and practices, and a 'good' language, they could just hack something together than managed to just barely work, armed with a $99 copy of Visual Basic and a 'Teach Yourself VB in 21 Days' books from SAMS publishing.
And by the time they knew any better, they were up to their ears in shit. Chances are, if you have a big project in VB, you also have the following problems:
* You're not using version control. Or worse, you're running Sourcesafe.
* You're not using secure encryption or communication
* You're not using secure programming practices
* You're not using a modern, secure OS
* You're also using some 16 or 32-bit utility libraries that nobody has the code to
* You're employing developers who have 20 years of "1 year experience with VB"
* No need to write a business case with fake ROI figures. No IT committee meeting. No need to teach a “solutions architect” who doesn’t really care to learn.
* Easier to evolve as requirements change because the front line person is fixing it.
* Proof of concept done already when you need IT involved for version control, security, etc.
Do you have any hard evidence of an actual causation between VB and the symptoms you describe? I think any non-bleeding-edge mid and later hype-cycle technology will have its monsters. I get the feeling VB is past
all that, and what's leftovers can't be sooo disfunctional.
291 comments
[ 6.3 ms ] story [ 253 ms ] thread(And VB.NET is much less of a loss -- it was never as popular as classic VB. Even when it first came out, it was clear that if you were a VB developer, Microsoft really wanted you to move to C#; VB.NET always felt like an afterthought, a fig leaf they could use to say they really weren't abandoning VB when they obviously were.)
That’s why when I switched from vb.net to c# (when microsoft announced they were deinvesting in it 2-3y ago), I stopped writing vb completely. It is hard to fit two languages in muscle memory (unless the syntax is pretty close).
Edit: I should also mention that VB5/6 got me away from HyperCard. I loved the idea of being able to draw my GUI, and not having to screw around with writing my own event loop.
With VB, I liked that it was "object based," by which I mean that you could use objects provided by the tool without having to create them. This was a great way for me to ease my way into OOP. By the time I wrote my first object, I already understood what objects were useful for.
It kinda still lives on in classic ASP. It will be supported indefinitely so far [1]
[1] https://support.microsoft.com/en-us/help/2669020/active-serv...
At the time it was very capable as lots of software titles opened themselves up to automation via COM - that's why you could have Classic ASP pages that invoked Office Excel to generate charts dynamically.
Unfortunately it was all a mess, but it was also something beautiful because it meant that a desktop/server OS was more than just a place where heterogenous applications could live: they could truly interact with each other regardless of their programming language or runtime platform.
That grand vision - itself an extension of OLE from the early 1990s - died down with the rise of .NET (this wasn't intentional - Microsoft just had a lot of reorgs around that time and COM was more-or-less feature-complete, and no-one was really using DCOM) - but with Windows 8 and the "WinRT" API I was hopeful that COM would be back and new ways of automating applications would come around, and that Microsoft would have a great system for non-programmer users wanting to build workflows like they can with Apple's macOS Automator and AppleScript.
This also ties-in with the do-as-little-work-as-necessary being done for VBA support in Microsoft's products. While we all wish Microsoft would allow modern JavaScript as a first-class COM automation language - the Office VBA runtime only supports its own VB6-dialect (the VBA language), and while Active Scripting supports JScript (a snapshot of JavaScript version 3 from 1999-2001) it doesn't support static typing nor is any of the tooling inside Office compatible at all. - so instead we have JavaScript, but only for "Office Apps" which don't offer anywhere near the same kind of integration or control over Office applications (or things like filesystem access) that VBA does. It's like it's 2008 again and everyone's excited about the new iPhone OS App Store and thinking about all the cool iPhone OS system extensions they'd add, like a Today screen or a camera app that can record video by using low-level camera hardware APIs - only to be discover Apple will only let-in apps using nerfed and siloed high-level APIs that take away all of the fun from extending an OS.
Even as late as 2010, COM support in .NET was still being developed - C# 4 got named indexers for this reason alone, and its "dynamic" supported IDispatch out of the box - its main scenario being Office automation.
VB6 and C++ (specifically, Microsoft VisualC++'s __declspec-punctuated dialect at least) were both intimately connected to COM with their respective compilers have built-in support for DOM/DCOM/etc (e.g. VC processing IDL files and generating TLB files, while the VB6 compiler seemingly reads-in TLB files natively - and can generate its own too) - and all major components for Windows desktop development (such as ADODB for OLE and ODBC database access, the Macromedia Flash player, OLE objects in general, and VB-ecosystem "components" like charting widgets and new styles of buttons were all done using COM - which means programs written in VB6 running in the VB runtime could use the same GUI components and platform feature libraries as C/C++ code running in its own world - that is cool!
While .NET is fully compatible with COM - the ecosystem isn't the same: WinForms and WPF GUI components written for .NET now cannot be used by VB6 forms or C/C++ windows (at least not without hosting .NET in-process and then facing additional issues integrating your Win32/User32 GUI with a WinForms hosting surface) - while hosting COM GUI components in WinForms is straightforward and just like VB6, hosting a COM GUI component in a WPF environment is very, very painful (google "wpf airspace" to see why this is a bad problem).
Additionally, consuming COM from .NET (even VB.NET) isn't as easy or as straightforward as it is with VB6 either - as you have to contend with the ISA of your .NET process (e.g. you can't load 32-bit COM components into an x64 .NET process).
I feel the amount of third-party software on Windows that offered COM automation has dwindled in recent years because of those reasons.
Bitness is not a new problem - VB6 similarly has problem consuming COM components written in C++, but compiled as 64-bit. Or, to put it another way: VB6 didn't have a problem, because 64-bit wasn't a thing back when it was popular, and didn't really became common on Win32 until relatively recently. But in a similar vein, if you always compile .NET code targeting x86 rather than AnyCPU (which is the default for new .NET VS projects - not sure when that changed, but it's been several years), you get the same exact behavior as VB6.
Getting back to OLE and ActiveX - I would say that it was killed by Microsoft directly, not because of .NET. Back in the day, most non-trivial Windows apps made by MS supported OLE for embedding - this was most commonly used with IE, but you could also do it with e.g. Word and Excel... until you couldn't anymore. If I remember correctly, it was Office 2007 that killed it as an officially supported scenario (you could still do it, but if anything broke, you were on your own). That roughly coincides with WPF, and I don't think that's a coincidence - but it doesn't mean that WPF/.NET was the primary cause.
I understand that's because .NET components loaded into a native process via COM are done so in-proc but using a single instance of the CLR, means you can't have .NET 2.0 CLR and .NET 4.0 CLR components loaded at the same time into the same process. I also understand (but am unsure) about what this means for AppDomains.
.NET Core simplifies things considerably: by being utterly broken when it comes to COM support and generally requiring each .NET Core program to have its own independent process rather than supporting multiple AppDomains in the same process (okay, that's a bit of hyperbole: .NET Core supports strongly-typed COM objects but they removed support for using `dynamic` with late-bound COM objects - and I can't find any documentation regarding loading .NET Core components via COM into a native VB6/C++ process.
> But in a similar vein, if you always compile .NET code targeting x86 rather than AnyCPU (which is the default for new .NET VS projects - not sure when that changed, but it's been several years), you get the same exact behavior as VB6.
I understand the default for .NET Framework application projects is still AnyCPU but a new option called "Prefer 32-bit" is selected by default. Whereas for library projects and all .NET Core projects the default is AnyCPU ("Prefer 32-bit" is only an option for *.exe projects).
> If I remember correctly, it was Office 2007 that killed it as an officially supported scenario (you could still do it, but if anything broke, you were on your own).
> That roughly coincides with WPF, and I don't think that's a coincidence - but it doesn't mean that WPF/.NET was the primary cause.
I understand the reason was because very few applications in the wild depended on this functionality (that's what Microsoft's telemetry in Windows is for) - I think the only real application that made full use of this was MS Binder (rip 2002) - and I only ever got annoyed at the times when Internet Explorer would load Office Word or Excel directly into the browser shell.
Office 2007's radically redesigned UI required much more screen real-estate - whereas Office's support for being loaded into an OLE window was back when people were running at 640x480 or 800x600 (if you were lucky!) and Office had 16px-sized toolbar buttons - which is another reason to avoid wasting developer time working on it.
That's not necessarily so. By default, a .NET class exposed via COM is free-threaded, so it'll be instantiated in-proc. But you can have all the same complicated apartment arrangements as with native - and marshaling is done via type libraries that are generated from assembly metadata. So if you want an out-of-proc COM server written in .NET, it's quite possible.
> but using a single instance of the CLR, means you can't have .NET 2.0 CLR and .NET 4.0 CLR components loaded at the same time into the same process.
If you use in-proc components, then yes, the runtime is loaded. But .NET 2 and .NET 4 runtimes are intentionally designed to be possible to side-load. They don't see each other as .NET, of course - so if you take a reference to an object in one runtime, and pass it through native code as a COM reference to the other runtime, it'll see it as an opaque COM component.
.NET Core is its own thing - it's clear that everything Win32 is legacy there, including COM. I was surprised it even got WinForms...
And UWP as modern COM is here to stay, no matter what, Microsoft seems to be willing to spend the money to keep it going, even it requires a new programmer generation.
Not trashing VB, but C# was always more capable and fully featured than VB (VB couldnt even do unsigned integers, and I dont it can even now), and almost immediately more widely adopted in even .Net 1.0. Hell, C++ with COM was more capable (if not extremely annoying amd error prone). Of course VBscript and VBA share very similar syntaxes, but they're not the same languages or std object models/libraries, just maybe 95% similar.
All this feels a little like history repeating itself. We even naively made up a petition back then to keep VB6 around, somewhat glad that led nowhere in retrospect. A few decades ago I loved that the VB ecosystem was approachable and combined beginners and professional users. I somewhat think we have enough other good tools that fit this description these days, some of which incidentally even come with a good programming language.
Apparently VB does support unsigned data types in some version: https://docs.microsoft.com/en-us/dotnet/visual-basic/program...
As long as MS doesn't break my workarounds to run that old IDE or its EXE's, I'm happy. VB.NET was a great stepping stone, but after switching to C# I never looked back. The only thing I miss is global functions that don't need a class qualifier in front of them. And I still find the Edit-and-Continue debugging experience in C# hit-or-miss.
You can even mix powershell and C# together in the same script.
Once I realized I had a better version of everything I wanted, it became my new favorite.
What feature are you referring to?
[0] https://dandraka.com/2018/11/12/powershell-how-do-you-add-in...
But just so you are aware you can use the 'class' modifier To change this behavior.
It is one of the most fundamentally bizarre language design choices I have seen in my career
It seems like it might make some kind of sense, since it doesn't output directly to the console but rather to a pipe. Bash functions sort of work the same way since they don't have complex return values (aside from exit codes) other than the function's output stream.
Take the following in PowerShell:
ls | sort DateTime -d
ls returns an array of objects, sort then sorts the array by each object’s DateTime field (and here I’m asking it to sort in descending order with -d). The point is that sort isn’t depending on any text output, so it works with any array of objects regardless of the command that returned them.
The other cool thing this enables is auto-complete awareness in the shell. If I typed:
ls | sort <Tab>
then the shell knows what makes sense in auto-completion here as ls has an actual return type and in this case it will give me a list of available fields that I can sort on.
For those unfamiliar: ls and sort here are shortened aliases to more wordy verb-noun commands. These (as well as a large bunch of others) are given to you by default.
Structured data with direct access to any OS API, regardless how it is provided, .NET, COM or straight C like DLL.
UNIX world never had that, beyond trying to fit language repls as user shell, which on UNIX always feels like a leaky abstraction.
I use fish as my command line, but I still write scripts in bash, even personal ones I only expect to use on my own machine. Just out of a vague sense that I might reuse it, or it might escape confinement, or something.
I usually get frustrated with it and bash out a quick cmdlet instead.
Freudian slip?
In terms of wider adoption, it suffered by maturing at a time when a lot of people had moved on to more powerful devop solutions. And of course, being MS tech (although technically it was acquired), it carries a stigma.
I just found it un-intuitive, ugly, and verbose. Compared to my beloved python it looks really really bad.
I used PS to write small scripts and I actually like it. I'm more fluent with bash, but that's only because I used bash a lot. PowerShell feels more robust, no silly space-in-filename problems, no silly parsing of text output to access fields. May be it's ugly for big scripts, I don't know, for me it looked like a vastly superior version of shell.
I would love to learn why people think that power shell is ugly, especially comparing with bash.
I don't think people compare it with bash, but with more modern languages.
[PS] C:\> Get-MyReallyLongFunctionName -Server furtle
$ lol --floop
PS is fine but it takes ages for the bloody thing to wake up and notice command completion. It is like dealing with a teenager in bed.
Actually, I have no problems with PS but with MS's idea of search as deployed to users.
(I run KDE on Arch. Search is faster than I can blink)
Autocompletion still works, just type first letter or two after get and filter most stuff out.
And so I never become comfortable with it, even though I've tried several times since it was released.
The newer IDE is pretty good too.
But C# shows what it could have been if they'd had a talented language designer do it (which no-one can determine if someone is beforehand I admit).
I just wish they'd admit defeat and just use a subset of C# instead of stubbornly sticking with something that seems fairly widely loathed.
myfunc -param1 this -param2 that
instead of:
myfunc(param1: this, param2: that);
I get the impression it's designed with the intent that you're supposed to type the dash, then hit Tab to get tab-completion in most cases. Same with the verb/noun syntax (I know I want to 'Get' something, so typing Get-<Tab> for the list of things is usually the thing to do). I do find it a bit difficult sometimes to think of an approprioate verb right off the top of my head (is it Get- or New- that I need?).
I'd also love to see the concept of proper namespaces in PowerShell; it seems really inconsistent right now (unless I've missed something). For example, type Show-Command and hit ENTER, then look at the different modules that are available. Some will express a 'namespace' by having it prepended to the noun (see for example, commands from the BitLocker module, their nouns all start with BitLocker) while others express no namespace at all (see for example commands from the 'Dism' module). For everyday use I've gone with the 'add the name to the noun' approach in my own scripts. That does mean I tend to use short namespace names though.
I've mentioned this in an older PowerShell-related thread here - MenuComplete is absolutely awesome and improves the PowerShell experience in the console. I actually think it should be the default. If you havent already, try these commands:
Set-PSReadLineKeyHandler -key Tab -Function MenuComplete
Set-PSReadLineOption -ShowToolTips
PowerShell is my full-time shell in Windows now (and it will be in Linux also when I get back into it); I rarely use CMD for anything and parsing text in bash just seems antiquated.
I'm not talking about its unorthodox syntax - that's the least of its problems. The language is hellishly inconsistent and has an inexcusable number of legacy issues for being so young.
And the quality of the standard library is poor. More and more often I find I have to drop down into .net commands to work around showstopper bugs in their PowerShell wrappers.
Excel modules? OK not quite exactly the same but close.
I wrote a finite capacity planner system for a factory a fair few years ago in Excel to replace a huge number of Lotus 1-2-3 thingies with a vast amount of copy n paste from text screens and random sheets and what not.
I started with an automated forecast. We used an (memory may be fading) exponential fit which worked best using previous four weeks. eg last four Mondays would generate next Monday's demand.
The forecast could be tweaked by Planning at any time (aaaaiiiieee - Christmas!) The forecast was then fed into prep, make, bake, wrap and then dispatch. Between each process there is a stock holding. This is food so there are quite a few constraints on time, that's why we are making to forecast and not order. The customer will generally order your forecast if you are good enough and that is the whole point in the supply chain to the multiples: you know better than they do what will sell of your product.
The forecast cranks through the processes and stock points and generates a basic plan. It shows what efficiency is needed from each machine and the amount of manning etc. Oh dear you've got a Rademacher running at 170% which is a bit unlikely (110% is fine because 100% does not mean what you think it does in this industry - its a rate that is easy to achieve and not the absolute max). Oh and that machine is due 10 hours maintenance. Crap. OK, Mel off of Planning: do your thing ... a few parameters are tweaked, some production is offloaded to another member of the group and a packet of Hobnob biscuits is dispatched to a factory 200 miles away. The amended plan is run back through the model to ensure it satisfies the inputs and then when that is OK it is fixed for now.
I have not given too many details here as to specifics. I used a huge number of vlookups and I had a lot of code that ran through tables looking for the word "End" to indicate the last row (but one).
I basically found that VB gave me enough logic and whatever to get the job done in a reasonably safe way but without getting in the way of the business logic. I could concentrate on getting the job done.
Nowadays I'm a Linux (Windows and NetWare (lol)) sysadmin who masquerades as a PHB or MD but I still have a fondness for VBA. I recall getting someone's neural network spreadsheet VBA monster working after the most unlikely helpdesk call ever.
Good times.
https://www.youtube.com/watch?v=Qg4h1uv4o6Y
https://factorio.com/
You don't even need Excel!
http://ramblingcookiemonster.github.io/PSExcel-Intro/
I'm pretty sure that if you partner with someone that can package your food supply chain knowledge into a nice UI/UX experience (or doing it yourself, idk), you could produce and sell a decent piece of niche software for planning in food plants.
At $work we are into software for managing plants (not in the food industry), and the demand for tailor made planning functions is obvious.
This is the VB6 comparison in my book.
VB6 got me into programming as a kid.
I mostly use python for stats stuff. I sorta understand how to run up a GUI using tkinter, but it seems like a huge pain in the ass.
I'm sure Visual Studio offers the ability to do whatever VB6 could with a GUI, but it isn't obvious how to get there.
VB6 was one nice thing - build 'a program' as you understand them in Windows. Why the fuck is it so hard nowadays? VS isn't intuitive - it's a firehouse of information and I feel like you need training to use it. That is a bummer.
I just want to Lego-assemble a cute GUI-based program that I can make into a binary and email my wife to use. But I need to dedicate 70GB and two weeks of study to get there, I guess.
I got into coding qbasic (meh) & amiga (yeaaah) game engines in the 80s.
Currently teaching kids with Computercraft, to manipulate virtual worlds rather than boring spreadsheets.
IMO that sort of computer work will be obsolete by the time today’s kid are grown.
I’d probably avoid more than basic coding in general anymore and focus on math-y stuff. Just my take on where need will be, and discussing this with education researchers, and other thinkers.
I have a hard time believing we’ll carry as much code from the last couple decades as we had to from the previous few.
So much of it these days is web ui’s with a short shelf life relative to foundational code we shlepped forward in kernels, banking, and complex industry systems.
Maybe coding the Arduino/ESP32 game boy clones is appealing to today's kids.
The progression from there is python for those who want to control devices, or web dev for those more drawn to the visual design part. A missing piece is something for making games that sits in the middle of scratch and C++/unity. I don’t know how kids make that transition.
Or maybe Xojo: https://www.xojo.com/
I think Xojo was known as "RealBASIC" in the late 90s/early 00s and was really in the same spirit (but more cross platform) as VB6.
HyperCard occupies the same spot for me that VB6 seems to occupy for you. Today for stuff I'd have used that for in the 90s, I just stand up a quick little web app and text or email a link.
That's in no small part because nearly all of my wife's computing is done on an iThing and not on a computer that she could readily download and run something on. Unless I want to throw my cute GUI in an app store, it needs to be web-based now.
I downloaded Xojo and kicked the tires. It was absolutely cool to see that an environment like this lives on. It really does feel like a successor to VB6.
If you're interested in a GUI editor, this is the tool people are using these days:
https://www.sapien.com/software/powershell_studio
It's a paid product, but comparatively cheaper than VB6 was.
Great question. And I agree with the sentiment.
My opinion for "why is it so hard today": it has to do with the way .NET evolved right after its birth. .NET was a response to Java by Microsoft. What Microsoft did in effect was attempt to smother the Java juggernaut by introducing their own Java with J++ (Anders' team) but only available on Windows (their attempt to prevent the allure of Java's platform independence).
By all accounts that attempt was an astounding achievement from Redmond. It boasted interactive tools to create GUI drag and drop features users were accustomed to in VB6 but glaringly missing in the Java world. This was with Visual Studio 97. Then the lawsuits with Sun came. The aftermath of the J++/Microsoft Java debacle was the beginning of .NET. A "Java" for Windows with attendant crazies of the Java world. This is the reason why it is hard. Java was "hard" compared to VB6, therefore .NET had to be hard in the same way.
All analogous complexities associated with the Java world: build tools, runtime versioning tools and intermediate code compilers etc were forever required, keeping this huge katamari ball of technical debt alive for over 20 years.
Now we have .NET Core. So we've just reset the clocks and in one swoop gone right back to 1998 with a new Microsoft Java but this time it is cross platform!
22 years of a meandering path that ends up right where we started!
I am, quite frankly, exhausted.
> ...astounding achievement from Redmond. It boasted interactive tools to create GUI drag and drop features users were accustomed to in VB6 but glaringly missing in the Java world. This was with Visual Studio 97
Thay were not "glaringly missing in the Java world" in 1997 when Visual Studio was released. By that time at least these 2 IDEs with "drag and drop" were released and used already: Symantec Visual Café (a good one!), and a beta of IBM VisualAge (second part of 96). VisualAge came with specific ibm's understanding of drag and drop, however the Visual Café's experience was really similar to VB and much easier than J++ from what I remember. I tried all of them at the time including JBuilder and Sybase. JBuilder was my best for quite time.
The original version was an attempt at Delphi for Java and I liked it far better than Netbeans later, but I came from Delphi to Java so that makes sense.
Same. But I have remained with Delphi. I think we are now known as the lost generation. :-)
Accepting new members into the club? :)
1."No bullshit" - stick to the fundamentals and don't waste time over-engineering, relying on complex builds, producing ambiguous compiles (ok, we're still fixing this), relying on bulky runtime architectures. Have straightforward source code. Native. Straight-talking. Quick-compiling. Hard-hitting. Because Shipping Matters(tm). Only thing that matters. Shipping. No bullshit.
2. "Fiercely independent mindset" - Members know that they must use the right tools for the right job, but members must also display a strong ability to not be swayed by what employers are hiring for. Latest shiny flavour of tech, framework, language, might look good on your CV but many times the conclusion for "What is the right tool for this job?" can still be answered: "Delphi". Stand your ground.
So, if you are a CV-oriented programmer, you will most likely not want to do Delphi. There is an indelible and horribly misinformed meme out there that there are no Delphi jobs or that Delphi is dead, is old, outdated and irrelevant in modern software architectures. I have seen this ageist misinformation come out as lame attempts to ridicule Delphi programmers (jealousy?), branding them luddites and dinosaurs. We never retaliate. Quiet stoicism is a prerequisite for club membership.
Finally, the Delphi club also has a new membership protocol: always buy them a beer. No matter whether they eventually get accepted in the hallowed halls of this quiet corner. :-)
Cheers! <clink>
Delphi is a victim of its stewards management post Borland.
Last great decision, remove reference counting and back to full manual memory management on the upcoming Delphi version.
BTW, I used JBuilder extensively. What a topnotch tool from Borland. Pity they didn't survive the virulent competition during those IDE wars period. I still remember settling an argument with a colleague about his insistence to use the newly arrived Netbeans, while I fired up my JBuilder IDE (Yellow Porsche splash screen IIRC), created a gui, added jdbc data controls, coded a few lines and hit compile - ALL while his Netbeans was still loading with that dastardly progress bar.
(These comments have been much needed catharsis for me.)
Code emitted JBuilder's tools was not isolated from other code that was written for the application. It was easy to add a line of code that would make the included builder tool to not show the resultant GUI correctly.
This was from JBuilder 9 and JBuilder 2006, other than that issue it was a really nice IDE to use.
However I do agree Visual Basic and Delphi were much better, and if Java hadn't happened we wouldn't have lost 20 years playing around with VMs and dynamic languages, to finally start paying attention to AOT, value types on type safe languages.
edit - I'm guessing whoever downvoted doesn't know who Trent Lott is.
It's wierd enough that any old niche forum friends I've lost touch with would recognize it...and I can't imagine anybody else would use it coincidentally. He's been a non-figure for years and years
Your curiosity demands more upvotes than I've got!
My takes is because it's not modular enough. Sure it's easy to plop this and that components here and there, add events, etc. However as requirement changing each pages / sections need to be changed as well. Not to mention portability to linux or mac. That and we're talking about db access, drivers, and security (in memory data sniffing / tepering).
Of course it doesn't applied to all kind of apps, but those who need constant changing are the one who pays Microsoft bills.
If you're starting from scratch, VB.NET is not really any harder to use for this purpose than VB6.
It really annoyed me that I couldn't get nice bitmaps in menus so I eventually learned about Ownerdraw. That changed my life. Having to hook into the wndproc and all the other windows api calls introduced me to C, and so I naturally started experimenting with C++. All without internet, stackoverflow or groups.
I'm now write C++ for a living.
The strength of VB6 was a simple and straightforward syntax and a great integrated GUI builder and IDE.
Powershell has none of that. The Powershell syntax is baroque due to the (necessary) compromise between command line syntax and scripting language and there is no IDE/GUI-builder.
Sure, Powershell is much more powerful in many ways, but that was not the draw to VB6 in the first place.
The debugging environment was better than any I have used since. You could drag the execution point anywhere, edit code in between steps, view everything. It was amazing.
IntelliJ is pretty good now, but not like that.
Other than the amount of work it would take, what's to keep someone from taking all of the specs and docs, and implementing a language compatible with VB6 and VB.NET?
But, ignoring that, almost any app of any complexity in VB6 land will rely on bugs, quirks, and implementation details. (Also, I was never clear if the binary format for editing forms was actually documented somewhere). Someone could implement their own VB6 parser, but it seems like a ton of work for a vanishing market.
All of that said, while typing this, a quick search revealed https://www.radbasic.dev/ , so maybe someone's trying. Well, it's a Kickstarter, so maybe someone just has an idea. Dunno.
That market isn't going anywhere anytime soon, though.
There are a lot of XP machines out there running critical VB code...
https://www.xojo.com/index_xojo.php
Not open source but it looks quite interesting.
Microsoft said this week that it will support Visual Basic on .NET 5.0 but will no longer add new features or evolve the language.
“Starting with .NET 5, Visual Basic will support Class Library, Console, Windows Forms, WPF, Worker Service, [and] ASP.NET Core Web API … to provide a good path forward for the existing VB customer who want [sic] to migrate their applications to .NET Core,” the .NET team wrote in a post to the Microsoft DevBlogs. “Going forward, we do not plan to evolve Visual Basic as a language … The future of Visual Basic … will focus on stability, the application types listed above, and compatibility between the .NET Core and .NET Framework versions of Visual Basic.”
When Microsoft released the .NET version of Visual Basic, originally called Visual Basic .NET, alongside C# at the beginning of the .NET era, the two languages were evolved together and had roughly identical feature sets. But this changed over time, with professional developers adopting C# and many fans of classic VB simply giving up on the more complex but powerful .NET versions of the environment. Today, virtually all of Microsoft’s relevant developer documentation is in C# only, with VB source code examples ever harder to find.
Worse, Microsoft in 2017 announced that its original C#/VB co-development strategy was over. Only C# would get all of the new features, while VB would focus on the simpler and more approachable scenarios that it once dominated. But that never really happened, and Microsoft effectively abandoned VB. This week’s announcement just makes it official.
What this means to VB developers is that they might be able to bring their existing codebases forward to .NET Core or, soon, to .NET 5.0, which will replace both the traditional .NET and the open-source and cross-platform .NET Core when it’s released in late 2020. The issue is that not all legacy technologies will be supported going forward, so developers using WebForms, Workflow, or Windows Communication Foundation (WCF) will need to stick with classic .NET. Those applications will continue to work and be supported until the underlying Windows versions are retired; classic .NET support life cycles are tied to the Windows versions on which they were initially deployed.
Microsoft also notes that VB developers will occasionally benefit from improvements to Visual Studio.
“Visual Studio regularly adds new features to improve the experience for developers, including those using Visual Basic and either .NET Core or .NET Framework,” the .NET team adds. “An example is the recent addition of IntelliCode for Visual Basic.”
This is a sad day, and one that hits me personally. I started my writing career with Visual Basic 3, went on to write several books about VB and its various variants, and most recently wrote an entire Notepad clone called .NETpad in Visual Basic, Windows Forms, and the .NET Framework.
Then next year I enrolled in AP Comp Sci - hardcore turbo c++. Just blew my mind!
Funny enough, AP Comp Sci went the other direction in the early 2000s, switching from C++ to Java precisely because it was too hardcore for the average high school student.
E.W.Dijkstra would disagree: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Or maybe Dijkstra was wrong.
People who are really good at manipulating other people seem to have a hard time learning to do productive things, maybe because it's too easy to manipulate other people to do them instead, but maybe because people sometimes follow the Law of Attraction, where you make wishful thinking come true by believing in it hard enough, while software and Volkswagen engines do, if anything, the opposite.
More broadly, I think any field of learning carries with it a sort of implicit value system: we consider things x and y centrally important, while things a and b are inconsequential details. Much of learning a field involves internalizing these values to the point where you apply them automatically without even being aware that there's an alternative. But often they are suboptimal or even counterproductive in a different field. Volkswagen engines don't care about paint color or whether your grandfather just died, but they do care about thousandth-of-an-inch tolerances and not making mistakes. Interior decorating doesn't care about thousandth-of-an-inch tolerances or clean abstractions, but it does care about paint color and whether your grandfather just died. Debugging software doesn't care about not making mistakes or paint color, but it does care about clean abstractions.
This is even true in subfields within the same field: real-time engine control software cares about memory allocation in a way that seems completely insane to anyone who programs in Python, for example.
BASIC tends to reward novice programmers for banging on a piece of code cluelessly until they get it to work in some cases. Dijkstra, by contrast, believed that what was important was having sufficient logical understanding of the program's space of possible behaviors that you could be sure it would work even before testing it; he in fact designed and successfully taught an introduction-to-computer-programming course that used no actual computers. It's unsurprising that someone who had internalized BASIC's value system would be extremely resistant to Dijkstra's preferred approach, and that Dijkstra's disciples would be extremely resistant to the BASIC approach, even though in fact they are complementary, and each one works best for some classes of problems, so those who are best at one of these ways of working are those who would gain the most from learning the other.
I totally understand how someone trained in VB was "mutilated" for CS. Because the priorities for CS coding are totally different than for commercial coding.
But from an IT perspective the point of programming is to be profitable, not perfect. VB allowed people to write profitable programs quickly. It was a fantastic environment if all you wanted to do was write desktop applications for businesses.
The quote isn't about VB; its from 1975, VB was released in 1991.
The quote was also thrown around a lot in the late 90's as a "VB sucks, you should use a real programming language" comment in the usual language flame wars.
Yes. And Dijkstra would be wrong. (Or, perhaps more accurately, prone to somewhat bombastic hyperbole.)
BASIC is structurally similar to ASM, moreso than is any other HLL, at least of any popularity. Like almost any language (or paradigm) it is possible to get stuck in its particular ruts, and when BASIC was at its peak popularity there were probably lots of people stuck in those ruts just as later happened with Java and the static, class-based OO paradigm more generally. A learning language isn't something you stock with exclusively, it's something you learn with and then diversify from, ideally, and for that, BASIC (old-school unstructured imperative BASIC) is great.
Dijkstra was trying to promote structured programming languages like Algol and Visual Basic is based on the QBasic dialect which has full structured programming features like WHILE and FOR loops, IF that would work with compound statements (that is have the THEN part be more than a single command), local variables, functions, recursion, etc. It might be hard to image nowadays but there was a time when those weren't available to all languages. Though note that the next year after Dijkstra wrote that quote, the original Dartmouth BASIC actually got structured features. Though it wouldn't be until QBasic that you'd see a (popular) BASIC dialect having those in home computers.
Regardless, this quote was outdated long before Visual Basic 1 was made, let alone VB6.
https://github.com/peteri/ClassicBasic/blob/master/Games/kin...
Note that this is a bit more readable than what people worked with since now you have syntax highlighting.
I'm not sure where tail calls enter in the picture... there wasn't even support for functions, at best you had GOSUB/RESUME which was essentially assembly-like CALL/RET.
GOTO essentially involves setting the continuation of your program to something other than the following instruction(s). That's what a tail call does. No "functions" involved except as a high-level description.
Firstly, RESUME was to continue execution after an error (eg ON ERROR RESUME NEXT). I think RETURN is what you might have meant?
Secondly, you cannot RESUME/RETURN from a GOTO. I think you meant GOSUB; which was a crude approximation of subroutines. BASIC did also have GOTO as well though.
One of the places I like gotos is when I need to break out of a nested loop. A goto to outside of the outer loop is far more obvious than a flag and a conditional to break from the parent nested loop. It also generates better machine code and uses fewer registers, at least in debug mode.
Sure, goto can be abused, just like every other language construct. They have their time and place, though.
It is like having an army of soldiers armed with a David Crockett[1] instead of a regular rifle. Things may get ugly fast.
[1] https://en.m.wikipedia.org/wiki/Davy_Crockett_(nuclear_devic...
Several years later the jump in quality was astonishing. Good ODBC drivers and easy linking between database rows and your UI make it a fast development tool that fit many needs.
I do not miss the big colored buttons that many developers used at the time. Never as bad as Access applications used to be, thou.
I'm sure in general Microsoft would love to scrap VB in Excel but there's too many companies that run entire areas of business on it, or the whole business itself.
It is the typical legacy/back compat problem. Python or even Powershell would be a vast improvement, but you're going against billions in sunk cost/skills/knowledge.
VB.Net was slowly losing popularity, VB in Excel isn't.
Retrofitting a multiple-language runtime under VBA would likely be a big endeavour, and in the end most people would probably stick to the established language anyway.
https://en.wikipedia.org/wiki/Visual_Studio_Tools_for_Applic...
You're a real team player. That's both rare and invaluable on current days of resume-driven-development.
I know a couple of places like this, no R, no Python, VB all the way.
CIL doesn't have that problem, you can keep writing in VB.Net without being forced off a supported compiler.
I was in a fork in the road and had the choice between Python or .Net to move forward with my career a few years back, there were a few factors on why I went .Net. Being one of very few pleasing to use and (extremely) widespread languages with static typing, along with MS's early embrace of WebAssembly were both major influences. Yet the biggest was the Python core devs refusal to address Python2/3 in a better way. There's no good reason why you couldn't use the same Python 3 interpreter for Python 2 code. I get the maintenance argument, but this raises questions about the future, and it makes their platform look rinky dink today. I came to the conclusion I'd never build anything important on it, which is essentially everything you write, as projects tend to grow.
Nor is it going anywhere. It's simply joining the ranks of legacy-but-stable-and-supported tech like MFC and WinForms.
I sometimes miss VB.NET's XML Literals/Embedded Expressions feature. Back when virtually everything spoke XML, it was very nice to have first-class support for XML as a language feature. https://docs.microsoft.com/en-us/dotnet/visual-basic/program...
There were other language constructs at the time that werent 1:1 parity at v1.0, but in nearly 20 years time, I forget.
It wasn't perfect. There were lots of problems with it. It would never win prizes in CS competitions. But man you could build shit with it fast.
A couple hours work in VB saved non-technical people hundreds if not thousands of hours of repeated effort. Killing it is a mistake in my opinion, Even if I haven't touched Windows since 2010, VB.Net is the one wonderful thing it had going for it.
VB6 can call win APIs and C++ code for when some arcane functionality is needed.
ps - noticed the employer on the profile. Powershell + .NET assemblies crushed it, and VB.NET was a far superior language (though, just like all the jvm languages have the same feel, all the IL based ones did and why not use C# at that point?)
"There’s something deeply right about how list indexing and function application are the same operation". That is a quote from a recent submission about K (https://news.ycombinator.com/item?id=22504106), and that is a perfect example of how I usually get VB nostalgia attacks: somebody talks about a thing in other language they consider amazing implying that that thing is unique for that language despite it was implemented in VB and earlier. Sometimes that somebody can ever be Microsoft as they brag about adding more features into C#'s switch statement with increasingly ugly syntax in every new version completely ignoring that they did them better in VB.
I thought HN was supposed to collapse duplicate submissions to a single topic? URL appears to be identical. Is there some kind of cache issue in HN's backend?
To your main point, the dupe detector seems to be fairly limited; I think it only checks for the same URL in the past 12 hours or 100 posts or something. It seems to be just to keep the same post from showing up multiple times in /new.
I moved on, to the web, to things like TCL/TK, Java, and Perl. Some things never change, I have a full screen vim window with a brand new perl script on my right-hand monitor as I type this.
Despite having dumped windows 20 years ago, I've still got a place in my heart for visual basic.
I was just a kid, maybe 10 or 12, when I learned to program with QBASIC and later VB5. I remember strongly feeling that a ".bas" file wasn't a real program. I so much wanted to be able to run my programs as real .EXE files. There was some kind of QBASIC compiler that made an .EXE but I felt like that was just... still not real enough. That desire for making a real bonafide .EXE was one of the driving reasons I (tried to) learn C.
But, Windows Forms with C# was just as easy as VB6 and VB.Net was just as complicated and more verbose than C#.
Microsoft politics after hiring Anders Hejlsberg who designed C# as a competitor to Java so Java's compile-once-run-anywhere wont take a foothold on the desktop market and thus endanger the dominance of Windows, required that everything related to developing software for Windows was focused on C# and .NET to drive home to ISVs that this is the future, but up until that point VB6 was wildly popular - and absolutely incompatible with anything related to C# or .NET. So they reskinned C# with some VB clothes and paraded it in front of VB6 developers, hoping they wont notice the sharp bits sticking out - which worked as well as you'd expect. But with Microsoft having full and absolute control over VB6, it isn't like anyone could do anything about it, so over time people moved on. VB.NET never managed a hint of VB6's popularity and was always in the shadow of C#, which made perfect sense since outside of liking QBasic-like syntax more than C-like syntax, there wasn't any reason to use VB.NET.
Instead of actually learning principles and practices, and a 'good' language, they could just hack something together than managed to just barely work, armed with a $99 copy of Visual Basic and a 'Teach Yourself VB in 21 Days' books from SAMS publishing.
And by the time they knew any better, they were up to their ears in shit. Chances are, if you have a big project in VB, you also have the following problems:
* You're not using version control. Or worse, you're running Sourcesafe.
* You're not using secure encryption or communication
* You're not using secure programming practices
* You're not using a modern, secure OS
* You're also using some 16 or 32-bit utility libraries that nobody has the code to
* You're employing developers who have 20 years of "1 year experience with VB"
* No need to write a business case with fake ROI figures. No IT committee meeting. No need to teach a “solutions architect” who doesn’t really care to learn.
* Easier to evolve as requirements change because the front line person is fixing it.
* Proof of concept done already when you need IT involved for version control, security, etc.