Skybuck's Thoughts on Delphi in 2022

I watched some video about Delphi 11.2 and it got me going, gonna share my thoughts on Delphi in 2022 with you, maybe it interested somebody out there :)

Here it is:

"
Feedback on Delphi 11.2 video on youtube:

The question about foldedably try except blocks was hilarious. There is some hypocrazy going on here as well, GOTO is bad, but jumping to some except block is perfectly fine ! XS

The least this company could do is attempt a write of bitcoin database into their own database software, to make a point and prove something, see how it performance, also to unlock bitcoin transaction data to Delphi developers, via FireDAC, at the very least it's a nice publicity stunt and might actually give that old database technology from this company some more new sunshine for the crypto crowd ! =D And maybe some nice Delphi bitcoin applications will emerge out of it. However bitcoin database is huge ! Not a light thing.

There is C++ Builder, so it should be possible to run bitcoin inside C++ Builder and slap some FireDAC on it or under it, otherwise this product is not very impressive.

Databases are a failed concept as far as I am concerned. Try work on something new, something more distributed, like a world computer, a distributed database, study kademlia or other distributed hashes algorithms, also content addressible system. A centralized/hackable easily denial of service attacked, expensive to run database is such an old concept, boring as well, totally not exciting and very limited in capabilities.

The graphical technology that exists today is limited, frustrating and slow. For a really hi-tech project, work together with nvidia and re-invent the gui with advanced topics like distance field rendering and design a new computer chip that can accelerate GUIs and 2D graphical data properly and in crystal clear form and at high speed. CPU is a hot place and gets something over worked rendering GUIs and maybe also supplieing GPU with other api calls and data... string thing to pack some much code in such a tiny hot chip. Few more years and CPU/industry will start to fail as faster products no more possible. Offloading commons tasks to specialized chips located elsewhere on motherboard with their own coolers will become the new thing =D... To bad NVIDIA was not allowed to take over ARM to integrate ARM cpu into GPU, maybe could have become something cool/new/essential to have. But designing their own CPU/CHIP instead should also be a possibility.  Compiler writes could help with that. Perhaps some scripting language for 2D geometry/distance field rendering could be a start.

It's strange how the main loop/thread runs Tapplication.initliaze/run etc... this is also worth considering moving into some thread and allowing users to actually write their own main program besides the Tapplication and Tform... currently too much code gets directly integrated into TForm handlers etc... it's a bad software development code practice and may have to be broken to take Delphi to new levels. The VCL is getting old, multi-threading is around the corner... transitioning to a new multi-threaded based approach may be necessary. No longer should Delphi dominate the main thread or freeze the application if something like a TMainMenu item is used etc... plenty of work to do to bring Delphi to the future ! =D

One of the most annoying things in Delphi is "find declaration" on some kind of system variable or function call or type or whatever, and then the cursor ends up on system.pas/unit name instead of actually finding something. This should be looked at and fixed, a very old and nasty/annyoing short coming in Delphi IDE and lookup system.

One strong part of Delphi which could be exploited is the strength/engineering (I hope) that goes behind the VCL/Component library. Explaining the philosophy or design decisions that are made during the development of these components would be golden advise for other developers. The integration of other components into the VCL build upon other components is amazing. This is one of Delphi's strongest points but very hard to do. A guide how to best integrate software/code/components into the VCL and how to design them would be a very good idea. There is some of it in the help file perhaps but it's too limited, more should be done in this regard. And it should also be promoted more and used to put Delphi apart from other development solutions, like python. Delphi is more plug and play, click and play, sounds like childplay, some might frown upon it, but this is Delphi's very strong side/point and is not highlighted enough in marketing and new presentations.

The VCL components have many limitations, a questionair should be help publicly online where developers can go to fill in questions about what they find limitating about VCL components, then over time/years these limitations/remarks/comments can be collected and the components made better/more powerfull, it feels like development team is blind to limitations and progress of these components, same limitations as 20 years ago or so, very little progress made.

