Why C# coders should shut up about Delphi (2016) • Hacker News Board

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

#141

Post by danielbarla » Thu, May 28, 2020, 11:55 AM UTC

jonnypotty wrote: post #140

danielbarla wrote: post #138

Earlier quoted context omitted.

This could be argued infinitely, I think. I do appreciate your points; yes, simply adding code - by default or by itself - does not resolve those things I mentioned. But, it's important to view my comments within the context of what we were talking about, which was the defacto development style that grew around Delphi, especially in the early days (before their libraries got smarter). In the case of my "SELECT *" exa…

My work until recently was working on one of the Delphi apps you're talking about. Not in terms of unoptimised queries but bad separation of business logic and ui. But the product has passed between 4 diffent companies and is over 20 years old now, I just don't see how you prevent these issues. I do see what you're saying, but I think the real issues is humans which hasn't changed.

Agreed, and I also don't have a real answer. At least, not a technological one. The closest we can get it is a bunch of developers who care about a product, ask themselves lots of "why do we do it this way", and "could this be done better", and try to come up with some solid answers. Of course, with products that survived 10+ years of maintenance, it is highly unlikely that enough time will be afforded to any team.

Circling back to what I was trying to say with the first comment - I suspect the rapid development promise and culture back in the day led to a lot of these apps being developed. The tooling was just an enabler.

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

#142

Post by FpUser » Thu, May 28, 2020, 12:59 PM UTC

monocasa wrote: post #126

thePunisher wrote: post #116

Earlier quoted context omitted.

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…

You can typecast integer to pointers in Pascal. It's not memory safe.

You know, I can always jump from that cliff. Still keep wondering why don't I do it.

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

#143

Post by colejohnson66 » Thu, May 28, 2020, 1:12 PM UTC

dleslie wrote: post #14

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…

You've even drank some of the koolaid by calling them "client side apps". They're simply applications, or if you must, native applications! ;) I'm heavily reticent towards using web-based interfaces to remote services, and I think that's healthy and fine. As a developer, of course it's less complicated to not be negotiating network communication in order to create an application!

So if a client side app is just an “app”, what differentiates it from a server side app?

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

#144

Post by dleslie » Thu, May 28, 2020, 1:34 PM UTC

colejohnson66 wrote: post #143

dleslie wrote: post #14

Earlier quoted context omitted.

You've even drank some of the koolaid by calling them "client side apps". They're simply applications, or if you must, native applications! ;) I'm heavily reticent towards using web-based interfaces to remote services, and I think that's healthy and fine. As a developer, of course it's less complicated to not be negotiating network communication in order to create an application!

So if a client side app is just an “app”, what differentiates it from a server side app?

All of the user's data is controlled, managed, stored, and owned by the user; there are no remote servers.

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

#145

Post by monocasa » Thu, May 28, 2020, 1:59 PM UTC

thePunisher wrote: post #139

monocasa wrote: post #125

Earlier quoted context omitted.

You've absolutely always been able to interop with asm as well as access and set arbitrary pointers with Pascal. I'm not sure where you got this idea that Pascal is memory safe.

Like I said, those were extensions made by compiler vendors, and not part of the original language. Borland enabled adding Assembler to almost every language for which they made a compiler.

You know that UCSD Pascal or ISO Pascal isn't the original Pascal, right?

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

#146

Post by monocasa » Thu, May 28, 2020, 2:03 PM UTC

FpUser wrote: post #142

monocasa wrote: post #126

Earlier quoted context omitted.

You can typecast integer to pointers in Pascal. It's not memory safe.

You know, I can always jump from that cliff. Still keep wondering why don't I do it.

Please take your projected inadequacies elsewhere.

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

#147

Post by thePunisher » Thu, May 28, 2020, 4:11 PM UTC

monocasa wrote: post #145

thePunisher wrote: post #139

Earlier quoted context omitted.

Like I said, those were extensions made by compiler vendors, and not part of the original language. Borland enabled adding Assembler to almost every language for which they made a compiler.

You know that UCSD Pascal or ISO Pascal isn't the original Pascal, right?

The only takeaway for me is that most developers these days don't understand the difference between systems programming languages and general purpose application languages either.

We need an AOT compiled general purpose application language like C# with managed memory access. If people want to fool around with low-level stuff let them use Rust, assembler or C/C++.

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

#148

Post by FpUser » Thu, May 28, 2020, 4:16 PM UTC

thePunisher wrote: post #116

FpUser wrote: post #39

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…

>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.

Maybe in your old classic pascal. Not true for modern Delphi/FreePascal incarnations of it. You can do pretty much anything including pointer math, including safe version of it.

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

#149

Post by FpUser » Thu, May 28, 2020, 4:17 PM UTC

monocasa wrote: post #146

FpUser wrote: post #142

Earlier quoted context omitted.

You know, I can always jump from that cliff. Still keep wondering why don't I do it.

Please take your projected inadequacies elsewhere.

Likewise

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

#150

Post by monocasa » Thu, May 28, 2020, 4:33 PM UTC

thePunisher wrote: post #147

monocasa wrote: post #145

Earlier quoted context omitted.

You know that UCSD Pascal or ISO Pascal isn't the original Pascal, right?

The only takeaway for me is that most developers these days don't understand the difference between systems programming languages and general purpose application languages either. We need an AOT compiled general purpose application language like C# with managed memory access. If people want to fool around with low-level stuff let them use Rust, assembler or C/C++.

Original Pascal was designed for bare metal systems programming on a CDC6000 series. Don't get snickety just because other people aren't abiding by your ahistorical definitions.