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.

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?

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.

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:

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).

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.

If my upcoming project takes off and makes any money, I would hire you in a heartbeat!

I would love just a new VB if you have the time….

Would love to read more about your Ruby. Have your written about it anywhere? Even old HN comments would be welcome.

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:

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.

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!

I wonder what the programming language was like which you used, before BASIC was put into the product?

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.

> 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

Thank you for the clarification. Yes, you are correct.

And no, I didn't set one of the Doobie Brothers on fire!

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.

.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...

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]

[0] https://learn.microsoft.com/en-us/lifecycle/products/microso...

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.

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]

[0] https://en.wikipedia.org/wiki/LibreOffice_Base

[1] https://dbeaver.io/

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?)

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.

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.

I feel much the same about NeXT's Interface Builder.

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...

I liked Flash for these reasons too, the way Macromedia fused design, animation and programming was amazing.

Have you checked out Xojo? It is a VB6-like language with a similar development UI. There are desktop and web versions.

https://documentation.xojo.com/getting_started/tutorials/des...

How do they compare to Gambas https://gambaswiki.org/website/en/main.html ?

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!

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.

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.

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.

Doesn't Lazarus serve a similar purpose?

It could, if the documentation were usable. 8(

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.

[0] https://forum.lazarus.freepascal.org/index.php [1] https://wiki.freepascal.org/lazarus_pas2js_integration

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.

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.

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....

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.

> Thankfully

Why? If it works...

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.

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.

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.

Active X it's a security disaster.

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.

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.

> 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.

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.

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.

> Excel, press Alt-F11

:O

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.

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.

> 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.

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.

WinForms itself was largely a clone of Delphi. C# through version 2 was essentially Delphi with C syntax.

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.

> 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.

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.

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.

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):

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.

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.

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.

Lazarus it's cross platform; it might even run under Windows XP and 2000, if not NT too...

There's an amazing era in the mid 90s where Steve Jobs is promoting NeXT stuff that interacts with Visual Basic.

D'OLE, etc.

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.

> 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.

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.

> 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.

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.

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.

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.

I am not the only person who has noticed this...

  - https://en.wikipedia.org/wiki/The_Mythical_Man-Month
  - https://www.onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx
  - https://testdouble.com/insights/managing-legacy-code-rewrite-vs-renovate
  - https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
  - https://www.reddit.com/r/ExperiencedDevs/comments/sr8zyf/why_exactly_does_most_software_rewrite_fail/
  - https://daedtech.com/the-myth-of-the-software-rewrite/
  - https://levelup.gitconnected.com/why-rewriting-applications-from-scratch-is-almost-always-a-bad-idea-5402d1715006

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.

Isn't that one of the tenets of Extreme Programming, write a sketch, throw it away, write it properly?

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.

The Mikado Method

> 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 ;-)

What would you say is most important for a rewrite to be successful?

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.

Link: (the web emulator is very slow)

https://classicreload.com/play/nisus-missile-master.html

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..

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.

Thanks!

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.

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.

Before (2023) - https://news.ycombinator.com/item?id=35192913

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”).

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.

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.

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.

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

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.

Both VB and Hypercard were amazing, for Windows and Mac, respectively

Anyone thinking of doing it on the Web?

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.

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.