There should be some explanation about how Delphi finds sources files and especially DCU units in relation to BPL especially when platform 32 bit and platform 64 bit is used. Currently I have no idea what happens, plus sometimes bad unit error happens and a build must be done again... notice this with GLScene library usage. Also is it 64 bit capable or just 32 bit ? Is it possible to use a 32 bit BPL with a 64 bit windows application ? Packages should be documented and explains much more thoroughly what is what and what is dcp etc. BPL has some potential, but may need some more work to improve it a little bit, not always as debuggable/intelli sense as the "real code/pascal files".

Another great idea would be to include the object pascal language book/pdf from Marco Contu with the product :)

Also Delphi help files should be accessable available via the start menu, without having to start Delphi.

A big waste of time is including the C++ documentation in the Delphi help files, plus the help files themselfes have some display issues, and the help could be worked out a bit more, many things undocumented. The filter on C++ don't work well or isn't there. There should be ZERO C++ in the Delphi helpfiles, it's just a waste of time. Plus it should be more clear in the index, what is what, which help file contains what documentation, this is unclear.

The best recommendation I can give the development team of Delphi is to sit down with noobie programmers, give them tasks to program, watch how the fuck up, or don't understand things, how they create bugs, how access violations happen, etc, etc, etc and then start changing Delphi and work on that to make Delphi again attractive for noobie programmers, to give it back the status of a nice easy to learn language and easy to use language to reach results with. Focus on attracting new/young programmers to the Delphi language/tool, the existing older programmers already know how to take care of bussiness/bugs in Delphi, but it's the younger generation that will suffer and thus Delphi loosing out to C# and Python, etc.

Automatically cleaning up dynamic pointers or dynamic arrays or something like that or interfaces is a super dangerous future in Delphi, currently Delphi applications can very easily generate access violations by simply declaring some uninitialize record somewhere on the stack/as a local variable in a routine somewhere, very hard to find and solve, definetly something technical that should be looked into and perhaps abolished, nothing worse than hard to find access violations. It's disheartening for me, I can only imagine what a noobie might feel like. It can give  Delphi a very bad taste in the mouth and noobies developers might look elsewhere and switch to python or some other language that doesn't blow up in their face.

Record inheritance is also something that makes me a bit jealous of visual studio/c/c++, something worty to consider for Delphi language feature expansion, makes designing data structures more powerfull, can also be a bit scary to have to make more decisions in case of splitting it up into multiple structures, this is where C++ has a big edge over Delphi though.

One last thing which makes me a bit jealous of Visual Studio is intrisincs for special intel/amd instructions which can accelerate certain operations. More time could be invested into trying to make some nice easy to understand intrinsincs for Delphi to benefit from these "accelerators".

Labels and goto statements should also be made more advanced, I know people frown at this, but could be interesting in some cases, I had at least one case or maybe two where this is/was interesting, it's at least something that should be played with it, it should be a hell lot easier to make labels inside the code, without having to declare them up top in the var statement or something like that... sometimes structure programming can be too limited, further experimentation could be done with jumping to direct address stored in variables, something with much more advanced capabilities then simple for loops which are super limited and while and repeat until which is also super limited in capabilities.

Please never remove the with statement, it's one of the more convenient things compared to C++, to accomodate noobies not understanding the scope, what could be done, is when mouse hovers over variables which are related to a with statement, show that in a balloon pop-up, what scope they are related too. The same could be done with variables inside a TForm event handlers, not all variables are of the TForm object, some of them may be global or coming from certain units. Having something like this, a "scope" inspector would make Delphi a whole lot more friendly for noobie programmers. Ice-ing on the cake would be to not only show the type to which it belongs, but also which instances/variable name, or with statement or object, something like that. Perhaps this is a case where Delphi's RTTI can shine or is too limited and may need expending in new features or a new runtime information library. RTTI is about types, what may be needed is something for actual instances.

