No. It's the fact that it is a great 12 year old machine that makes it notable.
I would not be surprised if it was usable as a 20 year old machine. These things are comfortable and they last.
I got mine for $100, about 4-5 years ago. Only 1 USB port seems to work. Great keyboard, only 720p screen, did not upgrade the HDD. Works great as a secondary machine. I expect to use it for at least another 5 years, likely more. I love old machines and how repairable they were.
I wish they would not make the new laptops that tight and thin. I like low weight, but would not mind a little thickness, if I can open it and clean it easily, change the paste, upgrade easily, have external battery, more room for venting and so on. These are very practical features.
On a related note, I just don't understand the madness of having battery inside the laptop in gaming laptops these days. The heat kills them. These are mostly portable desktops and I can't find any new gaming laptops that have external batteries anymore so that I can use them on just external power. In the rare occasion, it ends up as a very premium feature. These things were basic features in the past.
I used it. The user experience is not remotely close to Delphi, but it has WYSIWYG. The closest Python had to Delphi was Boa Constructor, but it stalled quickly, decades ago.
VB5/6 had native code compilers. Performance wise, the gap was reduced.
But it still was only object based and not full OOP, VCL was much better in all respects, so were the GUI builders. The component ecosystem was much better, despite having a much smaller user base. I prefer not to use Object Pascal today, but back then, it was superior to using VC++ or VB.
Those were nice because you would start with floating elements that you'd move around with the mouse until you'd figure out a good layout and then add the anchors at the end and make it all flexible. Delphi was all about having a smooth progression from mockup to prototype to production. Compared to it, current web workflows are outright retarded.
VB6 was primitive compared to what Delphi gave us. It had live design time data binding, visual form inheritance etc. VB and VC++ were primitive compared to that. VCL vs MFC? No contest. The API was powerful, fast, great to extend by inheritance, best in class layout management. There were about 8000 third party components at web sites like Delphi Super Page. Half of those were free, rest were affordably priced for commercial use.
Much of the 90s experience lives on in FPC/Lazarus, but it did not get much better after that, and few use it. I wish they aligned themselves with a more popular language like Rust or Go for a more cohesive experience, while keeping Object Pascal (built with IDE experience in mind).
I still prefer the GUI building experience in Delphi 6/7 than anything that was produced since then. C#/Winforms is fine, it was designed by the same person - Anders Hejlsberg, but I wanted something native.
It's unbelievable that something modern like Flutter still fails to capture the design convenience of Delphi, from decades ago. Yes, the design markup is great, but I don't even want to look at it most of the time.
The later Swing/SWT editors never came close. Even Qt, which was inspired by it, never provided the component market experience of Delphi, and it was much more bloated in runtimes.
I fell in love with GUI design with Delphi, but otherwise hated it since.
> Much of the 90s experience lives on in FPC/Lazarus, but it did not get much better after that, and few use it. I wish they aligned themselves with a more popular language like Rust or Go for a more cohesive experience
A very core aspect of LCL and how Lazarus works (and VCL/Delphi for that matter) is language features like metaclasses, RTTI, properties, etc which allow the framework to register classes, instantiate them at runtime and inspect the class definitions so that serialization/deserialization and IDE features like the object inspector will work. AFAIK neither Go nor Rust have this.
The only language off the top of my head that has it is C# (which isn't surprising considering both Delphi's dialect of Object Pascal and C# were designed by the same person).
Of course there can be language extensions like C++ Builder did for C++ but they'd need to maintain their own compiler (or fork).
Personally i get the impression that Visual Basic and Delphi's language features were added in tandem with the underlying framework (if not deciding first how the framework and IDE features will look like and then deciding on the language features to support those) whereas modern UI stuff are made with whatever the target language has in place.
> Of course there can be language extensions like C++ Builder did for C++ but they'd need to maintain their own compiler (or fork).
This is exactly what I hope would happen, except this time with Rust or Go. They don't need to integrate fully. I am not hoping for the ability to write Go/Rust for GUI code, just to be able to call into them without the clunky foreign functions.
I leave out Pascal now because besides the GUI part, the value isn't there anymore. The language is archaic otherwise.
> Personally i get the impression that Visual Basic and Delphi's language features were added in tandem with the underlying framework (if not deciding first how the framework and IDE features will look like and then deciding on the language features to support those) whereas modern UI stuff are made with whatever the target language has in place.
I agree. But the features stabilized, more or less. IDE experiences have not gotten better in a long while. It's not much of a moving target.
> language features like metaclasses, RTTI, properties, etc which allow the framework to register classes, instantiate them at runtime and inspect the class definitions so that serialization/deserialization and IDE features like the object inspector will work. AFAIK neither Go nor Rust have this.¶ The only language off the top of my head that has it is C#
They're not "static enough" to have automatic serialization/deserialization and object inspector-like functionality. AFAIK in OpenStep/GNUstep/Cocoa objects (derived from NSObject) are expected to implement encodeWithCoder and initWithCoder to save/load to an object to disk and relies on per-class versioning and the subclasses handling the versions manually. The default NSObject implementation does not do anything as it doesn't have enough information to do anything "automatically". For an IDE you could have objects implementing a protocol that enumerates properties (or just creates the GUI for editing an object) but this isn't something that can be done by what the language provides itself.
In Smalltalk you might be able to inspect objects and their values. The VM certainly has enough information for that - after all it needs to so it can read/write the image the objects are in - but i don't know how much of that is exposed (i've only played around with a few Smalltalks and never made any real application with them). Though even if that functionality is available, you'd still need some way to tell -say- a Delphi-like object inspector what properties are available and what values they are meant to be (so, e.g., a "backgroundColor" property is presented in the GUI with a color editor and not a string editor or whatever else :-P).
In contrast, Free Pascal (and Delphi) has enough functionality to implement serialization/deserialization for objects without the objects themselves having to have any custom logic (this is how components are saved - you simply declare a published property and the framework handles serialization and the IDE handles showing it in the object inspector with the appropriate editor based on its type). In addition the on-disk format can be implemented in a way as to allow only storing properties which have different values from the defaults (there is a language keyword to specify what the default is though there are also other means), meaning that any new property can be added. The default object writers work like that but as this information can be exposed to any program, you can do your own (the default formats and functionality mostly support whatever is needed for saving GUI forms but in my own game engine i need more functionality than that to handle binary data and external data assets so i wrote my own serialization system).
