121–130 of 162 posts
I love this post. My first gig was slinging Delphi for a telecoms company, my second was C# and I've been involved with TypeScript since it was announced. I'm a complete fan of Anders Hejlsberg work. To the extent that I gave genuine consideration to naming one of my son's "Anders". My wife was not onboard.
Could you have gotten away with naming him 'Sharp' instead?
Except that C# worked on 64-bit OS's practically from the start and Delphi--still only marginally does. And this isn't theoretical--Altium actually did a full code rewrite in order to get off of Delphi because of this.
Unfortunately C# and the rest of .NET ecosystem (and for that matter Java and rest of JVM) are not fully 64bit capable to this day and will probably not be fully 64bit capable for the next decade if ever. What do I mean with this? .NET and JVM native arrays use 32bit indexes and most standard container classes also use 32bit indexes so you cannot have more than 2^31 elements. Who needs that many elements in the array…
[0] https://docs.microsoft.com/en-us/dotnet/framework/configure-...
Earlier quoted context omitted.
Modern C++ is actually pretty safe. Pascal is reasonably safe as well if you know what you're doing. And all this safety talk is over-hyped anyways. Just learn hot to program properly. I do not really remember when was the last time I had problem with "safety" in either Delphi or C++. My commercial apps (C++, Delphi and C for firmware run for years without a single crash report).
C++ is safe if you know how to use it properly, but this does incur overhead and many people aren't willing to incur any overhead because they want the fastest raw speed available. So they usually mess around with C like constructs in their C++ programs. Pascal OTOH is 100% safe no matter what you do because you can't access pointers directly or do pointer math or out-of-bounds array access. The pointers available in…
Earlier quoted context omitted.
I laugh because you'd think the distributed part would be the toughest one. But nope, it's pretty easy. In fact the client/server model was pretty well understood even in the 90s (or well before that even). In my opinion what has exploded the complexity is the proliferation of environments. The execution environment of our software provides very few guarantees on what is available (no standard library) or even what l…
Lol - 90s is the era that gave birth to PHP, I'd wager to say very few things were "well understood". People writing apps with 100s of global variables was the norm. If you worked with WPF you'll see angular 2 is very similar in spirit - complexity is on par. I don't really see the difference between native development and JS once you start dealing with the same level of complexity.
WPF is backed by the .NET framework. While the UI framework itself might not be easier than say "React", you have a stable language (C#) with a huge, stable, standard library for all kinds of things from Date manipulation to File IO. There are so many advantages to that ecosystem over JavaScript currently.
For example, I've been using numeraljs for number formatting in JavaScript. This is now un-maintained and contains a bug where if the number is below 1e-6 it shows up as NaN. So now I have to go source a new package for number formatting. This is so simple and core it's amazing I am searching for packages for it.
There is now Intl.NumberFormat but it has quirks also. But this is the crap you have to deal with on a daily basis with JavaScript.
Earlier quoted context omitted.
I don't think the distinction you're making about C and C++ being systems languages, and Pascal being an application language totally holds. Pascal is a totally fine system s language. AEGIS (a from scratch Unix like) was written in Pascal and by all accounts was a great option at the time. And what makes C and C++ unsafe exists in Pascal.
Pascal was originally an application programming language, not a systems programming language. These days you can probably mix assembly within your Pascal code or access pointers directly with some custom language extensions, but these weren't part of the original Pascal specification.
I'm not sure where you got this idea that Pascal is memory safe.
Earlier quoted context omitted.
Modern C++ is actually pretty safe. Pascal is reasonably safe as well if you know what you're doing. And all this safety talk is over-hyped anyways. Just learn hot to program properly. I do not really remember when was the last time I had problem with "safety" in either Delphi or C++. My commercial apps (C++, Delphi and C for firmware run for years without a single crash report).
C++ is safe if you know how to use it properly, but this does incur overhead and many people aren't willing to incur any overhead because they want the fastest raw speed available. So they usually mess around with C like constructs in their C++ programs. Pascal OTOH is 100% safe no matter what you do because you can't access pointers directly or do pointer math or out-of-bounds array access. The pointers available in…
Earlier quoted context omitted.
Lol - 90s is the era that gave birth to PHP, I'd wager to say very few things were "well understood". People writing apps with 100s of global variables was the norm. If you worked with WPF you'll see angular 2 is very similar in spirit - complexity is on par. I don't really see the difference between native development and JS once you start dealing with the same level of complexity.
Client/server models existed before the web and HTML/JavaScript. WPF is backed by the .NET framework. While the UI framework itself might not be easier than say "React", you have a stable language (C#) with a huge, stable, standard library for all kinds of things from Date manipulation to File IO. There are so many advantages to that ecosystem over JavaScript currently. For example, I've been using numeraljs for numb…
You won't hear me arguing that JavaScript is a great environment to work with - but people argue that JS frameworks are overcomplicating things - when in reality desktop frameworks arrive at the same design decisions.
It's hard being an old programmer as some technologies that you used in the past, that were more productive than certain technologies today, are no longer popular. Creating client side apps in the 90s was arguably easier than creating web apps today with the soup of html/css/js frameworks that are changing every month. edit/mass reply: I've been coding web apps with the rest of you guys for 20 years. The web isn't th…
Delphi certainly was supremely productive for the kinds of one-off, bespoke enterprise apps that I was involved with, and it is valid to question why that was the case. I don't think the tooling was necessarily all that superior, the industry trend was simply way towards "slap a grid on top of that SELECT * FROM Orders". Clearly, there are many things wrong with that, but the fact that one could whip up several scree…
FWIW, before there was Delphi there was an entire language (and consulting industry) built around this: PowerBuilder. Its primary component was a "DataWindow" which was a fancy presentation object around basic CRUD SQL. Good times were had by many.
Earlier quoted context omitted.
I don't trust Qt licensing anymore. Whatever company owns Qt will forever try to squeeze it for money. They recently changed their licensing AGAIN: https://www.qt.io/blog/qt-offering-changes-2020
They have not changed any licensing. They have changed the way they are releasing their product. The only thing really that is different here is the fact that they are pushing less code as open source for their stable LTS releases. If you rely on having a stable Qt, why not pay the company that develops the software? You and I, the developers that use Qt without paying for it, still get the latest and greatest Qt, wi…
Because it's too expensive for me to afford. More than an order of magnitude too high for me. As side projects I write closed source software so they do pull in a a bit of money. But this is typically only a few hundred to a few thousand per year per app. I think they target corporations rather than individuals or small shops.
It's hard being an old programmer as some technologies that you used in the past, that were more productive than certain technologies today, are no longer popular. Creating client side apps in the 90s was arguably easier than creating web apps today with the soup of html/css/js frameworks that are changing every month. edit/mass reply: I've been coding web apps with the rest of you guys for 20 years. The web isn't th…
I very badly want to get back to this. Maybe with Python and Qt on Mac?
Only downside is that it is Windows only.