Another tool which is somewhat interesting is deepgit, a bit of a niche but usefull tool for hard to find changes to source code, also worthy of a take-over if possible, must also not let it go to waste... somehow the software world is starting to pivot around git... it will and already is the new battleground for software developers :)

There is a tool called: "understand" if you have not seen it definetly check it out, it can visualize and make source code/structure easier to understand, an amazing tool, if it's buyable because it's not doing well commercially then still a good buy to add to tool chain, must not let it go to waste.

Delphi lacks a strong web presence for cheap/free stuff like apache/html/php. One new possibility is Web Assembly, compiling Delphi to Web Assembly could be very interesting as well as having a GUI in HTML 5.

Python scares me, the installer for 3.0 didn't work on windows 7, I know old OS but still... the python language seems to evolve fast and the latest version must be used/installed otherwise it don't work... I see python as a dependency risk that could break/fail easy.

I worry a bit about GPUs maybe disappearing or breaking some day... perhaps replaced by multi threading. I hope Delphi IDE and GUI will always work on cpu or at least embedded GPU, so far it's doing ok. Though latest rad studio 11 does not run on windows 7, kinda shame but ok... it was a great operating system, I wonder how much it's still being uses by companies using Delphi ! :)

One weakness of git is it has no proper versioning, no version numbers, it can be done with tags though. This is something where git could be improved or a custom version created of git, something where versions are automatically stored in seperate version folders, to be able to look at different versions and have peace of mind that multiple copies exist on disk, without having to worrie that all copies are lost because of the git repository being destroyed... Something better, more powerfull than GIT could be created, something more robust more aimed at personal developer, small team development, not full blown operating system development with gigabytes of source files and outputs, but something a bit smaller where duplicates are desired for robustness/reliability/redundance sake and quick access to source code without requiring checkouts of older versions.

Something to keep an eye on is git and git integration. Visual Studio is ahead in git editing/differencing etc, this should be a questionary for delphi programmers/customers if they want git differencing inside of Delphi, curious as to what feedback would be. I personally also like github a lot, keeping an eye on that should be interesting too, perhaps Delphi can integrate a little bit with it to provide some feedback what is going on on github repositories, perhaps give notification if some Delphi related project was updated or had some new commits, could be interesting. Also a better insight than github has would be amazing to have and attract some developers to delphi for just that feature.

Mobile is kind of a waste of time, except for the arm part, mobile phones will disappear in the future as they cannot keep up with desktop performance, it will be a passing trend and people will be forced to return to desktops with better coolling options, though perhaps thin phones can cool nice too. Slow technologies like python, java/javascript will disappear as they cannot keep up with faster technology like Delphi. C++ might make a comeback because of multi-threading which increases compiler speed, most of the technologies focused on today will be gone and was a passing trend, edge may be gone as microsoft looses interest, why repeat the mistakes of internet explorer ? Focussing more on Delphi only technology is the way to go, isolate Delphi developer from the ever changing world and provide great technology within Delphi language itself.

Delphi generates a large rsm file for 64 bit platform, there is no way to disable this... this takes up a lot of space and has to be deleted manually. If these could be automatically deleted after a debug sessions that could be a handy feature.

Tlist/generic is also very limited in capabilities, more methods to do all kinds of things with it would also be highly appreciated.

Improve CORE of Delphi first, beyond 2 GB static structures/arrays, can be usefull for typecasting and debugging. Currently only dynamic arrays can move past the 2 GB limitation. Other limitation is 64 bit math in constant expressions. Other limitations include TrySetLength and TryCreateObject not available, forcing the use of try except blocks. TVarRec not supporting record, makes open array parameters for records dangerous. Interfaces may be dangerous as well for same reason, though need further investigation. Operator overloading for classes would be nice. Destructor for record would be nice. Initializing local variables to 0 would be very nice. Anonymous records and local records have advanced limitations, not a fan of this but does make language somewhat inconsistent.
"

Bye,
  Skybuck.