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

131–140 of 162 posts

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

#131

Post by seangrogg »

jonnypotty wrote: post #98
seangrogg wrote: post #65

Earlier quoted context omitted.

Isn't a day on HN unless someone complains about web development while pining for the days when they were building command line calculators in COBOL on their mainframes while sipping espresso with Turing and Dijkstra.

Are you really gonna defend the current state of Web development?

Nope. Web development could (and should) be much cleaner. But it doesn't get there by tirelessly adding to the list of curmudgeonly comments over and over and over. As a web developer who made zero choice for HTML, CSS, and JavaScript to be in the position they are today and who is wholeheartedly open to seeing the chances that things like wasm could bring it is honestly more tiring reading yet another derisive comment about JavaScript fatigue than it is actually dealing with the churn in the ecosystem.

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

#132

Post by seangrogg »

trixie_ wrote: post #70
seangrogg wrote: post #65

Earlier quoted context omitted.

Isn't a day on HN unless someone complains about web development while pining for the days when they were building command line calculators in COBOL on their mainframes while sipping espresso with Turing and Dijkstra.

Don't worry, eventually the web development will be figured out and it retrospect we'll look like cavemen rubbing two sticks together.

I honestly hope so. Sticks are passable enough for addressing today's CRUD apps but I'll readily take scalpels and plasma torches as they become available.

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

#133

Post by pedro2 »

tim-- wrote: post #46
AlexanderDhoore wrote: post #30

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…

It was not just LTS. The rumor [1] was:

  > As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months.
  > They are aware that this would mean the end of contributions via Open Governance in practice.
[1] https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...

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

#134

Post by 29athrowaway »

sedatk wrote: post #85
29athrowaway wrote: post #33

Earlier quoted context omitted.

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.

Some of the technologies associated with Sun that you can use today free of charge: NFS, ZFS, DTrace, Java, NetBeans, VirtualBox, OpenOffice, MySQL.

They don't deserve the trash talk.

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

#135

Post by FpUser »

goto11 wrote: post #68
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…

The advantage of web apps is in deployment. Developing a stand-alone app in Delphi or Visual Basic was highly productive, but distribution, installation and updating was a headache. And it would only run on one platform.

" but distribution, installation and updating was a headache"

I am not sure what headache are you talking about. My product/s are usually single exe with dependencies statically linked and acting in dual role: setup and the end software itself. Installation goes like this:

1) customer clicks on link

2) setup.exe is downloaded and ran.

3) setup copies itself to a proper location and renames itself to yourwonderfulsoftware.exe.

4) When running it may communicate to servers to get whatever data/files/licenses it needs if any.

5) It also checks for new version and if there is any it can self update if you click that "update" button.

6) Before update starts the old version and data are always backed up.

Yes it does lack that instant satisfaction experience that comes with good web applications. But then again the if software I want to make looks like a good candidate for Web target way I will implement it as a web app.

In hopefully not too distant future Web assembly may make the difference minimal but we will have to wait and see how it goes.

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

#136

Post by monocasa »

FpUser wrote: post #111
pjmlp wrote: post #107

Earlier quoted context omitted.

Not 70% caused by memory corruption bugs, I guess said clients are not a security target.

My servers use proprietary protocols and one of the first thing my protocol handlers do is check validity of the input. You will not find generic "read until EOL/Whatever" in my code. The low level logic knows exactly what to expect at each point and how to validate it. All over encrypted connection. Good luck hiring dedicated expert or team willing to break it. I am not Google and cost of trying to break my software…

How much do you think it costs?

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

#137

Post by perl4ever »

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…

I started out writing programs for the Mac in Pascal and believe me you, it was possible to crash the machine.

I think people get hung up on the theoretical capabilities of "pure" Pascal but the forms that people actually used had all sorts of extensions. Back in the day, whether you were using Pascal or C or whatever, it probably wasn't very standards-compliant anyway.

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

#138

Post by danielbarla »

jonnypotty wrote: post #114
danielbarla wrote: post #102

Earlier quoted context omitted.

I'm not sure I 100% understand your question, and it's also hard to respond without more context. Many Delphi apps back in those days were very lazily slapped together, with thin layers of code (or none) on top of whatever queries got the job done. There are performance issues, security issues, correctness issues (in terms of: does the app allow you to do some things that should not be allowed). There are also meta-l…

I guess I don't buy the idea that anything has changed. If a straight query shows you the data you need why would you put anything else but a thin layer of software over the top? More software is worse, not better. Apps are still lazily created by people downloading frameworks and plugging them into whatever shit they happen to be creating at the time. The issues you state. Security, correctness and performance. None…

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 *" example, this was quite often literally the case - queries were not optimised in the least bit regarding the columns and rows that were being retrieved (mostly due to lack of awareness or laziness). In terms of correctness, you can bet that business rules were usually sprinkled around the UI in a happenstance kind of way, rather than being collected in a relatively well defined, easy to verify and unit test business object, say. Again, while I do agree in theory that "more code" does not necessarily solve anything, these are the kinds of practicalities I am arguing about, not on a pure level. The tooling was great for getting things done instantly, but encouraged a laziness that caused a counter revolution which went too far in the opposite direction.

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

#139

Post by thePunisher »

monocasa wrote: post #125
thePunisher wrote: post #115

Earlier quoted context omitted.

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.

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.

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

#140

Post by jonnypotty »

danielbarla wrote: post #138
jonnypotty wrote: post #114

Earlier quoted context omitted.

I guess I don't buy the idea that anything has changed. If a straight query shows you the data you need why would you put anything else but a thin layer of software over the top? More software is worse, not better. Apps are still lazily created by people downloading frameworks and plugging them into whatever shit they happen to be creating at the time. The issues you state. Security, correctness and performance. None…

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.
Post reply on HN