Live data from Hacker News

Why I Choose Delphi

csvelocity.wordpress.com

261–270 of 307 posts

Re: Why I Choose Delphi

#261

I did an awful of Delphi in the nineties, but the closed nature and the lack of portability failed to keep me interested in the long run. Lazarus/Free Pascal, for some reason, has never really managed to ignite any passion, and it's not because I haven't tried. Except for the lack of IDE/RAD, a worthy present successor is Nim. There really is no end to the potential of this clear, cool, concise, modern, fast, and ele…

I still make heavy use of Delphi - a superb tool for fat client apps, but I have to agree on Nim. The potential is enormous and I'll be using it increasingly in the future.

Re: Why I Choose Delphi

#262
post #254

Earlier quoted context omitted.

Yes, to prove, get any crack exe and run pexplore on it. Very likely you will see some Delphi dfm or list of units compiled into the constant area.

I think I misunderstood - I thought you meant there was a way to ship slim c# exe files.

oh no, I wouldn't even dare try that.

Re: Why I Choose Delphi

#263
post #227

Earlier quoted context omitted.

The main platform's menu is written in Delphi. The tools to package apps (both the AppNamePortable.exe launcher and the installer they are then packaged in) are written using NSIS. Developers packaging most apps can do so just by filling in INI files without writing a single line of code. The utilities include NSIS itself, auto-generate the code needed for the installers and launchers, and automatically compile them.

Have you evaluated any other languages apart from Pascal/Lazarus? If Windows XP+ support is the driving feature and you would consider a modern language then please take a look at Nim[1], it features some Delphi/Pascal-isms so you and your team may find it familiar. I'm happy to answer any questions you may have about it. 1 - https://nim-lang.org/

One of the main reasons we settled on Delphi originally is that it was a relatively easy to learn RAD setup for GUI apps with a solid IDE to work in. Nim seems to be command-line, kernel, and server-focused.

Re: Why I Choose Delphi

#264

Earlier quoted context omitted.

Web is much more advanced (and complex), and that's why you can't just drag and drop. Or can you? Remember Wix.

Do you really know how complex Win32 GUI is on low level? Yet Delphi manages it nicely and wraps it up into handy abstractions.

I don't really know anything on low level.

But I've never seen any layout render engine with the same feature set as modern HTML/CSS engines.

Re: Why I Choose Delphi

#265
post #17

Earlier quoted context omitted.

You'll also have a smaller pool of candidates you can hire, no?

If you hire by checklist then yes. Otherwise, I would expect any competent programmer to be able to grasp Delphi.

Do all competent programmers check the 'Delphi' job postings?

Re: Why I Choose Delphi

#266
post #179
post #63

Earlier quoted context omitted.

dBase-derived languages in general were a lot of fun. And incredibly productive, basically taylor-made for cranking out CRUD apps. I do ponder sometimes why we don't have something quite like that these days. Oh, people do try, but it's never that simple, and there are always a lot of moving bits with plenty of friction between them. The ease with which I could collect a bunch of data from a form and shove it into a…

I totally agree. I'm pondering about build a Fox-in-spirit. I still mantain that NO programming tool today is good for database-development, and we need a modern take on the dbase. My idea is build a relational language with a lot of the ideas of fox but with a modern syntax. If somebody wanna to talk about this, and maybe help, I'm open!

Judging by the all comments and the upvotes in this thread, it looks like it's a more popular sentiment than I expected - so, sure? But this is probably best discussed in a setting more convenient than HN comments.

Re: Why I Choose Delphi

#267
post #223
post #63

Earlier quoted context omitted.

dBase-derived languages in general were a lot of fun. And incredibly productive, basically taylor-made for cranking out CRUD apps. I do ponder sometimes why we don't have something quite like that these days. Oh, people do try, but it's never that simple, and there are always a lot of moving bits with plenty of friction between them. The ease with which I could collect a bunch of data from a form and shove it into a…

>dBase-derived languages in general were a lot of fun. And incredibly productive, basically taylor-made for cranking out CRUD apps. Yes, true. I did a good amount of XBASE (which is the generic term for dBASE, Foxpro, Clipper, etc., and I worked on all 3 of those) in my early programming days (along with Turbo Pascal and Turbo C) - including a very interesting line-of-business app for a switchgear manufacturer's fact…

I know that Harbour is a re-implementation of Clipper with some added features, but not much else.

I think it's less about the DBF file format and xBase syntax, and more about the high-level conceptual approach, with the language built around concepts like database cursors and mapping data (rather than relegating it all to a library). If this stuff is to be redesigned from scratch in a modern environment, it would have to deal with contemporary data sources - meaning SQL RDBMS - and the syntax could definitely be more consistent and less crufty.

Re: Why I Choose Delphi

#268

Earlier quoted context omitted.

Smalltalk was able to do #1 in the 70s without static types.

I'm not familiar enough with Smalltalk to comment, but I'm guessing that it had a formal, discoverable system of hooking events to event handlers. Was that the case ?

There is no "formal" system for events, but there are patterns and most Smalltalk systems follow. For example, Pharo makes use of an object called `Announcer`, which you then subclass to make your own announcements. It works similarly to a pub/sub pattern, but using pure live objects and by sending specific messages to subscribers.

Previously, systems like Squeak used a pattern where objects had a collection of "dependents" that would be updated when sent the `changed` message. I think this is still how input events -- keys, mouse, etc -- work in Morphic.

In either case, the "handler" is whatever you want it to be, so long as the target object implements the appropriate message.

As for discoverable, I'd say most things in a Smalltalk are easily discoverable, though some of the patterns can get convoluted if you're inheriting an ancient object structure.

Re: Why I Choose Delphi

#269
post #63

Earlier quoted context omitted.

dBase-derived languages in general were a lot of fun. And incredibly productive, basically taylor-made for cranking out CRUD apps. I do ponder sometimes why we don't have something quite like that these days. Oh, people do try, but it's never that simple, and there are always a lot of moving bits with plenty of friction between them. The ease with which I could collect a bunch of data from a form and shove it into a…

I don't, but I'd like to. Most of the online documentation on Foxpro is old, and doesn't convey the magic that I've seen happen with it. I'd love to see some combination of Delphi with Foxpro, probably with LISP syntax and Qt bindings. And a little bit of sugar from haskell and kona languages. What made Turbo Pascal great was the help system. For every single standard library function, it had a snippet of code that y…

FoxPro also had a great help system, including context help with F1 for whatever was under the cursor. It wasn't quite as good as TP, because it didn't have true hyperlinked text - but it had a separate section in each article just for links ("See Also"), and it had very fast keyword search, so it was "good enough" in practice. And yes, also tons of examples!

Re: Why I Choose Delphi

#270

Earlier quoted context omitted.

Dead like Hypercard?

I'm really surprised Apple hasn't come up with something in this space, not everyone is a programmer but most people have things they could do with automating a little.

Apple is lead by the logistics expert of the old Apple and the CFO. Let's put it this way : they are less likely than before to produce new products.
Post reply on HN