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.
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.
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 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.
I read comments like this nearly every day, and they make me so excited to announce my project soon! But I don't want to botch the release, so I'm trying to finish it properly and not rush or announce it too soon.
Oh yes, that's me! It's fun to revisit those stories.
Some notes on the first one...
The photo of me with the wild hair is actually from September 1977, when I took my mom and family flying from San Jose in my favorite Cessna, N20100. So just over a year after Steve and I first met.
Don't look up that tail number unless you want to shed a tear over what happened many years later to that airplane and the pilot and instructor flying it. :-(
The health food store in Palo Alto was Country Sun on California Avenue, which is there to this day. Steve and I met at their old location, just down the street from where they are now.
This was also the summer when I adopted my hippie nickname Truetone Stratoscope, after seeing an old radio in a garage sale across the street, with this on the back:
EQUIPPED WITH
TRUETONE STRATOSCOPE
ELIMINATES AERIAL AND GROUND
Diplomat wasn't an email client, but a service to connect different email systems to each other, with a Forth-based scripting language to handle the details of each email system and convert it to another. At that time, every online service had its own unique protocol.
The Los Gatos health food store was Richard's Natural Foods. They went out of business many years ago, and their building is now Summit Bicycles.
Strangely enough, Steve and I ran into each other at the produce aisle there, just as we had at Country Sun.
The restaurant where we met in 2011, the last year of his life, wasn't in Menlo Park. It was La Strada on University Avenue in Palo Alto. The reason I didn't want to interrupt him was that he was having dinner with his daughter.
I do regret that when Steve's daughter left the table for a few minutes (presumably to use the restroom) I didn't take a moment to reconnect. I am sure he would have enjoyed hearing the story about the disassembler.
The second article seems to be behind a paywall, so here is an archive link:
Much more recently, I spent a year and a half at Wing, the Alphabet drone delivery company. A friend associated with the company pinged me for some urgent work on airspace data importers. This was right up my alley!
The cool thing was that would hire me as a "temp", so I wouldn't have to go through any of the usual Google interview process. And then if things worked out, they could convert me to an FTE (full time employee) position.
The "interview" was lunch with the team lead and manager. They knew I could do the job, I knew I could do the job, so we got started right away.
A year later, Google changed the rules. Temps could no longer convert directly to FTE. They would have to go through the standard Google interview process, with one specific requirement: No one on the team you had been working with, who knew your work and your contributions, could be involved.
You would have to interview with a panel of strangers who had never heard of you, who had no idea of the work you were already doing at Google/Alphabet for the team you were working for.
It would be as if you were just some random person off the street who applied for a position at Google/Alphabet.
It would not matter in the slightest that you were already working for a Google/Alphabet team who valued your work and wanted to keep you on the team.
The great irony in the email that announced this change was that interns were eligible to convert directly to FTE. It explained that interns were already Google employees, unlike temps like me.
I try to avoid swearing, but this was the most fucked up HR directive I have ever seen.
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.
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.
I also learned QBasic in 21 days, over 3+ years. It was the only QBasic book available at Waldenbooks. The name Namir Shammas is forever etched in my memory.
Thank you! It means so much to me that you and so many others used what my team built.
In all fairness, others in this thread have noted that the form design process back then was simpler than today. We didn't need to worry about mobile, high DPI vs. low DPI, and trying to get things to fit on any size screen.
I do see some comments from @90s_dev that sound intriguing. If they are able to get that '90s development experience to work on our modern varieties of displays and devices, that could be quite something!
I mean, I've been a professional developer now for more than 20 years, and it started with learning QBasic from a book and then building stuff with Visual Basic. So VB was literally life-changing for me.
I even bought (and still have somewhere!) a book on doing graphics or VFX or something using Visual Basic, though I never really did much with it. I think it was Visual Basic with DirectX or something. Though funny enough I ended up working at Autodesk for a few years on things related to 3d printing and computational geometry, so I eventually did some graphics-related stuff.
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!
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.
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.
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.
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 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]
I haven't really been paying attention to the GUI or dev-tools side of GNUstep, it was just duplicating what I have on macOS and I was more interested in server applications on other platforms.
An obvious mistake, in retrospect.
With Apple destroying both the UI and the development tools, the situation has fundamentally changed and that assessment is no longer valid.
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!
.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...
The RCW/CCW approach is much more low level, to the point there are whole books on how to use COM in .NET, whereas it was just part of how to program in VB (pre-.NET).
It also went through two reboots.
So now you have .NET COM support for .NET Framework, COM/WinRT support for UWP, modern .NET support for COM.
Every variation with its own APIs, only the classical .NET Framework approach has Visual Studio "import COM component" support, and none of them as easy as VB 6 was in the end.
Quite bad as developer experience, given the COM focus since Windows Vista.
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]
Oldschool .NET Framework is a Windows component now, so as far as support goes, it is treated the same as any other OS component - meaning that it's supported for as long as the corresponding OS is.
I suspect that .NET will last just as long given the sheer amount of enterprise software that was written for it - even today there are places that target it in lieu of the new OS-independent .NET versions.
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.
Microsoft has yet to produce a tool that makes as convinient to produce/consume COM libraries.
.NET support has been through a few reboots, and it is much more low level.
For a technology that nowadays runs so deep on Windows APIs, it is really surprising how Windows Development team is not capable to embrace better tooling for COM, only mini-projects that eventually are left abandoned as people move on.
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.
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....
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.
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 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.
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.
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.
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.
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.
"Boring company program" is exactly what VB was made for. People tried to use it for other purposes because when you have a hammer, you make everything look like a nail, but I don't recall any actual prominent software written in VB outside of line-of-business stuff. "Serious business" in that timeframe was done either in Delphi or in C++.
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.
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.
We're talking about the original .NET 1.x here, not the current state of affairs.
In any case, what I'm talking about is not so much implementation details as user-observable semantics. .NET strings are pretty much exactly like Java strings in that regard - it's an immutable reference type that is a sequence of UTF-16 codepoints. In contrast, strings in Delphi are mutable value types (implemented using copy-on-write with refcounting).
Similarly for arrays, while Delphi has Pascal-style fixed-size arrays that are value types, both C# and Java have arrays as a reference type with null as a distinct value from empty array. The other point of similarity is that both C# and Java treat arrays of objects as covariant, even though it's not actually typesafe (and triggers runtime exceptions if you try to put the wrong type into the array).
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):
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.
It's interesting that VB5 and 6 were what I call "object based." You could use pre-defined objects, but didn't have to create them yourself. In fact you needed some special "edition" to create objects, which I never did. But was a great way to ease a beginner into OOP -- by using them before creating them.
Now of course I'm not a beginner -- that can only happen once. And maybe it has gotten easier to learn. I remember the series in Byte Magazine about OOP, and it was just utterly baffling, but now I can't imagine why it seemed hard.
Meanwhile, I stepped off the software development bus, and so I don't care as much about "finished" software. Building crude GUI's in Tkinter is satisfactory for my needs these days.
It sounds like you're describing VB4 and below. In VB5+, the underlying object model was COM, and you absolutely could define and instantiate classes. Many built-in types for common operations also had to be instantiated - e.g. Collection, or anything to do with database access.
etc. Free Pascal also has this, slightly generalized now so you can use strings for IDs.
But FWIW I think most people who were writing those apps back in the day didn't think of it as OOP. It was more like, one day you learned about classes and objects, and then you realized that those things you've been writing were basically about that, but with a lot more manual scaffolding.
I guess another take on this is that OOP just flows naturally from GUI problems. To this day, I still remember my first TUI app, completely handcoded in Turbo BASIC. It had a bespoke event loop, and message dispatch, and widgets; but I didn't know about any of those things at the time - it just developed organically as I went about doing the thing that I wanted to do (in that case, a simple UI for a flat file database of sorts).
I was lucky to have learned multiple approaches to OOP, with TP 5.5 followed by TP 6.0 with Turbo Vision, as entry point into the world.
Eventually I came to grasp the concepts, the ways it was done different across languages, and came to the realisation a very bare bones description would be to say that an object is a module you can assign to variables. Which incidently is what you get in Standard ML with functors, with polymorphism for the dispatch.
Turbo Vision documentation, typing from head not going into bitsavers, actually had to guide people away from that approach you are describing to letting the framework handle those scenarios, even in MS-DOS.
Ah, Turbo BASIC, my first actual BASIC compiler, and entry into being a Borland products consumer.
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.
Very slow release cycle and long lifetimes. Qt moves pretty quick and this causes problems for downstream projects. E.g. KDE had to keep Qt 5 alive for _years_ until KDE 6 was ready. Rochus Keller has a version of Qt 5 as well. Trinity is still maintaining Qt 3.
Extremely wide cross-platform support, e.g. on the BSDs and some other niche OSes. I think there's even a Haiku version.
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 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.
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.
A lot of disagreement apparently but I agree with you. Been doing this a long time and never seen it be a good idea.
I completed one successfully and it paralyzed a team of five for a year. Thankfully it was an internal product being rewritten for sale so the affect on users was minimal, but we also lost a year of potential sales.
Every other attempt I've seen has started with beautiful ideas, rainbows and pots of gold at the end, but went south after the first 20% code written and things got hard.
It's possible to do if you're willing to cripple development efforts or progress for an extended period and understand the result will have it's own issues and a rewrite isn't a silver bullet.
I was a proficient C/C++ programmer for DOS and embedded, but found programming apps for Windows to be very overwhelming and tedious. So for a few years there VB was an excellent way for me to build little Windows tools and apps, until I eventually put in the effort to get good at MFC. I dropped that as soon as C# came out.
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.
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 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.
Honestly, I’m not following the full thread of your argument.
But what I do take, is that you think the UNIX world is just much better organised than the alternative; and anyone who doesn’t understand that and isn’t thriving in that environment… is the problem?
And you don’t see the problem with this line of thinking?
It really was one of the best language and ide environments that was completely pushed aside by security considerations from the much more widely used general purpose internet web browser.
Back in the day, we were building COM components in C++ with the STL. One of the discoveries is you could build out the same COM component in VB and maybe take only a 5% hit to performance. Was one of those 'we are not telling anyone we can do this' moments. Beyond the UI portion, it had some really powerful capabilities.
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
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.
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.
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.
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!
> 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.
I read comments like this nearly every day, and they make me so excited to announce my project soon! But I don't want to botch the release, so I'm trying to finish it properly and not rush or announce it too soon.
> As they say, AMA!
Are you also this Michael Geary?
«Meet the first guy Steve Jobs ever fired at Apple ... and he wasn't even an employee»
https://finance.yahoo.com/news/meet-first-guy-steve-jobs-130...
«Why an Older Google Contract Programmer Left Google»
https://www.businessinsider.com/why-an-older-google-contract...
Oh yes, that's me! It's fun to revisit those stories.
Some notes on the first one...
The photo of me with the wild hair is actually from September 1977, when I took my mom and family flying from San Jose in my favorite Cessna, N20100. So just over a year after Steve and I first met.
Here is the uncropped photo:
https://pbase.com/geary/image/120224799
Don't look up that tail number unless you want to shed a tear over what happened many years later to that airplane and the pilot and instructor flying it. :-(
The health food store in Palo Alto was Country Sun on California Avenue, which is there to this day. Steve and I met at their old location, just down the street from where they are now.
This was also the summer when I adopted my hippie nickname Truetone Stratoscope, after seeing an old radio in a garage sale across the street, with this on the back:
Diplomat wasn't an email client, but a service to connect different email systems to each other, with a Forth-based scripting language to handle the details of each email system and convert it to another. At that time, every online service had its own unique protocol.The Los Gatos health food store was Richard's Natural Foods. They went out of business many years ago, and their building is now Summit Bicycles.
Strangely enough, Steve and I ran into each other at the produce aisle there, just as we had at Country Sun.
The restaurant where we met in 2011, the last year of his life, wasn't in Menlo Park. It was La Strada on University Avenue in Palo Alto. The reason I didn't want to interrupt him was that he was having dinner with his daughter.
I do regret that when Steve's daughter left the table for a few minutes (presumably to use the restroom) I didn't take a moment to reconnect. I am sure he would have enjoyed hearing the story about the disassembler.
The second article seems to be behind a paywall, so here is an archive link:
https://archive.is/hcTNa
An odd coda to that article...
Much more recently, I spent a year and a half at Wing, the Alphabet drone delivery company. A friend associated with the company pinged me for some urgent work on airspace data importers. This was right up my alley!
The cool thing was that would hire me as a "temp", so I wouldn't have to go through any of the usual Google interview process. And then if things worked out, they could convert me to an FTE (full time employee) position.
The "interview" was lunch with the team lead and manager. They knew I could do the job, I knew I could do the job, so we got started right away.
A year later, Google changed the rules. Temps could no longer convert directly to FTE. They would have to go through the standard Google interview process, with one specific requirement: No one on the team you had been working with, who knew your work and your contributions, could be involved.
You would have to interview with a panel of strangers who had never heard of you, who had no idea of the work you were already doing at Google/Alphabet for the team you were working for.
It would be as if you were just some random person off the street who applied for a position at Google/Alphabet.
It would not matter in the slightest that you were already working for a Google/Alphabet team who valued your work and wanted to keep you on the team.
The great irony in the email that announced this change was that interns were eligible to convert directly to FTE. It explained that interns were already Google employees, unlike temps like me.
I try to avoid swearing, but this was the most fucked up HR directive I have ever seen.
Wonderful extra background! Thank you so much!
I am based in Europe and virtually never visit the Americas, but I hope our paths cross in real life some time. :-)
Well thank you Liam! You know, I saw your username but somehow it just didn't register. Pun intended.
I have read so many of your articles! Including the recent one on OSU OSL, which I've used many times, especially when I was doing Drupal work.
Having grown up in Eugene, I have to confess to being more of a U of O guy (Go Ducks!) but Corvallis and OSU are also dear to my heart.
I have been wanting to visit the Isle of Man, in part from being a long time user of Araxis Merge.
Now I have two reasons!
-Mike
:-D
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?
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).
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.
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.
I also learned QBasic in 21 days, over 3+ years. It was the only QBasic book available at Waldenbooks. The name Namir Shammas is forever etched in my memory.
Amazing!
I learned QBasic when I was 12, then moved on to Visual Basic when I was 13. It was such an amazing experience!
I'm one of the many people who still wish we had anything anywhere near as good today in terms of creating GUIs. It was an amazing achievement!
Thank you! It means so much to me that you and so many others used what my team built.
In all fairness, others in this thread have noted that the form design process back then was simpler than today. We didn't need to worry about mobile, high DPI vs. low DPI, and trying to get things to fit on any size screen.
I do see some comments from @90s_dev that sound intriguing. If they are able to get that '90s development experience to work on our modern varieties of displays and devices, that could be quite something!
I mean, I've been a professional developer now for more than 20 years, and it started with learning QBasic from a book and then building stuff with Visual Basic. So VB was literally life-changing for me.
I even bought (and still have somewhere!) a book on doing graphics or VFX or something using Visual Basic, though I never really did much with it. I think it was Visual Basic with DirectX or something. Though funny enough I ended up working at Autodesk for a few years on things related to 3d printing and computational geometry, so I eventually did some graphics-related stuff.
> VB was literally life-changing for me.
Wow. That is something every developer would hope to hear.
Thank you again, my friend.
> 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!
If my upcoming project takes off and makes any money, I would hire you in a heartbeat!
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 would love just a new VB if you have the time….
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.
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.
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 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/
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...
Ever looked at GNUstep's GORM?
https://www.gnustep.org/experience/Gorm.html
I'd be interested in an assessment.
Good point!
I haven't really been paying attention to the GUI or dev-tools side of GNUstep, it was just duplicating what I have on macOS and I was more interested in server applications on other platforms.
An obvious mistake, in retrospect.
With Apple destroying both the UI and the development tools, the situation has fundamentally changed and that assessment is no longer valid.
I need to take a closer look!
I liked Flash for these reasons too, the way Macromedia fused design, animation and programming was amazing.
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!
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 don't know much about Gambas but it seems it is Linux only whereas Xojo is cross platform.
.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...
Except if you need to touch COM.
The RCW/CCW approach is much more low level, to the point there are whole books on how to use COM in .NET, whereas it was just part of how to program in VB (pre-.NET).
It also went through two reboots.
So now you have .NET COM support for .NET Framework, COM/WinRT support for UWP, modern .NET support for COM.
Every variation with its own APIs, only the classical .NET Framework approach has Visual Studio "import COM component" support, and none of them as easy as VB 6 was in the end.
Quite bad as developer experience, given the COM focus since Windows Vista.
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...
Oldschool .NET Framework is a Windows component now, so as far as support goes, it is treated the same as any other OS component - meaning that it's supported for as long as the corresponding OS is.
How long that will be remains to be seen. But Windows still ships the VB6 runtime (MSVBVM60.DLL) in the box today, 27 years since it was first released: https://learn.microsoft.com/en-us/previous-versions/visualst...
I suspect that .NET will last just as long given the sheer amount of enterprise software that was written for it - even today there are places that target it in lieu of the new OS-independent .NET versions.
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.
Microsoft has yet to produce a tool that makes as convinient to produce/consume COM libraries.
.NET support has been through a few reboots, and it is much more low level.
For a technology that nowadays runs so deep on Windows APIs, it is really surprising how Windows Development team is not capable to embrace better tooling for COM, only mini-projects that eventually are left abandoned as people move on.
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.
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....
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.
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 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.
> 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.
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.
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.
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.
"Boring company program" is exactly what VB was made for. People tried to use it for other purposes because when you have a hammer, you make everything look like a nail, but I don't recall any actual prominent software written in VB outside of line-of-business stuff. "Serious business" in that timeframe was done either in Delphi or in C++.
> 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.
We're talking about the original .NET 1.x here, not the current state of affairs.
In any case, what I'm talking about is not so much implementation details as user-observable semantics. .NET strings are pretty much exactly like Java strings in that regard - it's an immutable reference type that is a sequence of UTF-16 codepoints. In contrast, strings in Delphi are mutable value types (implemented using copy-on-write with refcounting).
Similarly for arrays, while Delphi has Pascal-style fixed-size arrays that are value types, both C# and Java have arrays as a reference type with null as a distinct value from empty array. The other point of similarity is that both C# and Java treat arrays of objects as covariant, even though it's not actually typesafe (and triggers runtime exceptions if you try to put the wrong type into the array).
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.
It's interesting that VB5 and 6 were what I call "object based." You could use pre-defined objects, but didn't have to create them yourself. In fact you needed some special "edition" to create objects, which I never did. But was a great way to ease a beginner into OOP -- by using them before creating them.
Now of course I'm not a beginner -- that can only happen once. And maybe it has gotten easier to learn. I remember the series in Byte Magazine about OOP, and it was just utterly baffling, but now I can't imagine why it seemed hard.
Meanwhile, I stepped off the software development bus, and so I don't care as much about "finished" software. Building crude GUI's in Tkinter is satisfactory for my needs these days.
It sounds like you're describing VB4 and below. In VB5+, the underlying object model was COM, and you absolutely could define and instantiate classes. Many built-in types for common operations also had to be instantiated - e.g. Collection, or anything to do with database access.
Windows message dispatches are pretty much OOP, it follows the Smalltalk underlying idea of methods are sending messages.
Anyone that was written Windows custom controls knows how it goes, it isn't much different from OOP in C.
True - and Delphi even had syntactic sugar for it so you could write stuff like:
etc. Free Pascal also has this, slightly generalized now so you can use strings for IDs.But FWIW I think most people who were writing those apps back in the day didn't think of it as OOP. It was more like, one day you learned about classes and objects, and then you realized that those things you've been writing were basically about that, but with a lot more manual scaffolding.
I guess another take on this is that OOP just flows naturally from GUI problems. To this day, I still remember my first TUI app, completely handcoded in Turbo BASIC. It had a bespoke event loop, and message dispatch, and widgets; but I didn't know about any of those things at the time - it just developed organically as I went about doing the thing that I wanted to do (in that case, a simple UI for a flat file database of sorts).
I was lucky to have learned multiple approaches to OOP, with TP 5.5 followed by TP 6.0 with Turbo Vision, as entry point into the world.
Eventually I came to grasp the concepts, the ways it was done different across languages, and came to the realisation a very bare bones description would be to say that an object is a module you can assign to variables. Which incidently is what you get in Standard ML with functors, with polymorphism for the dispatch.
Turbo Vision documentation, typing from head not going into bitsavers, actually had to guide people away from that approach you are describing to letting the framework handle those scenarios, even in MS-DOS.
Ah, Turbo BASIC, my first actual BASIC compiler, and entry into being a Borland products consumer.
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...
I think I saw, mentioned in the system requirements, "Windows 2000 or above" or something like that.
I do wonder how cross-platform your code will be, though. I suppose it depends on whether it talks to Win32, or Gtk2, or Qt4, or Qt 5, or Qt 6... etc.
I wonder if FPC+Lazarus could be wired up to Tk so that there was a portable, cross-platform toolkit as well...?
FPC/Lazarus motto is "write once, compile anywhere", so the idea is that you rebuild as needed for different platforms.
It could certainly be wired up to Tk, but what does Tk offer that Qt already doesn't when it comes to a portable cross-platform toolkit?
> but what does Tk offer that Qt already doesn't
Small (relatively tiny) code size and simplicity.
Very slow release cycle and long lifetimes. Qt moves pretty quick and this causes problems for downstream projects. E.g. KDE had to keep Qt 5 alive for _years_ until KDE 6 was ready. Rochus Keller has a version of Qt 5 as well. Trinity is still maintaining Qt 3.
Extremely wide cross-platform support, e.g. on the BSDs and some other niche OSes. I think there's even a Haiku version.
TCL/Tk works under XP under the IronTCL release. With modern TLS and all (use http://legacyupdate.net for newer certs).
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...
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?
A lot of disagreement apparently but I agree with you. Been doing this a long time and never seen it be a good idea.
I completed one successfully and it paralyzed a team of five for a year. Thankfully it was an internal product being rewritten for sale so the affect on users was minimal, but we also lost a year of potential sales.
Every other attempt I've seen has started with beautiful ideas, rainbows and pots of gold at the end, but went south after the first 20% code written and things got hard.
It's possible to do if you're willing to cripple development efforts or progress for an extended period and understand the result will have it's own issues and a rewrite isn't a silver bullet.
I was a proficient C/C++ programmer for DOS and embedded, but found programming apps for Windows to be very overwhelming and tedious. So for a few years there VB was an excellent way for me to build little Windows tools and apps, until I eventually put in the effort to get good at MFC. I dropped that as soon as C# came out.
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.
https://www.lazarus-ide.org/
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.
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
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.
Honestly, I’m not following the full thread of your argument.
But what I do take, is that you think the UNIX world is just much better organised than the alternative; and anyone who doesn’t understand that and isn’t thriving in that environment… is the problem?
And you don’t see the problem with this line of thinking?
It really was one of the best language and ide environments that was completely pushed aside by security considerations from the much more widely used general purpose internet web browser.
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”).
Back in the day, we were building COM components in C++ with the STL. One of the discoveries is you could build out the same COM component in VB and maybe take only a 5% hit to performance. Was one of those 'we are not telling anyone we can do this' moments. Beyond the UI portion, it had some really powerful capabilities.
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.
Thankfully no one does curl | sh in UNIX....
[dead]