5 ms·

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

vunderba 1y ago
Agree - while the concept of event-driven programming was not without its quirks, it was very easy to grasp for a newcomer. I do think the WinForms editor in Visual Studio C# was a pretty decent spiritual successor that came close to capturing the magic of a drag-and-drop GUI builder. Aesthetically lacking but highly functional.
- raddan 1y ago
  I also used both of these at a formative time in my programming career, and it really felt magical. I built half a dozen little apps, some using Access (another product whose loss I mourn), to solve problems at the small company I worked for that “professional” developers quoted us many times my salary to develop.
- jeswin 1y ago
  > I do think the WinForms editor in Visual Studio C# was a pretty decent spiritual successor that came close to capturing the magic of a drag-and-drop GUI builder. Aesthetically lacking but highly functional. It required the .Net Framework to be installed, which in the early 2000s (with far lower internet penetration and speeds) was a big enough problem. It wasn't particularly great either - Microsoft's attempts to port their own desktop products to .Net mostly failed. It was basically Java for the Windows Desktop, and never quite took off in the way VB apps did.
  - vintagedave 1y ago
    WinForms itself was largely a clone of Delphi. C# through version 2 was essentially Delphi with C syntax.
    - int_19h 1y ago
      It would be more accurately described as a blend of Delphi and Java, the latter via J++. The overall object model is from Java, tweaked to merge the primitive types with their boxed wrappers (i.e. `int` vs `Integer`). C# strings and arrays were also almost a carbon copy of Java rather than anything Delphi-like, although it did add multidimensional arrays. From J++ it got delegates and events. From Delphi it got things like properties and explicit `virtual` on methods, but notably not e.g. overridable class (static) methods or named constructors. Also, Delphi had manual memory management, not GC.
      - neonsunset 1y ago
        > C# strings and arrays were also almost a carbon copy of Java You'd be surprised but .NET and Java strings have a lot of differences. In Java, String is a class which wraps byte[], in .NET - string is a "FieldSeq" object with characters stored inline. One indirection less but with no special fields and cached state like in Java. Arrays have significant differences too, where Java arrays do not implement any actual collection interfaces - they are just contiguous chunks of elements with an indexer and length field and need to be asList'ed, so it's common to consider in Java to rely on arrays an anti-pattern, which is the opposite to C# arrays, which implement the full set of System.Collections.Generic interfaces.
        int_19h 1y ago
        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).
mattl 1y ago
There's an amazing era in the mid 90s where Steve Jobs is promoting NeXT stuff that interacts with Visual Basic. D'OLE, etc.
- bitwize 1y ago
  D'OLE sounds like something Homer Simpson would say in frustration, and the implementation was probably a cause for such frustration in actual use, cool demos notwithstanding.
  - mattl 1y ago
    > D'OLE > D'OLE makes it possible for Windows developers to build robust, scalable, distributed applications today > Building on NeXT's leadership in object-oriented software development, D'OLE brings the OPENSTEP object model(PDO) from UNIX to the Windows platform and integrates it with Microsoft's Object Linking and Embedding(OLE) object model. Through this integration with OLE, it is now possible to use popular Windows development tools, such as Visual Basic and PowerBuilder(which are currently limited to small workgroup deployments) in conjunction with OPENSTEP objects. This allows application developers to create distributed client/server applications that are scalable to the enterprise. Developers can use their tool of choice to create custom applications that employ a multi-tier distributed object architecture. > D'OLE also makes it possible, using only OLE objects, to create a truly distributed computing environment on the Windows platform. For instance, you can modify an Excel spreadsheet running on one Windows NT client machine from a Visual Basic application running on another Windows NT client machine. > Interoperability with OLE is accomplished via support for OLE Automation, which provides transparent integration between OPENSTEP and OLE objects. OLE objects simply connect to, and message, OPENSTEP objects just as if they were OLE objects, and vica versa. With this integration, popular Windows GUI design tools can take advantage of NeXT's advanced object technology without modification. > D'OLE also supports the Enterprise Objects Framework. The Enterprise Objects Framework supplies data access services that allow objects to persist in industry-standard relational databases. These persistent objects provide database independence and can be reused by multiple OLE and OPENSTEP applications. The pairing of the Enterprise Objects Framework with D'OLE also enables a distributed computing environment that provides an infinitely flexible choice of application deployment strategies.
analog31 1y ago
I think that the earliest methods of programming windowed computers were just way over the heads of mere mortals, including myself. For those of us where were comfortable with earlier computers, GUI required simultaneously grasping OOP, a mountain of opaque documentation, and a complex IDE and build process. All at once. No surprise that the first GUI programs I wrote were in LabVIEW and Hypercard, followed soon thereafter by VB. While I'm not a commercial developer, I still avoid any "stack" where the tutorial for "Hello World" doesn't fit comfortably in one page.
- 01HNNWZ0MV43FF 1y ago
  GUIs are still harder than they need to be. Async patterns that don't compose, operating systems where CLI and GUI programs are separate concepts entirely, massively complex GPU-based stacks needed to fill 800 MP/s... I no longer blame people for punting to Electron. As bad as HTML is, it's still only 100 MB to save yourself from the worst parts of GUIs.
  - int_19h 1y ago
    On Windows, GUIs are still as easy as they were in VB6 days if you pick the right tools. It only becomes a headache if you need cross-platform support. Although even there options like Avalonia are far superior to Electron.
    - anthk 1y ago
      Lazarus it's cross platform; it might even run under Windows XP and 2000, if not NT too...
      - lproven 1y ago
        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...?

