I’m like @LowLevel, I have a software engineering and systems development background, but now do other things.
In my spare time, I do design and program video games for the Intellivision Master Component, a 30 year-old console sold by Mattel to compete with the Atari VCS back in the early '80s.
I can’t really escape my systems architecture roots, and have ended up designing and programming a comprehensive game programming framework and runtime engine for the Intellivision. It’s all in Assembly language and a huge complex layer of macros because the tool chain lacked a linker.
It depends. It’s nice for RAD development but has its flaws if you want to leave the road and do something the original developers didn’t think of. And what’s not so good is the limited bugfixing which requires you to update to next release as there are no backports. Some things use highly optimised ASM code other are rather suboptimal if you want ease of speed. In my company we have many tweaks and extensions to optimise the speed.
And the other problem is dealing with code that was clicked together by people that don’t follow proper code style or are inexperienced. But this is a problem with every language. Delphi was just an early and easy RAD area and thus attracted non-programmers.
I don’t know, I did much Win32 systems programming and low-level network programming in Delphi. However, it was eschewing the VCL for direct object manipulation and optimized routines, enhanced with hand-coded Assembly Language.
I find it’s Win32 wrapper library was easier to deal with than doing everything by hand in C, yet still close to the metal.
I’m not fond of the .Net managed code and virtual machine, but the C# language and frameworks are sound and close to the Delphi philosophy. No surprise there, since both were designed by Anders Helsjberg.
It’s quite interesting language, which begins to become more portable across the different OS types. But again here you have just the VM for .Net and it depends what language you are going to use. Programming in VB.Net is different from C#. And everything is better than the perversions from the 90s like the Visual J++ or the .Net variant J#.
But then the approach with virtual method tables is instable. I remember trying to debug an application crashing before the first line of code. Cause was a case typo in a Windows function name in D2010. And if you used it anywhere in your code the app would insta-crash because it couldn’t build its virtual method table. For a fix without manual patching of original sources you’d have to update to Delphi XE.
Even more - he knew which flaws Delphi had and could build something better.
Btw, one of the features I still miss is the ternary operator for short if-then-else notations. You can trick around by building own functions but this is limited as both cases are evaluated before calling the function while the ? operator in C/C++/C# uses lazy evaluation.
No, it’s basically the same. One just looks like shit
I remember porting a Java library to Visual J# back then… It actually worked really well. Since Microsoft even made x64 installers available for the Visual J# runtime this code still works today (but this library was eventually ported to C# anyway).
I also remember they made Delphi.NET but it’s deprecated now.