Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why C# coders should shut up about Delphi (2016)

jonlennartaasenden.wordpress.com

Post reply on HN
Print view View original

81–90 of 162 posts

Re: Why C# coders should shut up about Delphi (2016)

#81

Post by lostmsu »

pjmlp wrote: post #20

Satire or not, one thing I do fully agree. It was a big mistake not embracing AOT from day one, C++ wouldn't have kept its king position in MS ecosystem if the original .NET had been like .NET Native since the begging and kept Delphi like features for low level coding (some of each are have been added since C# 7.x). JIT support could still be an additional option as well, just like on languages like Eiffel. Instead w…

I've been doing C# for over 10 years, and so far the AOT trend just gets in my way. I would prefer .NET Core on all platforms to just function similarly to .NET Framework on Windows: shared runtime(s) with major releases for breaking changes, and point releases for in place improvements.

Case in point: when Windows RT jailbreak came out, my .NET Framework AnyCPU apps just worked there. Now when I package, I very often have to list the target architectures in advance.

When I hear Java announcing JIT in Java and catching up with C# on syntax sugar, I feel that C# + .NET might start to lag behind in innovation.

Re: Why C# coders should shut up about Delphi (2016)

#82

Post by betzol »

pjmlp wrote: post #77
betzol wrote: post #75

Earlier quoted context omitted.

I'm not 100% on this, but I'm pretty sure that HPC# has a separate, LLVM-based compiler.

Unless something has changed, Burst also uses IL2CPP. https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual...

As far as I can see, if it's AOT compiled it requires the same linker tooling as IL2CPP does, but is otherwise separate from it.

https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual...

Re: Why C# coders should shut up about Delphi (2016)

#83

Post by lostmsu »

FpUser wrote: post #38
bsder wrote: post #27

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.

I am not sure what you mean under marginally. Delphi and FreePascal/Lazarus have no troubles producing 64bit executables. I have ongoing commercial product in Delphi and it is 64bit only.

Was it available in Delphi in 2016?

Re: Why C# coders should shut up about Delphi (2016)

#84

Post by 72deluxe »

temporaryvector wrote: post #74
jcfields wrote: post #66

Earlier quoted context omitted.

I did a couple of small projects in Python using wxWidgets recently, and I was surprised at how easy it was (as well as how consistent the results were between Windows and Mac OS).

I'm overall surprised at how unpopular/unknown wxWidgets is when the discussion turns to cross platform UI toolkits. I've used it a lot, as well as other popular toolkits (Qt, GTK, etc.) and I find that wx is, at the very least, the least bad option and overall programming in it hasn't been a pain, regardless of which binding I used. I guess my only complaint would be that it's a bit harder to do something way outsid…

I am surprised too. It is easy to talk to the devs about issues and also the documentation is good.

There are some rough spots here and there but all in all I am really baffled why you don't see more use of it. I use it in C++ for all my GUIs.

Re: Why C# coders should shut up about Delphi (2016)

#85

Post by sedatk »

29athrowaway wrote: post #33
thePunisher wrote: post #25

This blog is not an article but a rant full of half-truths and outright lies. The author doesn't realize that most C# developers have no knowledge of the history of both Pascal and C (I'm old enough to know) because they were born decades after these languages came into being. The author also misses the point that C and C++ are systems programming languages (for developing operating systems, device drivers and low-le…

Java and C#, in that order. C# appeared after Sun sued Microsoft for trying to embrace/extend Java.

That strategy worked really well for Sun Microsystems.

Re: Why C# coders should shut up about Delphi (2016)

#86

Post by 72deluxe »

nightski wrote: post #26
rubber_duck wrote: post #21

Earlier quoted context omitted.

Creating hello world and drawing trivial forms is just as simple with HTML/CSS/JS, you don't need a SPA MVC framework or component libraries or state management framework. Looking back to VB and other WinForms RAD tools it's easy to do that stuff and there are HTML WYSIWYG tools but that double-click code behind logic doesn't scale - software these days is distributed, has more complex requirements and expectations.…

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…

I can't agree more with your "we don't have standard UI primitives" and "every major website is expected to have a team of world class designers" comments. I have been migrating a site from an old to a new shop system and the amount of work for simply displaying product data, options and choosing something to buy is insane. I really believe we've lost something from the RAD era.

Re: Why C# coders should shut up about Delphi (2016)

#87

Post by sedatk »

dmz73 wrote: post #64
bsder wrote: post #27

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…

You can have 2GB array of 2GB arrays if you’d like. But, having a single contiguous huge block is only one scenario for 64-bit, not the only one. I doubt it’s the most common one either.

Re: Why C# coders should shut up about Delphi (2016)

#88

Post by pjmlp »

lostmsu wrote: post #81
pjmlp wrote: post #20

Satire or not, one thing I do fully agree. It was a big mistake not embracing AOT from day one, C++ wouldn't have kept its king position in MS ecosystem if the original .NET had been like .NET Native since the begging and kept Delphi like features for low level coding (some of each are have been added since C# 7.x). JIT support could still be an additional option as well, just like on languages like Eiffel. Instead w…

I've been doing C# for over 10 years, and so far the AOT trend just gets in my way. I would prefer .NET Core on all platforms to just function similarly to .NET Framework on Windows: shared runtime(s) with major releases for breaking changes, and point releases for in place improvements. Case in point: when Windows RT jailbreak came out, my .NET Framework AnyCPU apps just worked there. Now when I package, I very ofte…

.NET has had lot of innovation, AOT was there since the beginning via NGEN, although there was never a big investment in its optimizing capabilities.

Then there was Axum, Cω, Phoenix Compiler (LLVM like in .NET), Singularity, Midori, Rosylin, MDIL, .NET Native.

GraalVM goes back to MaximeVM and JikesRVM, so JIT in Java is also quite old.

What all these projects need is the money and political willigness to keep driving them forward, and here is probably the main issue with some .NET research projects, because since the begging Windows Development (which kind of owns the C and C++ story) teams aren't that willing into having too much .NET on their turf.

Re: Why C# coders should shut up about Delphi (2016)

#89

Post by jjeaff »

me551ah wrote: post #36
trixie_ wrote: post #9

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…

Not to mention how native client-side apps consume far less memory and CPU than their web/electron counterparts. I miss those days when I would have a bunch of native apps constantly running and minimized. These days it's considered normal for a music player to consume 500MB of memory and for chat apps to consume multiple GBs of RAM.

But if you spent the same amount of money on your dev system adjusted for inflation, of course, then it could probably handle everything you could throw at it.

Re: Why C# coders should shut up about Delphi (2016)

#90

Post by me551ah »

jjeaff wrote: post #89
me551ah wrote: post #36

Earlier quoted context omitted.

Not to mention how native client-side apps consume far less memory and CPU than their web/electron counterparts. I miss those days when I would have a bunch of native apps constantly running and minimized. These days it's considered normal for a music player to consume 500MB of memory and for chat apps to consume multiple GBs of RAM.

But if you spent the same amount of money on your dev system adjusted for inflation, of course, then it could probably handle everything you could throw at it.

It's only true if a handful of apps do it, but if everyone starts to do it then you end up with a scenario where RAM isn't enough for every application.

And also from an end user perspective, not everyone has a powerful dev machine.

Post reply on HN