vunderba 1y ago

Agree - while the concept of event-driven programming was not without its quirks, it was very easy to grasp for a newcomer. I do think the WinForms editor in Visual Studio C# was a pretty decent spiritual successor that came close to capturing the magic of a drag-and-drop GUI builder. Aesthetically lacking but highly functional.

raddan 1y ago
I also used both of these at a formative time in my programming career, and it really felt magical. I built half a dozen little apps, some using Access (another product whose loss I mourn), to solve problems at the small company I worked for that “professional” developers quoted us many times my salary to develop.
jeswin 1y ago
> I do think the WinForms editor in Visual Studio C# was a pretty decent spiritual successor that came close to capturing the magic of a drag-and-drop GUI builder. Aesthetically lacking but highly functional. It required the .Net Framework to be installed, which in the early 2000s (with far lower internet penetration and speeds) was a big enough problem. It wasn't particularly great either - Microsoft's attempts to port their own desktop products to .Net mostly failed. It was basically Java for the Windows Desktop, and never quite took off in the way VB apps did.
- vintagedave 1y ago
  WinForms itself was largely a clone of Delphi. C# through version 2 was essentially Delphi with C syntax.
  - int_19h 1y ago
    It would be more accurately described as a blend of Delphi and Java, the latter via J++. The overall object model is from Java, tweaked to merge the primitive types with their boxed wrappers (i.e. `int` vs `Integer`). C# strings and arrays were also almost a carbon copy of Java rather than anything Delphi-like, although it did add multidimensional arrays. From J++ it got delegates and events. From Delphi it got things like properties and explicit `virtual` on methods, but notably not e.g. overridable class (static) methods or named constructors. Also, Delphi had manual memory management, not GC.
    - neonsunset 1y ago
      > C# strings and arrays were also almost a carbon copy of Java You'd be surprised but .NET and Java strings have a lot of differences. In Java, String is a class which wraps byte[], in .NET - string is a "FieldSeq" object with characters stored inline. One indirection less but with no special fields and cached state like in Java. Arrays have significant differences too, where Java arrays do not implement any actual collection interfaces - they are just contiguous chunks of elements with an indexer and length field and need to be asList'ed, so it's common to consider in Java to rely on arrays an anti-pattern, which is the opposite to C# arrays, which implement the full set of System.Collections.Generic interfaces.
      - int_19h 1y ago
        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).

mattl 1y ago

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

bitwize 1y ago
D'OLE sounds like something Homer Simpson would say in frustration, and the implementation was probably a cause for such frustration in actual use, cool demos notwithstanding.
- mattl 1y ago
  > D'OLE > D'OLE makes it possible for Windows developers to build robust, scalable, distributed applications today > Building on NeXT's leadership in object-oriented software development, D'OLE brings the OPENSTEP object model(PDO) from UNIX to the Windows platform and integrates it with Microsoft's Object Linking and Embedding(OLE) object model. Through this integration with OLE, it is now possible to use popular Windows development tools, such as Visual Basic and PowerBuilder(which are currently limited to small workgroup deployments) in conjunction with OPENSTEP objects. This allows application developers to create distributed client/server applications that are scalable to the enterprise. Developers can use their tool of choice to create custom applications that employ a multi-tier distributed object architecture. > D'OLE also makes it possible, using only OLE objects, to create a truly distributed computing environment on the Windows platform. For instance, you can modify an Excel spreadsheet running on one Windows NT client machine from a Visual Basic application running on another Windows NT client machine. > Interoperability with OLE is accomplished via support for OLE Automation, which provides transparent integration between OPENSTEP and OLE objects. OLE objects simply connect to, and message, OPENSTEP objects just as if they were OLE objects, and vica versa. With this integration, popular Windows GUI design tools can take advantage of NeXT's advanced object technology without modification. > D'OLE also supports the Enterprise Objects Framework. The Enterprise Objects Framework supplies data access services that allow objects to persist in industry-standard relational databases. These persistent objects provide database independence and can be reused by multiple OLE and OPENSTEP applications. The pairing of the Enterprise Objects Framework with D'OLE also enables a distributed computing environment that provides an infinitely flexible choice of application deployment strategies.

analog31 1y ago

I think that the earliest methods of programming windowed computers were just way over the heads of mere mortals, including myself. For those of us where were comfortable with earlier computers, GUI required simultaneously grasping OOP, a mountain of opaque documentation, and a complex IDE and build process. All at once. No surprise that the first GUI programs I wrote were in LabVIEW and Hypercard, followed soon thereafter by VB. While I'm not a commercial developer, I still avoid any "stack" where the tutorial for "Hello World" doesn't fit comfortably in one page.

01HNNWZ0MV43FF 1y ago
GUIs are still harder than they need to be. Async patterns that don't compose, operating systems where CLI and GUI programs are separate concepts entirely, massively complex GPU-based stacks needed to fill 800 MP/s... I no longer blame people for punting to Electron. As bad as HTML is, it's still only 100 MB to save yourself from the worst parts of GUIs.
- int_19h 1y ago
  On Windows, GUIs are still as easy as they were in VB6 days if you pick the right tools. It only becomes a headache if you need cross-platform support. Although even there options like Avalonia are far superior to Electron.
  - anthk 1y ago
    Lazarus it's cross platform; it might even run under Windows XP and 2000, if not NT too...
    - lproven 1y ago
      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...?