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.
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.
>>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.
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.
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.
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.
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.
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.
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).
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.
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.
HTML/JavaScript. That has the shortest start-making-a-GUI story (plain JavaScript; React/Webpack/etc. absolutely do not have this level of accessibility).
> 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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
>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 ...
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.
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.
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?
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
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.
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.
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.