It’s funny how lousy VB (and PHP a few years later) were as programming languages, even for the time. But they got stuff done, which is a good lesson.
I do think the WinForms editor in Visual Studio C# was a pretty decent spiritual successor that came close to capturing the magic of a drag-and-drop GUI builder. Aesthetically lacking but highly functional.
It required the .Net Framework to be installed, which in the early 2000s (with far lower internet penetration and speeds) was a big enough problem. It wasn't particularly great either - Microsoft's attempts to port their own desktop products to .Net mostly failed. It was basically Java for the Windows Desktop, and never quite took off in the way VB apps did.
You'd be surprised but .NET and Java strings have a lot of differences. In Java, String is a class which wraps byte[], in .NET - string is a "FieldSeq" object with characters stored inline. One indirection less but with no special fields and cached state like in Java.
Arrays have significant differences too, where Java arrays do not implement any actual collection interfaces - they are just contiguous chunks of elements with an indexer and length field and need to be asList'ed, so it's common to consider in Java to rely on arrays an anti-pattern, which is the opposite to C# arrays, which implement the full set of System.Collections.Generic interfaces.
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).
D'OLE, etc.
> D'OLE makes it possible for Windows developers to build robust, scalable, distributed applications today
> Building on NeXT's leadership in object-oriented software development, D'OLE brings the OPENSTEP object model(PDO) from UNIX to the Windows platform and integrates it with Microsoft's Object Linking and Embedding(OLE) object model. Through this integration with OLE, it is now possible to use popular Windows development tools, such as Visual Basic and PowerBuilder(which are currently limited to small workgroup deployments) in conjunction with OPENSTEP objects. This allows application developers to create distributed client/server applications that are scalable to the enterprise. Developers can use their tool of choice to create custom applications that employ a multi-tier distributed object architecture.
> D'OLE also makes it possible, using only OLE objects, to create a truly distributed computing environment on the Windows platform. For instance, you can modify an Excel spreadsheet running on one Windows NT client machine from a Visual Basic application running on another Windows NT client machine.
> Interoperability with OLE is accomplished via support for OLE Automation, which provides transparent integration between OPENSTEP and OLE objects. OLE objects simply connect to, and message, OPENSTEP objects just as if they were OLE objects, and vica versa. With this integration, popular Windows GUI design tools can take advantage of NeXT's advanced object technology without modification.
> D'OLE also supports the Enterprise Objects Framework. The Enterprise Objects Framework supplies data access services that allow objects to persist in industry-standard relational databases. These persistent objects provide database independence and can be reused by multiple OLE and OPENSTEP applications. The pairing of the Enterprise Objects Framework with D'OLE also enables a distributed computing environment that provides an infinitely flexible choice of application deployment strategies.
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.
I no longer blame people for punting to Electron. As bad as HTML is, it's still only 100 MB to save yourself from the worst parts of GUIs.
It only becomes a headache if you need cross-platform support. Although even there options like Avalonia are far superior to Electron.
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...?
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?
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.
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.
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.
Anyone that was written Windows custom controls knows how it goes, it isn't much different from OOP in C.
procedure WMPaint(var Msg: TWMPaint); message WM_PAINT;
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).
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.
Usually this is either a sign of a terrible programmer or a very competent and experienced one, and it's hard to know which without seeing their other work. But I've done this before, and to good effect. Writing code is not hard. Figuring things out is hard. But once the things are figured out and well understood, rewriting them in a cleaner design is especially easy. Granted, it still takes time, that sometimes that time can be on a scale of months. But the more experienced you are, the more you can estimate that time more accurately.
Even though it's a bad idea, in very rare cases it can be the least-bad idea. But like you said, that takes an expert to figure out, and there's not a lot of experts floating around.
If you have a car, and you disassemble the car and reassemble the car 10 times in a row, each time trying it out, then when you finally disassemble-and-reassemble an 11th time, without the defects you've seen the last 10 times, that will be pretty easy and fast.
If you disassemble and reassemble a car 10 times, but only once a month, it's not going to be as easy.
If you disassemble and reassemble it only once a year, it'll be even harder.
If you have never disassembled and reassembled it, and you want to not only disassemble it, but redesign all its parts, and then reassemble it, in one go, that will be incredibly time-consuming and error-prone.
That is the prototypical "entire software rewrite" which is just a bad idea, full-stop. It's not that it's impossible to work; you can eventually get the car to work again. It's just way more expensive, time-consuming, and error-prone, than people realize when they start it. The whole argument for it is that it'll somehow be quicker and cheaper, and that has never been the case. It is attractive because it feels less complex than a process of incremental improvement of an existing legacy system. But the reality is that it's often more complex, due to all the problems involved in a first-time tear-down, re-design, and re-build.
I am not the only person who has noticed this...
- https://en.wikipedia.org/wiki/The_Mythical_Man-Month
- https://www.onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx
- https://testdouble.com/insights/managing-legacy-code-rewrite-vs-renovate
- https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
- https://www.reddit.com/r/ExperiencedDevs/comments/sr8zyf/why_exactly_does_most_software_rewrite_fail/
- https://daedtech.com/the-myth-of-the-software-rewrite/
- https://levelup.gitconnected.com/why-rewriting-applications-from-scratch-is-almost-always-a-bad-idea-5402d1715006A 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 ;-)
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.
Why? If it works...
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.
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.
Outside of that context, ActiveX is simply a well-defined object-oriented API and ABI for cross-language use.
Up to the point tons of people chose to revert W98's shell to the Win95 one, having a good speed boost on some PI-PII machnes.
VB6 was a good idea as a RAD tool; but, as TCL 7.x (and the older 8.x releases), the performance wasn't fast enough until some Pentium 3/Pentium 4 for 'big' software. Not an issue for a boring company program or the 234000000nth shareware crossword puzzle software for PC magazines or sites as Softonic. Or some whatever catalog hooking up some Excel/Access libraries, or nice in-sormware forms borrowed from IE DLL to create zillions of similar shovelware. That kind of niche software was everywhere.
Ditto with some simple games written in VB; but the native ones outperformed VB ones with ease. And, yes, you could call native DDL's, but most amateur programmers didn't do that.
Are we sure we should be thankful?
Looking back on VB6, now that i'm in my mid-30ies, i think it had some great points. Basically, a simple app was fast and easy to build and did not require to ship (!) and run (!!!) an entire google chrome instance to render a few buttons, some textboxes and a bit of logic.
BTW, the VB6 experience is still somewhat attainable with .NET WinForms (can even use VB.NET if you so desire). Showed my kids how to build simple apps a couple years back and the overall process of dropping controls on a canvas and wiring up events was pretty much the same.
:O
I really wish the VBA IDE got some love, but I guess that will never happen.
Link: (the web emulator is very slow)
What I see as a much more powerful prevailing undercurrent, in everything from Linux not making it on the desktop (next year!) to dependency management in Python to awful documentation in so many projects, is that smart programmers cater to themselves, and there are too few incentives to cater for the proles who aren’t quite as capable or deeply embedded in computer science.
In short, it’s Hanlon’s razor: you’re seeing conspiracy while I just see incompetence.
Simply, the network won. And, for the 'integrated' guys... MSOffice and VBA are silos were the data often got mangled, losing billions in bioinformatics, for instanced.
Having the markup, the data, the input, output and reports in the same file, that's the recipe for a disaster. And it did happen. As I stated, Unix established a clear pipeline, transforming data sequentially and having each step of the process either recordable or trivially decoupleable.
Smart people would just begin with plain text files and format them once they are finished. Ditto with spreadsheets. CVS/TSV first, data transforms and function should come later, ideally separating the input file from the output.
Reading to print/end user documents should always be under a PDF/DJVU format, never to be edited, but universally viewed in the same way no matter the OS. Period.
PDF's/DJVU's should be the target format, either from Excel, or Word or even PPT's. Oh, these format don't support inline videos nor macros or whatever potentially risky function to crap out your, you know, valuable outputed data? That's even better. Data should have been precalculated and presented long ago.
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?
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.
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.
https://documentation.xojo.com/getting_started/tutorials/des...
I also made a simple two button menu app for use on repurposed 386's that we were using as thin client pc's. Years later I went back to see they had been replaced with tiny HP thin client devices but my menu was still being used!
It wasn't perfect, but it seems that we threw out $100 of capability to "fix" 10 cents worth of flaws.
Instead of fixing the flaws.
https://www.diyaudio.com/community/threads/murphy-law-applie...
https://www.gnustep.org/experience/Gorm.html
I'd be interested in an assessment.
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!
[0] https://forum.lazarus.freepascal.org/index.php [1] https://wiki.freepascal.org/lazarus_pas2js_integration
Also, TCL/Tk with Tcllib and TkLib plus maybe Tkimage and SQLite3, which was born from TCL code. With that you can create a fast RAD tool in hours.
I have never, for the life of me, found a quicker way to go from zero to GUI than Tcl/Tk. Even VB requires a lot of rat wrestling to set up a UI. Some people think that's how it should be done, but compared to just telling the machine what you want and letting it take care of layout, to me it's still cumbersome. Plus, Tk has had hierarchical, relative positioning and sizing, no need for doing layout in terms of absolute pixels or "dialog units", from the jump.
[0] https://learn.microsoft.com/en-us/lifecycle/products/microso...
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.
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.
.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.
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.
For those, like me, that are not native speakers of english and not familiar with the slang: a "doobie" here is a joint. Basically weed (marijuana).
@Stratoscope correct me if i'm wrong
And no, I didn't set one of the Doobie Brothers on fire!
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.
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.
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?
As to what it would take to have a VB today, VB.NET still exists:
https://en.wikipedia.org/wiki/Visual_Basic_(.NET)
Maybe that would do the trick?
Of course at that point you could also use C# instead of the VB.NET syntax (which is rather different from "classic" VB).
I 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 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 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.
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!
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 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.
Wow. That is something every developer would hope to hear.
Thank you again, my friend.
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...
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:
EQUIPPED WITH
TRUETONE STRATOSCOPE
ELIMINATES AERIAL AND GROUND
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:
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.
I am based in Europe and virtually never visit the Americas, but I hope our paths cross in real life some time. :-)
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
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”).
Anyone thinking of doing it on the Web?
And, on people praising VBA integration under MS Office, that gave us security disasters with macros and millions of dollars lost because of Excel parsing genomics as dates.
It's better to decouple data and algorythms as separate files. Keep your raw data in a file, transform it and set the output in a separate process and file. You know, a proper pipeline. Something the Unix folks understood since the very beginning 50 years ago.
But "performance" fanboys don't care, until the shit hits the fan as it happened in Science with bioinformatics. Tons of studies, papers and research were just void because of shitty software.
Meanwhile, some Unix users with Slackware with discrete tools for every process (and not just a self-updating XLS file for everything) did it fine as they followed a basic reproducible chain.
https://slackalaxy.com/2019/03/15/slackware-and-slackbuilds-...
Harder? Yes, OFC. But, can you bet that your initial data will be the same on every process? For sure.
I remember submitting a stock charting application that Michael Risse and Nevet Basker used to love showing during the VB 1.0 launch demos (and road shows), because they could plot the chart of Microsoft (up and up) vs. IBM (not so up).
For me, VB 3.0 was peak Visual Basic, and I was on to doing Java stuff by the time VB 6.0 was released.
Fun times.
saidinesh5•1mo ago
I don't think I could've done that with any of the HTML5 / Web tools that were touted as an alternative at that time... Or probably even today. I mean sure there's MIT scratch that does half as many things as visual basic. But i feel like we need a little more "mature" tools that fill these gaps. I could be wrong and there's much better replacements these days..
WillAdams•1mo ago
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.
occasionalcoder•1mo ago
WillAdams•1mo ago
That seems to be the consensus --- hopefully it will become more popular, and I'll give it a try, and hopefully will add to that.
int_19h•1mo ago