Agreed on all points except [2], I run many scrapers and sites change _all the time_, often changing markup for seemingly random reasons. One government site I scrape changes ids and classes between camel and snake case every couple of weeks, it makes me wonder if it's a developer pulling a fast one on the client.
Hearing this makes me suspect some tool auto-generates the id's and its config is getting changed every couple weeks by some spaces vs tabs battle between devs.
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.
I'd also like some horror stories, like someone vibe-coding their way into burning a million dollars by accident and having to sell a kidney on the black market so they don't lose their house.
Oh, good. All you have to do is happen to grow up somewhere with opportunities, move home for a great job, happen to have the house next door to your family's go on sale at an affordable price at a time you can afford it before having children, win the bidding process for it, and have the family never move and stay in good enough health to leave your baby monitor on in the background without nodding off, then have nothing happen to your kid that requires a fast response time.
Look, I'm all for creating community and building relationships with your neighbors, but this person lives a very privileged life and seems completely braindead to it.
Try to build a community where you can get friends to babysit once in a while. If you have a baby, go on your cruise with family or friends with a baby who can trade shifts with you and be on the same floor as the kid.
Even if you believe that every one of these things is correct (which is a big _even_) -- It's a really bad idea to let private actors break the law, then decide not to punish them if it turns out to be useful enough.
It's bad for competitors who didn't break the law, bad for future companies who have to gamble on if they're getting a pass at breaking the next big thing's law, and bad for parties who suffered losses they didn't expect because they were working within the law.
If you want to throw out the copyright system I'm right there with you, but change the laws, don't just reward lawbreaking and cronyism.
I have heard many stories of being a Sesame Street zombie once upon a time, so I doubt you were much more resistant to Mr Rogers gentle charms =).
There's a definitely a big gulf between the Mr Rogers / Daniel Tiger / Bluey energy and almost every other show. It's crazy now noticeable it is. Even modern Sesame Street is much more frenetic and lively than old episodes from the 80s and 90s. Which is not to say it's empty junk food like Cocomelon, it's just that those shows have raised the required addictiveness bar overall.
reply