Hi! I was the lead developer for Ruby (no relation to the programming language), which became the "visual" side of Visual Basic.
It is nice to see this article again.
Perhaps my favorite part is this true story that I shared with Ryan at Retool.
If you ever wonder why we "fire" an event, this is why:
# # #
I was looking for a name for one gizmo sending a message to another. I knew that SQL had "triggers," and Windows had SendMessage, but I didn't like those names.
I got frustrated one night and started firing rubber bands at my screen to help me think. It was a habit I had back then to shake up my thinking. Probably more practical on a tough glass CRT than on a modern flat screen! After firing a few rubber bands, I was still stuck. So I fired up a doobie to see if that would help. As I flicked my lighter and looked at the fire, it all came together. Fire a rubber band. Fire up a doobie. Fire an event!
# # #
My other claim to fame may have been the VBX. It was likely one of the worst APIs in history, but also one of the most successful.
Go figure.
As they say, AMA!
And as it happens, I am looking for work. If anyone doesn't mind working with an older programmer who is still enthusiastic and productive and creative, you know where to find me.
lucastech · 25m ago
I have to say, Visual Basic 4.0 changed my life when I was introduced to it at the age of 12. I had written Basic before that, but being able to build drag and drop create a GUI on top of my code was what really hooked me on programming. I built and sold my first desktop application at 14 that I wrote by myself in VB6 and used VB6 for all of my jobs through 21 when I had to upgrade a VB6 application to C#.net.
I often harp on how much I wish someone would build a simple GUI for the modern desktop or web environment, instead of spending ages fighting css and javascript for even the most basic layouts. Visual Basic just removed all of the complexity, nothing filled that gap before VB or after VB. Sadly, even VB these days is a mess ever since winforms stopped being the primary target interface.
Thank you for what you built, I've been writing code for 26 years now as a direct result of it.
Stratoscope · 4m ago
Oh my gosh! This means a lot to me.
I should mention that wasn't just me. Alan Cooper came up with the initial idea and a prototype called Tripod and showed it to Bill Gates. After Microsoft funded the project, Alan hired me, and Gary Kratkin, Frank Raab, and Mark Merker to build out the actual Ruby product. And then a team at Microsoft melded it with Basic to become Visual Basic.
I am really grateful that you and so many people put our work to good use!
memset · 9h ago
Wow!
I learned programming via QBasic (in 21 days!), then VB3, then VB6. My father still writes toy programs in VB6. Things like binding Access DBs to controls was magical to me.
What would it take to have a VB today? I feel like the web, APIs, auth, screen sizes, they’ve all become so complicated. And while Retool aims to make it as easy to develop, it’s just not the same.
What would it look like to really feel “the same” as the good old days?
vikingerik · 2h ago
C# or VB.NET or MS Access with Winforms still exists and you can still use it, but you wouldn't for anything more than a personal toy.
I don't think you can do anything nowadays that replicates the VB style of interface design. That was completely tied to a fixed layout and only a few desktop screen sizes, but everything these days needs screen size responsiveness from mobile to 4k. And you also need cross platform, accessibility to screen readers, language localization, dark mode, and so on. A flowable and styleable layout just works better for everything, and runs in the HTML/HTTP client that every device already has. Sadly the VB style of design was a temporary waystop and not an enduring norm. I guess the closest you could do would be a big HTML table and just let the small screens scroll biaxially painfully.
Stratoscope · 8h ago
Thank you! It always warms my heart to hear how people have used our team's work over the years.
As to what it would take to have a VB today, VB.NET still exists:
Of course at that point you could also use C# instead of the VB.NET syntax (which is rather different from "classic" VB).
90s_dev · 7h ago
I am so close to announcing my project that I hope both you and the OP will appreciate, precisely because it aims to resurrect 90s development, to see if we can do better than we have in the past 25 years, standing on nothing but the benefit of hindsight.
90s_dev · 7h ago
If my upcoming project takes off and makes any money, I would hire you in a heartbeat!
antman · 6h ago
I would love just a new VB if you have the time….
msephton · 13h ago
Would love to read more about your Ruby. Have your written about it anywhere? Even old HN comments would be welcome.
Stratoscope · 8h ago
I wish I had written more about it! I would love to revisit those days too.
There are a few old HN comments that I wrote and you can find here:
You will have to scroll past a lot of comments about the Ruby programming language.
msephton · 1h ago
Thanks! I'm digging in. I was already coding in GFA Basic on Atari ST when I encountered Visual Basic on Windows. I'll never forget that moment - truly a new dawn!
warpspin · 16h ago
I wonder what the programming language was like which you used, before BASIC was put into the product?
Stratoscope · 8h ago
It was an extremely primitive language in the style of DOS batch files.
But that was really kind of a placeholder.
We didn't hardwire the language into the Ruby code, we made an API to allow other languages to be plugged in. And that's how it was easy for Microsoft to plug Basic in.
In fact, I completely forgot the original purpose of Ruby. It wasn't intended as a complete programming environment, it was going to be a new "shell" (desktop) for Windows 3.0. Windows users would create their own custom desktops using Ruby and our primitive batch language.
Somewhat related, there used to be stories about how Visual Basic was originally not going to allow third parties to create custom "controls" (or "gizmos" as we originally called them). But Bill Gates insisted on making it extensible.
That may be true in a narrow sense, but it misses the bigger picture.
Of course we had to create a gizmo API from the very beginning, for the original set of gizmos we had in Ruby. Buttons, lists, text boxes, and so on.
My understanding is that the Visual Basic team didn't want to publish this API in the original VB release, perhaps to get the release out sooner. But Bill insisted that it be included.
znpy · 16h ago
> I fired up a doobie to see if that would help
For those, like me, that are not native speakers of english and not familiar with the slang: a "doobie" here is a joint. Basically weed (marijuana).
@Stratoscope correct me if i'm wrong
Stratoscope · 8h ago
Thank you for the clarification. Yes, you are correct.
And no, I didn't set one of the Doobie Brothers on fire!
RebeccaTheDev · 21h ago
I miss VB6 so much.
For rapidly prototyping an idea, I have yet to find anything that was as good as VB6. Drag a button, write code. Want to change things about the button? Use properties, that live update the GUI without recompiling. It was so simple that a reasonably intelligent person could grasp it in an afternoon, but in the hands of a capable developer could do some very impressive things.
It was also a fun game to hunt for VBX/OCX controls that you could use in things that were downloaded or came on random disks or CDs.
I really feel like VB6 was the peak of that development model and we've been moving away from it since. And I get some of the reasons why (just look at the mess that comes from trying to do anything with Xcode storyboards and version control.) But for just rapidly trying out an idea, I have yet to find anything anywhere that was as good as VB6 was.
account-5 · 20h ago
I feel the same about MS Access databases, for databases obviously. Provided you kept within its limitations, and actually used relational models, it was really quick at setting up a database program. I never used VB6 but the workflow sounds similar.
akoster · 3h ago
I agree! I still sometimes use LibreOffice Base for quick prototyping [0] or Microsoft Access if I am on Windows. It uses HSQLDB by default but you can connect to several external JDBC, ODBC and ADO compatible databases, though I often use DBeaver for that purpose. [1]
It was almost exactly the same expect in VB you had use some esoteric code to access databases — and they kept changing what was the “proper” way to do it. (I think by the time I quit VB it was ADO?)
int_19h · 3h ago
It was indeed ADO (ActiveX Data Objects) - Connection, Command, Recordset etc - and this is also the API used by Access.
Microsoft wouldn't be Microsoft without having confusing naming for its APIs, so the one before ADO was called DAO (Data Access Objects).
There was also some very confusing layering in play. ADO didn't work with the database directly - it was a layer on top of either ODBC or OLE DB, depending on the database.
jemmyw · 17h ago
I don't recall it being particularly esoteric. There were libraries to call various databases. In my first job I converted a vb6 application from Foxpro to SQL server. I was just getting into Ruby on Rails at the time and wrote a COM library the the data layer that was somewhat like activerecord, and ended up using it from ruby scripts. Fun times. Just looked it up and the software still seems to be being sold 20 years later.
int_19h · 3h ago
.NET with Windows Forms - either C# or VB.NET, depending on your taste - is very similar in experience, and is still a fully supported stack today even in the most recent .NET versions (so you get e.g. high-DPI support, dark mode etc) with new features added regularly: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/wh...
akoster · 3h ago
Thanks for sharing! I'm glad Microsoft is still providing active development for WinForms and on recent .NET Core versions and not just .NET Framework, although the later seems to still be supported indefinitely (for now?). [0]
I totally agree with this. When I worked at a University (mumbles) years ago I wrote a build system for rebuilding the OS and apps on student lab PC's and I used VB6 as the front end. It seemed in those days we could do anything, and nobody told us we couldnt do it.
I also made a simple two button menu app for use on repurposed 386's that we were using as thin client pc's. Years later I went back to see they had been replaced with tiny HP thin client devices but my menu was still being used!
anthk · 8h ago
Lazarus and Turbol Pascal it's close.
Also, TCL/Tk with Tcllib and TkLib plus maybe Tkimage and SQLite3, which was born from TCL code. With that you can create a fast RAD tool in hours.
bitwize · 8h ago
Tcl/Tk mentioned. Let's goooooo!
I have never, for the life of me, found a quicker way to go from zero to GUI than Tcl/Tk. Even VB requires a lot of rat wrestling to set up a UI. Some people think that's how it should be done, but compared to just telling the machine what you want and letting it take care of layout, to me it's still cumbersome. Plus, Tk has had hierarchical, relative positioning and sizing, no need for doing layout in terms of absolute pixels or "dialog units", from the jump.
anthk · 8h ago
Also Tk is in every language, as it's dumb easy to duct tape it into C. TkInter, Perl-Tk... I'm pretty sure if some Forth user created a Tk UI for PForth/GForth, it would be almost as easy as in TCL, but with the syntax reversed. That's it, you would find 'pack' in the end of a sentence full of words.
billfruit · 9h ago
Doesn't Lazarus serve a similar purpose?
mikewarot · 9h ago
It could, if the documentation were usable. 8(
akoster · 3h ago
Thankfully their forums are quite active with folks sharing lots of sample code [0]. I was able to get some assistance with getting their SQLite library to work. Also the wiki has quite a few tutorials - when I get some more time I hope to check out this pas2js Electron tutorial. That would be something quite useful to go from a WYSIWYG RAD IDE design to a working JavaScript web app running in a browser.
What people forget is that VBA is still built in to every copy of Desktop Excel (press alt f11) and is used by entire industries that are disconnected from the open source tech online discourse. In a lot of locked down business environments its the only automation an employee has access to. If macros suddenly got Thanos snapped out of existence tomorrow the entire economy would grind to a halt. People keep saying VB is dead but it probably processed some of your information today somewhere in some cubicle.
kjellsbells · 3h ago
Every time I try and automate Excel it pushes me towards TypeScript, which I accept is probably the future for Excel automation...except that when you really need to do middling to advanced Excel, Microsoft's Typescript engine throws up its hands in despair and I am forced to pull out VBA.
I really wish the VBA IDE got some love, but I guess that will never happen.
Sn0wCoder · 23h ago
Not going to lie I was exited to see this work lol. Thanks for the tip of the day. I love learning and not sure what I was expecting to happen when I opened up excel and hit alt + f11 but it was awesome to see it open. Already created my first user form and now the rest of the weekend its going to be difficult not to go down this rabbit hole. VB once paid my bills....
romanhn · 22h ago
There are still companies running their web backends on classic ASP with VBScript. Not to mention VB6-based desktop apps. Thankfully fewer and fewer each year, but they exist.
ghssds · 22h ago
> Thankfully
Why? If it works...
romanhn · 22h ago
End of life software running on top of end of life software. Hard to hire for this stack, especially anyone who cares about tech. Security and maintenance nightmare. Interoperability is a pain. Questionable documentation. It all works until it doesn't, and then you're in the world of pain.
potoooooooo · 9h ago
Not all of these issues apply to VBA, which the top level comment brought up,even if they apply to VB6 and the other ones you mentioned. VBA isn't EOL, and Excel certainly isn't.
Lots of people are continually building sophisticated tools in MS Office even though it's not helpful for the resume because it's the path of least resistance for solving problems for the sorts of people who just learned VLOOKUP in 2021 and don't want to learn about XLOOKUP now.
Security, maintenance, interop, documentation... There are arguments to be made. It's not cut and dry that VBA is the worst option for any of those. The patterns for handling them are different than a web app repo or something, but it's not like they don't get thought of and handled on a daily basis.
jackvalentine · 21h ago
A client of mine used Visual Foxpro for… way past its used by date, for a crucial database in a crucial aspect of a crucial industry. When it inevitably failed spectacularly they struggled to get anyone who knew what was up to intervene. Same client kept poor backups.
Recently persuaded said client looking for a new solution to support a new line of business to go with the .NET, actively developed system over the ‘free’ VB6 desktop application that a charity developed a billion years ago and wanders around the industry inflicting pain.
anthk · 8h ago
Active X it's a security disaster.
int_19h · 3h ago
Only in the context of embeddable web components, and only because running non-sandboxed native code in the browser is a security disaster in general, not because of anything specific to ActiveX.
Outside of that context, ActiveX is simply a well-defined object-oriented API and ABI for cross-language use.
anthk · 3h ago
It wasn't any better for Windows 98 with IE bundled in the shell, and audio parsing functions right in the kernel.
Up to the point tons of people chose to revert W98's shell to the Win95 one, having a good speed boost on some PI-PII machnes.
VB6 was a good idea as a RAD tool; but, as TCL 7.x (and the older 8.x releases), the performance wasn't fast enough until some Pentium 3/Pentium 4 for 'big' software. Not an issue for a boring company program or the 234000000nth shareware crossword puzzle software for PC magazines or sites as Softonic. Or some whatever catalog hooking up some Excel/Access libraries, or nice in-sormware forms borrowed from IE DLL to create zillions of similar shovelware.
That kind of niche software was everywhere.
Ditto with some simple games written in VB; but the native ones outperformed VB ones with ease. And, yes, you could call native DDL's, but most amateur programmers didn't do that.
znpy · 16h ago
> Thankfully fewer and fewer each year, but they exist.
Are we sure we should be thankful?
Looking back on VB6, now that i'm in my mid-30ies, i think it had some great points. Basically, a simple app was fast and easy to build and did not require to ship (!) and run (!!!) an entire google chrome instance to render a few buttons, some textboxes and a bit of logic.
romanhn · 10h ago
I have no issues with VB itself, but the technology is long obsolete and any organization that still has it somewhere in their business is taking on risk that should have been mitigated years ago. Realistically, these apps are not simple apps with a few buttons. I happen to know that the complex, business-critical VB6 app used by the company I interned for 25 years ago is still out there, still supported by the original team! That's a ticking time bomb, as far as I'm concerned.
BTW, the VB6 experience is still somewhat attainable with .NET WinForms (can even use VB.NET if you so desire). Showed my kids how to build simple apps a couple years back and the overall process of dropping controls on a canvas and wiring up events was pretty much the same.
int_19h · 3h ago
VB.NET is an underappreciated language for teaching in general, IMO. I especially like their choice of keywords being very descriptive rather than traditional. For example, `Overridable` rather than `virtual`, `MustOverride` (for methods) / `MustInherit` (for classes) rather than `abstract`, `Shared` rather than `static` etc.
90s_dev · 22h ago
> Excel, press Alt-F11
:O
showerst · 1d ago
What a great article. My first exposure to real programming was VB and it’s hard to overstate how magical it was to just drag a button onto a form, and double click on it to write a few lines of code and wire it up. TBH it’s still something that I miss in the modern world, likely killed forever by the huge diversity of display devices.
It’s funny how lousy VB (and PHP a few years later) were as programming languages, even for the time. But they got stuff done, which is a good lesson.
vunderba · 1d ago
Agree - while the concept of event-driven programming was not without its quirks, it was very easy to grasp for a newcomer.
I do think the WinForms editor in Visual Studio C# was a pretty decent spiritual successor that came close to capturing the magic of a drag-and-drop GUI builder. Aesthetically lacking but highly functional.
jeswin · 23h ago
> I do think the WinForms editor in Visual Studio C# was a pretty decent spiritual successor that came close to capturing the magic of a drag-and-drop GUI builder. Aesthetically lacking but highly functional.
It required the .Net Framework to be installed, which in the early 2000s (with far lower internet penetration and speeds) was a big enough problem. It wasn't particularly great either - Microsoft's attempts to port their own desktop products to .Net mostly failed. It was basically Java for the Windows Desktop, and never quite took off in the way VB apps did.
int_19h · 3h ago
Today isn't the early 2000s, though. For example, every version of Windows shipped in the past ~20 years (starting with Vista) comes with .NET. And it is in fact very common for desktop apps on Windows today.
vintagedave · 22h ago
WinForms itself was largely a clone of Delphi. C# through version 2 was essentially Delphi with C syntax.
int_19h · 3h ago
It would be more accurately described as a blend of Delphi and Java, the latter via J++. The overall object model is from Java, tweaked to merge the primitive types with their boxed wrappers (i.e. `int` vs `Integer`). C# strings and arrays were also almost a carbon copy of Java rather than anything Delphi-like, although it did add multidimensional arrays. From J++ it got delegates and events. From Delphi it got things like properties and explicit `virtual` on methods, but notably not e.g. overridable class (static) methods or named constructors. Also, Delphi had manual memory management, not GC.
neonsunset · 3h ago
> C# strings and arrays were also almost a carbon copy of Java
You'd be surprised but .NET and Java strings have a lot of differences. In Java, String is a class which wraps byte[], in .NET - string is a "FieldSeq" object with characters stored inline. One indirection less but with no special fields and cached state like in Java.
Arrays have significant differences too, where Java arrays do not implement any actual collection interfaces - they are just contiguous chunks of elements with an indexer and length field and need to be asList'ed, so it's common to consider in Java to rely on arrays an anti-pattern, which is the opposite to C# arrays, which implement the full set of System.Collections.Generic interfaces.
raddan · 1d ago
I also used both of these at a formative time in my programming career, and it really felt magical. I built half a dozen little apps, some using Access (another product whose loss I mourn), to solve problems at the small company I worked for that “professional” developers quoted us many times my salary to develop.
analog31 · 23h ago
I think that the earliest methods of programming windowed computers were just way over the heads of mere mortals, including myself. For those of us where were comfortable with earlier computers, GUI required simultaneously grasping OOP, a mountain of opaque documentation, and a complex IDE and build process. All at once.
No surprise that the first GUI programs I wrote were in LabVIEW and Hypercard, followed soon thereafter by VB.
While I'm not a commercial developer, I still avoid any "stack" where the tutorial for "Hello World" doesn't fit comfortably in one page.
int_19h · 3h ago
Earliest practical GUIs were (Smalltalk aside) generally not OOP but rather procedural - an explicit message dispatch loop, message handlers that were basically huge switch statements etc. Here's the listing for a basic Win32 app (Win16 looked very similar):
OOP was bolted on later to make this all more manageable. Indeed, VB itself, which is object-oriented (even if it lacks some common features such as inheritance) is a prime example of that.
01HNNWZ0MV43FF · 21h ago
GUIs are still harder than they need to be. Async patterns that don't compose, operating systems where CLI and GUI programs are separate concepts entirely, massively complex GPU-based stacks needed to fill 800 MP/s...
I no longer blame people for punting to Electron. As bad as HTML is, it's still only 100 MB to save yourself from the worst parts of GUIs.
int_19h · 3h ago
On Windows, GUIs are still as easy as they were in VB6 days if you pick the right tools.
It only becomes a headache if you need cross-platform support. Although even there options like Avalonia are far superior to Electron.
anthk · 3h ago
Lazarus it's cross platform; it might even run under Windows XP and 2000, if not NT too...
mattl · 1d ago
There's an amazing era in the mid 90s where Steve Jobs is promoting NeXT stuff that interacts with Visual Basic.
D'OLE, etc.
bitwize · 23h ago
D'OLE sounds like something Homer Simpson would say in frustration, and the implementation was probably a cause for such frustration in actual use, cool demos notwithstanding.
mattl · 23h ago
> D'OLE
> D'OLE makes it possible for Windows developers to build robust, scalable, distributed applications today
> Building on NeXT's leadership in object-oriented software development, D'OLE brings the OPENSTEP object model(PDO) from UNIX to the Windows platform and integrates it with Microsoft's Object Linking and Embedding(OLE) object model. Through this integration with OLE, it is now possible to use popular Windows development tools, such as Visual Basic and PowerBuilder(which are currently limited to small workgroup deployments) in conjunction with OPENSTEP objects. This allows application developers to create distributed client/server applications that are scalable to the enterprise. Developers can use their tool of choice to create custom applications that employ a multi-tier distributed object architecture.
> D'OLE also makes it possible, using only OLE objects, to create a truly distributed computing environment on the Windows platform. For instance, you can modify an Excel spreadsheet running on one Windows NT client machine from a Visual Basic application running on another Windows NT client machine.
> Interoperability with OLE is accomplished via support for OLE Automation, which provides transparent integration between OPENSTEP and OLE objects. OLE objects simply connect to, and message, OPENSTEP objects just as if they were OLE objects, and vica versa. With this integration, popular Windows GUI design tools can take advantage of NeXT's advanced object technology without modification.
> D'OLE also supports the Enterprise Objects Framework. The Enterprise Objects Framework supplies data access services that allow objects to persist in industry-standard relational databases. These persistent objects provide database independence and can be reused by multiple OLE and OPENSTEP applications. The pairing of the Enterprise Objects Framework with D'OLE also enables a distributed computing environment that provides an infinitely flexible choice of application deployment strategies.
pkoird · 23h ago
Growing up in a third world country with no formal CS classes, I will never forget the wonder and awe I felt when I coded a simple calculator after self-teaching myself VB6 from a book I stumbled upon. The simplicity of drag and drop and the fluidity with which it simply worked has remained unmatched. I tried going back into App development time and again but these new container based paradigm just never clicked for me.
90s_dev · 1d ago
> Cooper decided to promptly throw away the 25,000 lines of messy prototype C code that comprised Tripod and start over from scratch, feeling like it was so irredeemably full of time-pressured hacks, it'd simply be easier to rewrite it with a cleaner design.
Usually this is either a sign of a terrible programmer or a very competent and experienced one, and it's hard to know which without seeing their other work. But I've done this before, and to good effect. Writing code is not hard. Figuring things out is hard. But once the things are figured out and well understood, rewriting them in a cleaner design is especially easy. Granted, it still takes time, that sometimes that time can be on a scale of months. But the more experienced you are, the more you can estimate that time more accurately.
0xbadcafebee · 22h ago
It's always a bad idea. Eight decades of software has shown it to be true, multiple books written on it. The inherent problem with it is the idea that writing a replacement is somehow going to be easy or fast. But if it were easy or fast, somebody would have done it already! Then come the additional problems of a rewrite like second system effect, inherent complexity, human error. It's impossible to predict how long it could take to finish making it, so fast-or-easy goes out the window.
Even though it's a bad idea, in very rare cases it can be the least-bad idea. But like you said, that takes an expert to figure out, and there's not a lot of experts floating around.
90s_dev · 21h ago
Several times in the past few months, while working on my project, I spent a week writing something exploratory within it, and after all the lessons were fully learned and absorbed, erased that whole part and rewrote it in just a day. I could have kept the week long buggy and badly designed version of it and saved a day of work, but it would have drastically slowed down both development and maintenance of the overall project.
0xbadcafebee · 8h ago
That is very different from having an existing complex system and attempting a complete rewrite from scratch.
If you have a car, and you disassemble the car and reassemble the car 10 times in a row, each time trying it out, then when you finally disassemble-and-reassemble an 11th time, without the defects you've seen the last 10 times, that will be pretty easy and fast.
If you disassemble and reassemble a car 10 times, but only once a month, it's not going to be as easy.
If you disassemble and reassemble it only once a year, it'll be even harder.
If you have never disassembled and reassembled it, and you want to not only disassemble it, but redesign all its parts, and then reassemble it, in one go, that will be incredibly time-consuming and error-prone.
That is the prototypical "entire software rewrite" which is just a bad idea, full-stop. It's not that it's impossible to work; you can eventually get the car to work again. It's just way more expensive, time-consuming, and error-prone, than people realize when they start it. The whole argument for it is that it'll somehow be quicker and cheaper, and that has never been the case. It is attractive because it feels less complex than a process of incremental improvement of an existing legacy system. But the reality is that it's often more complex, due to all the problems involved in a first-time tear-down, re-design, and re-build.
It depends on the size of the (sub)system, the inherent complexity of any version vs incidental complexity of the initial version, and the time given for a rewrite.
jimnotgym · 18h ago
Isn't that one of the tenets of Extreme Programming, write a sketch, throw it away, write it properly?
90s_dev · 11h ago
I don't know, I'm not a real programmer, I still don't understand what SOLID is. I just write code and try to fix it when it doesn't work.
manicminer · 18h ago
The Mikado Method
mpweiher · 15h ago
> It's always a bad idea.
A significant chunk of my software career has been complete rewrites of existing systems. Every one was a huge success.
You should always beware of claims of universality ;-)
Bjartr · 3h ago
What would you say is most important for a rewrite to be successful?
FlingPoo · 22h ago
I wrote a Missile Command game in VB3, that was a very long time ago. I think I sold just over 400 copies, mostly from Compuserve.
Honestly, while growing up.. There's something really amazing about the intuitiveness of tools like Macromedia Flash, Visual Basic, Audacity/even FL Studio that we've had so many people being able to pick up these tools without having to resort to so much documentation/tutorials.
I don't think I could've done that with any of the HTML5 / Web tools that were touted as an alternative at that time... Or probably even today. I mean sure there's MIT scratch that does half as many things as visual basic. But i feel like we need a little more "mature" tools that fill these gaps. I could be wrong and there's much better replacements these days..
WillAdams · 23h ago
For me it was HyperCard/Runtime Revolution/Livecode.
Unfortunately, that latter, after stumping for funds to go opensource has gone closed source and is now charging enough that I can't justify it for hobbyist use, and the openxtalk folks don't seem to have an easy Windows download yet (I'd love to be wrong).
I'd really like for there to be an opensource successor to VisualBasic which was cross-platform and worked well enough to be popular enough to achieve a critical mass of usage/support.
That seems to be the consensus --- hopefully it will become more popular, and I'll give it a try, and hopefully will add to that.
int_19h · 3h ago
Check out https://avaloniaui.net as well. It's basically a cross-platform reimplementation of WPF. It's not quite as simple as C#+WinForms or Lazarus+LCL because you don't get drag-and-drop UI designer, and you need to write markup by hand (albeit with live preview). But unlike HTML, it's actually designed for desktop UI apps from the get go, so it's much easier to write for anything non-trivial. And you can still write "quick and dirty" GUI code by directly connecting event handlers to buttons and updating values etc in it, ignoring data bindings and other more advanced facilities.
I bought VB 1.0 from an 800 number in Dvorak’s back page PC Week article. I still have the floppies and manuals.
I made a lot of consulting cash being an expert in VB 6.
When .NET came out, I switched to C# and learned object-oriented programming. (Ironically by reading Bruce Eckel’s “Thinking in Java”).
0xbadcafebee · 22h ago
I personally consider the abandonment (and lack of replacement) of Visual Basic to be an indictment of the entire tech industry. The industry does not want people to be able to write software easily, because it would put software companies out of a job. I'm glad that AI has finally arrived so it can kill programming. Once the programmers figure this out they may prevent it from being too easy to use AI to create software. If they're not really careful, it might even make web browsers obsolete.
mft_ · 19h ago
I hear you, but I don’t think “the industry” is anything like as rational or strategic or organised as your theory suggests.
What I see as a much more powerful prevailing undercurrent, in everything from Linux not making it on the desktop (next year!) to dependency management in Python to awful documentation in so many projects, is that smart programmers cater to themselves, and there are too few incentives to cater for the proles who aren’t quite as capable or deeply embedded in computer science.
In short, it’s Hanlon’s razor: you’re seeing conspiracy while I just see incompetence.
anthk · 3h ago
No, is not incompetence. Contrary to MS, FLOSS Unixen were designed as a client/server role, and with these Unixen with easy licenses, you can decouple your core and your UI and manage your software anywhere, be it from terminal, a TUI client, HTML, a QT client, TCL/TK, your smartphone... Try that with MS Windows Server licenses.
Simply, the network won. And, for the 'integrated' guys...
MSOffice and VBA are silos were the data often got mangled, losing billions in bioinformatics, for instanced.
Having the markup, the data, the input, output and reports in the same file, that's the recipe for a disaster. And it did happen. As I stated, Unix established a clear pipeline, transforming data sequentially and having each step of the process either recordable or trivially decoupleable.
Smart people would just begin with plain text files and format them once they are finished. Ditto with spreadsheets. CVS/TSV first, data transforms and function should come later, ideally separating the input file from the output.
Reading to print/end user documents should always be under a PDF/DJVU format, never to be edited, but universally viewed in the same way no matter the OS. Period.
PDF's/DJVU's should be the target format, either from Excel, or Word or even PPT's. Oh, these format don't support inline videos nor macros or whatever potentially risky function to crap out your, you know, valuable outputed data? That's even better. Data should have been precalculated and presented long ago.
pfraze · 20h ago
I’ve just started playing with retool to act as a data visualization frontend to big query. If you’re nostalgic for VB, it’s worth giving them a shot. I’m only a couple days in but I’m finding it very promising
WA · 18h ago
VB got me into programming as a teen in the 90s. I even managed to create several small games without having much of a clue. Good times.
EGreg · 10h ago
Both VB and Hypercard were amazing, for Windows and Mac, respectively
Anyone thinking of doing it on the Web?
anthk · 8h ago
Ob VB, performance wise, giving how 'fast' some C64 written in VB ran, I think it was on par of TCL/Tk, if not worse for some cases and better in a few obvious cases (Direct Draw/Direct X), but Unix people wrote the core in C and they put a Tk UI on top giving great speeds.
And, on people praising VBA integration under MS Office, that gave us security disasters with macros and millions of dollars lost because of Excel parsing genomics as dates.
It's better to decouple data and algorythms as separate files. Keep your raw data in a file, transform it and set the output in a separate process and file. You know, a proper pipeline. Something the Unix folks understood since the very beginning 50 years ago.
But "performance" fanboys don't care, until the shit hits the fan as it happened in Science with bioinformatics. Tons of studies, papers and research were just void because of shitty software.
Meanwhile, some Unix users with Slackware with discrete tools for every process (and not just a self-updating XLS file for everything) did it fine as they followed a basic reproducible chain.
It is nice to see this article again.
Perhaps my favorite part is this true story that I shared with Ryan at Retool.
If you ever wonder why we "fire" an event, this is why:
# # #
I was looking for a name for one gizmo sending a message to another. I knew that SQL had "triggers," and Windows had SendMessage, but I didn't like those names.
I got frustrated one night and started firing rubber bands at my screen to help me think. It was a habit I had back then to shake up my thinking. Probably more practical on a tough glass CRT than on a modern flat screen! After firing a few rubber bands, I was still stuck. So I fired up a doobie to see if that would help. As I flicked my lighter and looked at the fire, it all came together. Fire a rubber band. Fire up a doobie. Fire an event!
# # #
My other claim to fame may have been the VBX. It was likely one of the worst APIs in history, but also one of the most successful.
Go figure.
As they say, AMA!
And as it happens, I am looking for work. If anyone doesn't mind working with an older programmer who is still enthusiastic and productive and creative, you know where to find me.
I often harp on how much I wish someone would build a simple GUI for the modern desktop or web environment, instead of spending ages fighting css and javascript for even the most basic layouts. Visual Basic just removed all of the complexity, nothing filled that gap before VB or after VB. Sadly, even VB these days is a mess ever since winforms stopped being the primary target interface.
Thank you for what you built, I've been writing code for 26 years now as a direct result of it.
I should mention that wasn't just me. Alan Cooper came up with the initial idea and a prototype called Tripod and showed it to Bill Gates. After Microsoft funded the project, Alan hired me, and Gary Kratkin, Frank Raab, and Mark Merker to build out the actual Ruby product. And then a team at Microsoft melded it with Basic to become Visual Basic.
I am really grateful that you and so many people put our work to good use!
I learned programming via QBasic (in 21 days!), then VB3, then VB6. My father still writes toy programs in VB6. Things like binding Access DBs to controls was magical to me.
What would it take to have a VB today? I feel like the web, APIs, auth, screen sizes, they’ve all become so complicated. And while Retool aims to make it as easy to develop, it’s just not the same.
What would it look like to really feel “the same” as the good old days?
I don't think you can do anything nowadays that replicates the VB style of interface design. That was completely tied to a fixed layout and only a few desktop screen sizes, but everything these days needs screen size responsiveness from mobile to 4k. And you also need cross platform, accessibility to screen readers, language localization, dark mode, and so on. A flowable and styleable layout just works better for everything, and runs in the HTML/HTTP client that every device already has. Sadly the VB style of design was a temporary waystop and not an enduring norm. I guess the closest you could do would be a big HTML table and just let the small screens scroll biaxially painfully.
As to what it would take to have a VB today, VB.NET still exists:
https://en.wikipedia.org/wiki/Visual_Basic_(.NET)
Maybe that would do the trick?
Of course at that point you could also use C# instead of the VB.NET syntax (which is rather different from "classic" VB).
There are a few old HN comments that I wrote and you can find here:
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
You will have to scroll past a lot of comments about the Ruby programming language.
But that was really kind of a placeholder.
We didn't hardwire the language into the Ruby code, we made an API to allow other languages to be plugged in. And that's how it was easy for Microsoft to plug Basic in.
In fact, I completely forgot the original purpose of Ruby. It wasn't intended as a complete programming environment, it was going to be a new "shell" (desktop) for Windows 3.0. Windows users would create their own custom desktops using Ruby and our primitive batch language.
Somewhat related, there used to be stories about how Visual Basic was originally not going to allow third parties to create custom "controls" (or "gizmos" as we originally called them). But Bill Gates insisted on making it extensible.
That may be true in a narrow sense, but it misses the bigger picture.
Of course we had to create a gizmo API from the very beginning, for the original set of gizmos we had in Ruby. Buttons, lists, text boxes, and so on.
My understanding is that the Visual Basic team didn't want to publish this API in the original VB release, perhaps to get the release out sooner. But Bill insisted that it be included.
For those, like me, that are not native speakers of english and not familiar with the slang: a "doobie" here is a joint. Basically weed (marijuana).
@Stratoscope correct me if i'm wrong
And no, I didn't set one of the Doobie Brothers on fire!
For rapidly prototyping an idea, I have yet to find anything that was as good as VB6. Drag a button, write code. Want to change things about the button? Use properties, that live update the GUI without recompiling. It was so simple that a reasonably intelligent person could grasp it in an afternoon, but in the hands of a capable developer could do some very impressive things.
It was also a fun game to hunt for VBX/OCX controls that you could use in things that were downloaded or came on random disks or CDs.
I really feel like VB6 was the peak of that development model and we've been moving away from it since. And I get some of the reasons why (just look at the mess that comes from trying to do anything with Xcode storyboards and version control.) But for just rapidly trying out an idea, I have yet to find anything anywhere that was as good as VB6 was.
[0] https://en.wikipedia.org/wiki/LibreOffice_Base
[1] https://dbeaver.io/
Microsoft wouldn't be Microsoft without having confusing naming for its APIs, so the one before ADO was called DAO (Data Access Objects).
There was also some very confusing layering in play. ADO didn't work with the database directly - it was a layer on top of either ODBC or OLE DB, depending on the database.
[0] https://learn.microsoft.com/en-us/lifecycle/products/microso...
It wasn't perfect, but it seems that we threw out $100 of capability to "fix" 10 cents worth of flaws.
Instead of fixing the flaws.
https://www.diyaudio.com/community/threads/murphy-law-applie...
https://documentation.xojo.com/getting_started/tutorials/des...
I also made a simple two button menu app for use on repurposed 386's that we were using as thin client pc's. Years later I went back to see they had been replaced with tiny HP thin client devices but my menu was still being used!
Also, TCL/Tk with Tcllib and TkLib plus maybe Tkimage and SQLite3, which was born from TCL code. With that you can create a fast RAD tool in hours.
I have never, for the life of me, found a quicker way to go from zero to GUI than Tcl/Tk. Even VB requires a lot of rat wrestling to set up a UI. Some people think that's how it should be done, but compared to just telling the machine what you want and letting it take care of layout, to me it's still cumbersome. Plus, Tk has had hierarchical, relative positioning and sizing, no need for doing layout in terms of absolute pixels or "dialog units", from the jump.
[0] https://forum.lazarus.freepascal.org/index.php [1] https://wiki.freepascal.org/lazarus_pas2js_integration
I really wish the VBA IDE got some love, but I guess that will never happen.
Why? If it works...
Lots of people are continually building sophisticated tools in MS Office even though it's not helpful for the resume because it's the path of least resistance for solving problems for the sorts of people who just learned VLOOKUP in 2021 and don't want to learn about XLOOKUP now.
Security, maintenance, interop, documentation... There are arguments to be made. It's not cut and dry that VBA is the worst option for any of those. The patterns for handling them are different than a web app repo or something, but it's not like they don't get thought of and handled on a daily basis.
Recently persuaded said client looking for a new solution to support a new line of business to go with the .NET, actively developed system over the ‘free’ VB6 desktop application that a charity developed a billion years ago and wanders around the industry inflicting pain.
Outside of that context, ActiveX is simply a well-defined object-oriented API and ABI for cross-language use.
Up to the point tons of people chose to revert W98's shell to the Win95 one, having a good speed boost on some PI-PII machnes.
VB6 was a good idea as a RAD tool; but, as TCL 7.x (and the older 8.x releases), the performance wasn't fast enough until some Pentium 3/Pentium 4 for 'big' software. Not an issue for a boring company program or the 234000000nth shareware crossword puzzle software for PC magazines or sites as Softonic. Or some whatever catalog hooking up some Excel/Access libraries, or nice in-sormware forms borrowed from IE DLL to create zillions of similar shovelware. That kind of niche software was everywhere.
Ditto with some simple games written in VB; but the native ones outperformed VB ones with ease. And, yes, you could call native DDL's, but most amateur programmers didn't do that.
Are we sure we should be thankful?
Looking back on VB6, now that i'm in my mid-30ies, i think it had some great points. Basically, a simple app was fast and easy to build and did not require to ship (!) and run (!!!) an entire google chrome instance to render a few buttons, some textboxes and a bit of logic.
BTW, the VB6 experience is still somewhat attainable with .NET WinForms (can even use VB.NET if you so desire). Showed my kids how to build simple apps a couple years back and the overall process of dropping controls on a canvas and wiring up events was pretty much the same.
:O
It’s funny how lousy VB (and PHP a few years later) were as programming languages, even for the time. But they got stuff done, which is a good lesson.
I do think the WinForms editor in Visual Studio C# was a pretty decent spiritual successor that came close to capturing the magic of a drag-and-drop GUI builder. Aesthetically lacking but highly functional.
It required the .Net Framework to be installed, which in the early 2000s (with far lower internet penetration and speeds) was a big enough problem. It wasn't particularly great either - Microsoft's attempts to port their own desktop products to .Net mostly failed. It was basically Java for the Windows Desktop, and never quite took off in the way VB apps did.
You'd be surprised but .NET and Java strings have a lot of differences. In Java, String is a class which wraps byte[], in .NET - string is a "FieldSeq" object with characters stored inline. One indirection less but with no special fields and cached state like in Java.
Arrays have significant differences too, where Java arrays do not implement any actual collection interfaces - they are just contiguous chunks of elements with an indexer and length field and need to be asList'ed, so it's common to consider in Java to rely on arrays an anti-pattern, which is the opposite to C# arrays, which implement the full set of System.Collections.Generic interfaces.
No surprise that the first GUI programs I wrote were in LabVIEW and Hypercard, followed soon thereafter by VB.
While I'm not a commercial developer, I still avoid any "stack" where the tutorial for "Hello World" doesn't fit comfortably in one page.
https://learn.microsoft.com/en-us/windows/win32/learnwin32/y...
And here's Xlib:
https://github.com/smysloff/xlib-examples/blob/master/src/ev...
OOP was bolted on later to make this all more manageable. Indeed, VB itself, which is object-oriented (even if it lacks some common features such as inheritance) is a prime example of that.
I no longer blame people for punting to Electron. As bad as HTML is, it's still only 100 MB to save yourself from the worst parts of GUIs.
It only becomes a headache if you need cross-platform support. Although even there options like Avalonia are far superior to Electron.
D'OLE, etc.
> D'OLE makes it possible for Windows developers to build robust, scalable, distributed applications today
> Building on NeXT's leadership in object-oriented software development, D'OLE brings the OPENSTEP object model(PDO) from UNIX to the Windows platform and integrates it with Microsoft's Object Linking and Embedding(OLE) object model. Through this integration with OLE, it is now possible to use popular Windows development tools, such as Visual Basic and PowerBuilder(which are currently limited to small workgroup deployments) in conjunction with OPENSTEP objects. This allows application developers to create distributed client/server applications that are scalable to the enterprise. Developers can use their tool of choice to create custom applications that employ a multi-tier distributed object architecture.
> D'OLE also makes it possible, using only OLE objects, to create a truly distributed computing environment on the Windows platform. For instance, you can modify an Excel spreadsheet running on one Windows NT client machine from a Visual Basic application running on another Windows NT client machine.
> Interoperability with OLE is accomplished via support for OLE Automation, which provides transparent integration between OPENSTEP and OLE objects. OLE objects simply connect to, and message, OPENSTEP objects just as if they were OLE objects, and vica versa. With this integration, popular Windows GUI design tools can take advantage of NeXT's advanced object technology without modification.
> D'OLE also supports the Enterprise Objects Framework. The Enterprise Objects Framework supplies data access services that allow objects to persist in industry-standard relational databases. These persistent objects provide database independence and can be reused by multiple OLE and OPENSTEP applications. The pairing of the Enterprise Objects Framework with D'OLE also enables a distributed computing environment that provides an infinitely flexible choice of application deployment strategies.
Usually this is either a sign of a terrible programmer or a very competent and experienced one, and it's hard to know which without seeing their other work. But I've done this before, and to good effect. Writing code is not hard. Figuring things out is hard. But once the things are figured out and well understood, rewriting them in a cleaner design is especially easy. Granted, it still takes time, that sometimes that time can be on a scale of months. But the more experienced you are, the more you can estimate that time more accurately.
Even though it's a bad idea, in very rare cases it can be the least-bad idea. But like you said, that takes an expert to figure out, and there's not a lot of experts floating around.
If you have a car, and you disassemble the car and reassemble the car 10 times in a row, each time trying it out, then when you finally disassemble-and-reassemble an 11th time, without the defects you've seen the last 10 times, that will be pretty easy and fast.
If you disassemble and reassemble a car 10 times, but only once a month, it's not going to be as easy.
If you disassemble and reassemble it only once a year, it'll be even harder.
If you have never disassembled and reassembled it, and you want to not only disassemble it, but redesign all its parts, and then reassemble it, in one go, that will be incredibly time-consuming and error-prone.
That is the prototypical "entire software rewrite" which is just a bad idea, full-stop. It's not that it's impossible to work; you can eventually get the car to work again. It's just way more expensive, time-consuming, and error-prone, than people realize when they start it. The whole argument for it is that it'll somehow be quicker and cheaper, and that has never been the case. It is attractive because it feels less complex than a process of incremental improvement of an existing legacy system. But the reality is that it's often more complex, due to all the problems involved in a first-time tear-down, re-design, and re-build.
I am not the only person who has noticed this...
A significant chunk of my software career has been complete rewrites of existing systems. Every one was a huge success.
You should always beware of claims of universality ;-)
Link: (the web emulator is very slow)
https://classicreload.com/play/nisus-missile-master.html
I don't think I could've done that with any of the HTML5 / Web tools that were touted as an alternative at that time... Or probably even today. I mean sure there's MIT scratch that does half as many things as visual basic. But i feel like we need a little more "mature" tools that fill these gaps. I could be wrong and there's much better replacements these days..
Unfortunately, that latter, after stumping for funds to go opensource has gone closed source and is now charging enough that I can't justify it for hobbyist use, and the openxtalk folks don't seem to have an easy Windows download yet (I'd love to be wrong).
I'd really like for there to be an opensource successor to VisualBasic which was cross-platform and worked well enough to be popular enough to achieve a critical mass of usage/support.
That seems to be the consensus --- hopefully it will become more popular, and I'll give it a try, and hopefully will add to that.
I made a lot of consulting cash being an expert in VB 6.
When .NET came out, I switched to C# and learned object-oriented programming. (Ironically by reading Bruce Eckel’s “Thinking in Java”).
What I see as a much more powerful prevailing undercurrent, in everything from Linux not making it on the desktop (next year!) to dependency management in Python to awful documentation in so many projects, is that smart programmers cater to themselves, and there are too few incentives to cater for the proles who aren’t quite as capable or deeply embedded in computer science.
In short, it’s Hanlon’s razor: you’re seeing conspiracy while I just see incompetence.
Simply, the network won. And, for the 'integrated' guys... MSOffice and VBA are silos were the data often got mangled, losing billions in bioinformatics, for instanced.
Having the markup, the data, the input, output and reports in the same file, that's the recipe for a disaster. And it did happen. As I stated, Unix established a clear pipeline, transforming data sequentially and having each step of the process either recordable or trivially decoupleable.
Smart people would just begin with plain text files and format them once they are finished. Ditto with spreadsheets. CVS/TSV first, data transforms and function should come later, ideally separating the input file from the output.
Reading to print/end user documents should always be under a PDF/DJVU format, never to be edited, but universally viewed in the same way no matter the OS. Period.
PDF's/DJVU's should be the target format, either from Excel, or Word or even PPT's. Oh, these format don't support inline videos nor macros or whatever potentially risky function to crap out your, you know, valuable outputed data? That's even better. Data should have been precalculated and presented long ago.
Anyone thinking of doing it on the Web?
And, on people praising VBA integration under MS Office, that gave us security disasters with macros and millions of dollars lost because of Excel parsing genomics as dates.
It's better to decouple data and algorythms as separate files. Keep your raw data in a file, transform it and set the output in a separate process and file. You know, a proper pipeline. Something the Unix folks understood since the very beginning 50 years ago.
But "performance" fanboys don't care, until the shit hits the fan as it happened in Science with bioinformatics. Tons of studies, papers and research were just void because of shitty software.
Meanwhile, some Unix users with Slackware with discrete tools for every process (and not just a self-updating XLS file for everything) did it fine as they followed a basic reproducible chain.
https://slackalaxy.com/2019/03/15/slackware-and-slackbuilds-...
Harder? Yes, OFC. But, can you bet that your initial data will be the same on every process? For sure.