2 ms·
The problem with Delphi and its relatives is that they are walled gardens. As long as you are working on the kind of application envisaged by the designers (rou
by paulajohnson 10y ago
The problem with Delphi and its relatives is that they are walled gardens. As long as you are working on the kind of application envisaged by the designers (roughly, CRUD with a SQL backend) everything is easy. As soon as you step outside that domain your foot disappears into a sucking quagmire.
- barrkel 10y agoI don't really agree. Delphi made writing native code on Windows really pleasant, primarily because it had (a) a built-in string type with reference counting and (b) strong conventions around object ownership and construction / destruction. The built-in string type interacted really well with the Win32 API, and it was universal - there wasn't one string type to deal with the platform, and another string type for your own code, and yet another string type for third party code, all too common in C++, especially in the 90s. The object model - zero-initialized reference types with a Destroy method that was safe to call on null values - avoided one of the biggest pains in C++ exception safety, in particular safely destroying partially constructed instances. The idioms in Delphi don't catch all cases (e.g. if a destructor throws, you're potentially going to leak), but they work really well 99% of the time without convolutions or RAII wrappers. Delphi did exceptions very well too. Because of the strong conventions around try/finally to wrap creation and destruction of objects, exceptions never felt dangerous or uncontrolled. I don't think anyone who used Delphi in anger pined for nothrow, explicit exception specifications or wholesale replacement of exceptions with error codes. The point is that it was a high-level native language language that was far easier to use correctly than C++.