Why I Choose Delphi • Hacker News Board

Re: Why I Choose Delphi

#281

Post by i_don_t_know » Wed, Aug 02, 2017, 12:33 PM UTC

Fischgericht wrote: post #241

We also use Object Pascal extensively. We do high-level stuff (Win32, Android, iOS) but also really hardcore low-level embedded stuff. We use - Delphi 7 - Delphi 10.2 - CrossKylix ( http://crosskylix.untergrund.net ) - CrossFPC ( http://www.crossfpc.com ) And are able to compile native code to a gigantic amount of platforms, all from within a single IDE. Web stuff we also do, with ExtJS as a front-end. If anyone is l…

I'm not looking for an ObjectPascal job (because I have zero experience with it and I'm quite happy in my current position). But I'm still curious about what you do.

How do you build for iOS, for example? I thought you had to use Xcode.

How do you convince clients that ObjectPascal is the right solution? That is, are client concerned that you're not using Java/ C#/ C++? I've always thought Germany was fairly conservative in this respect.

Re: Why I Choose Delphi

#282

Post by unclebucknasty » Wed, Aug 02, 2017, 12:53 PM UTC

computerex wrote: post #260

unclebucknasty wrote: post #209

Earlier quoted context omitted.

> A GUI web site generator is trivial and many already exist. > older desktop based technologies like WinForms are more geared towards purely functional experiences. The web can go above and beyond providing merely functional experiences. Not talking about web sites here, but web apps, which in the modern sense are much more aligned with desktop apps than websites of old.

I meant web apps. Modern web apps offer a lot of freedom in constructing the precise experience we want the user to get. This is unlike traditional desktop applications with the cookie cutter controls that behave the same way from app to app.

That's not been my observation when it comes to SPAs, responsive apps, etc. They tend to use fairly straightforward components, layout schemes, etc. For instance, if you look at the components/layout capabilities that come baked into the latest version of Bootstrap, you'll find a lot of bases covered.

Regardless, there's nothing that precludes you from wrapping any control you desire into an interface that makes it droppable and configurable through a GUI editor, then have it generate code. Likewise, for the creation of different layout managers, though in practice I don't think you'd find a ton of variability there. Most "experiences" boil down to grid-based and responsive.

So, I'm not sure which precise experiences you imagine couldn't be created. It's all just code. But, if there are some, then they'd be the exception, not the rule.

Re: Why I Choose Delphi

#283

Post by TimJYoung » Wed, Aug 02, 2017, 1:16 PM UTC

scroot wrote: post #268

TimJYoung wrote: post #256

Earlier quoted context omitted.

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 "depe…

Thanks, very interesting. I think a lot of the confusion here is over my terminology and a general lack of understanding about what the Delphi IDE is actually doing.

By "discoverable", I mean can the IDE:

1) Compile/analyze the code in the component library/run-time,

2) Figure out which type of method can be used for a certain type of event property for a given class, and

3) Display all matching methods in the current unit/module for the user to select.

This is what Delphi does (and Visual Studio with WinForms), and all of it is done at design-time, meaning that your application is not getting compiled in order to determine any of this.

From what you're describing, I don't think Smalltalk is doing the same thing. However, it could be doing something similar if it enforces (at design-time) this part:

"so long as the target object implements the appropriate message"

Re: Why I Choose Delphi

#284

Post by jcelerier » Wed, Aug 02, 2017, 1:17 PM UTC

mamcx wrote: post #219

jcelerier wrote: post #215

Earlier quoted context omitted.

The recent Qt Quick designer is miles ahead of what Delphi provides: http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creat...

That is hard to believe. I test QT a few months ago (osx) and the toolset is the same joke as any other C++ toolset. Powerfull in the inside if you pray to the proper gods. Have you use Delphi?

> Have you use Delphi?

yes, though I have to admit the last version I did use was Delphi 7. What did you find lacking from Qt ?

Re: Why I Choose Delphi

#285

Post by TimJYoung » Wed, Aug 02, 2017, 1:33 PM UTC

theamk wrote: post #250

Clubber wrote: post #240

Earlier quoted context omitted.

Correct. It compiles to binaries without any runtime environment, so you have to manage memory. Apple did something with objective-c (forgot what it was called) that automatically frees your memory based on your code, but it actually inserts the free memory calls. That's the only language that does that AFAIK. Very clever though, memory management can be a pain if you aren't used to it. The good thing about managing…

I know the disadvantages of GC; what I am asking about is "smart pointer", like C++'s std::shared_ptr, or Rust's Rc. It is used like this: In the class definition: std::shared_ptr big_struct; In the constructor (or anywhere else in the program): big_struct = std:::make_shared (arg1, arg2) and that's it. When there are no more users of the pointer (for example, when the container object disappears), it will get destro…

You can use interfaces as class wrappers if you want referenced-counted class instances in Delphi. All arrays and strings are automatically reference-counted, and records (structs) are values that can be passed around without allocating memory (Delphi supports variable parameters, or pass-by-reference, but without requiring pointers or address-of notation).

As a Delphi application developer, you will most likely not be manually allocating/freeing memory a lot. Delphi's visual component library has a component ownership model. For example, any components/controls that you drop on a form are automatically "owned" by the form and are created/destroyed for you.

Re: Why I Choose Delphi

#286

Post by TimJYoung » Wed, Aug 02, 2017, 1:53 PM UTC

dvfjsdhgfv wrote: post #245

TimJYoung wrote: post #152

Earlier quoted context omitted.

You're not going to be able to do it, at least not in the same way as Delphi. Go lacks the complete OO and component functionality that allows Delphi to provide its level of integration between the IDE and the code/components. It's not just a language that was popped into an IDE, rather the IDE and the language were created to work together as one, and it all revolves around proper class support/RTTI. Chuck Jazdzewsk…

OO in Go is quite peculiar, but not impossible. I'd even say you could quite naturally code methods and properties of components, while events would have to be a part of this particular implementation. In any case, I completely agree: whoever decides to do it, they'll have to take Go's peculiarities into account and instead of making an exact copy of Delphi in Go, create a new project leveraging the specific features…

Yeah, my comment came off a little harsh. I'm not discouraging someone from creating a Go IDE like Delphi, I'm just saying that one should be prepared to make allowances for what the language can/cannot do, given that one cannot change the language. The original Delphi team had the enviable position of being able to modify the language to suit the IDE, and vice-versa.

Re: Why I Choose Delphi

#287

Post by scroot » Wed, Aug 02, 2017, 2:48 PM UTC

TimJYoung wrote: post #283

scroot wrote: post #268

Earlier quoted context omitted.

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 "depe…

Thanks, very interesting. I think a lot of the confusion here is over my terminology and a general lack of understanding about what the Delphi IDE is actually doing. By "discoverable", I mean can the IDE: 1) Compile/analyze the code in the component library/run-time, 2) Figure out which type of method can be used for a certain type of event property for a given class, and 3) Display all matching methods in the curren…

You should play around with Pharo if you have some free time. It's a completely different way of doing things (and a lot of fun). Indeed, what you've described of Delphi is not happening in a Smalltalk: there's no difference between the thing you are programming inside of and the end product (at least not right away).

It's easier to think of a Smalltalk image as a live system that you are configuring (using Smalltalk itself) for some end-user or goal. Because a Smalltalk image is simply a snapshot of the state of the whole system, you can use a development image to generate a more bare-bones, customer image/application if you so choose. In other words, you can configure a Smalltalk image however you want for a client. This would be the equivalent of the kind of "compiling" that creates a usable end product. You are manipulating a live system and configuring it for some purpose rather than describing a system in text files, compiling it, and then giving it to people to use.

On a technical level, you are compiling all of the time when working in a Smalltalk. Every time you save, the changes recompile and execute, live, as instantly as these things can.

Of course this means that Smalltalk is highly self-aware, and therefore there can be / are some of the IDE features you've listed. One of my favorites is the ability to provide example inputs and example outputs and see recommended objects/messages and implement the method for doing it. It probably exists in other Java IDEs or something, but I've never seen it elsewhere myself.

Re: Why I Choose Delphi

#288

Post by vram22 » Wed, Aug 02, 2017, 5:29 PM UTC

int_19h wrote: post #267

vram22 wrote: post #223

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

I think you're right on that. Having the database-related features built-in to the language makes a difference. A bit like how REBOL has many data types built-in (~45, IIRC [1]). And if not now, I guess over time, Red will have them too.

[1] https://en.wikibooks.org/wiki/REBOL_Programming/Language_Fea...

Re: Why I Choose Delphi

#289

Post by TimJYoung » Wed, Aug 02, 2017, 5:55 PM UTC

scroot wrote: post #287

TimJYoung wrote: post #283

Earlier quoted context omitted.

Thanks, very interesting. I think a lot of the confusion here is over my terminology and a general lack of understanding about what the Delphi IDE is actually doing. By "discoverable", I mean can the IDE: 1) Compile/analyze the code in the component library/run-time, 2) Figure out which type of method can be used for a certain type of event property for a given class, and 3) Display all matching methods in the curren…

You should play around with Pharo if you have some free time. It's a completely different way of doing things (and a lot of fun). Indeed, what you've described of Delphi is not happening in a Smalltalk: there's no difference between the thing you are programming inside of and the end product (at least not right away). It's easier to think of a Smalltalk image as a live system that you are configuring (using Smalltalk…

Thanks again for the detailed reply.

I will definitely try Pharo and see how it all works. I've read a bit here and there about Smalltalk over the years, and the whole environment seems really cool. I'm especially interested in the whole "not requiring static types", because that may give some ideas on how to do a JS IDE without losing the functionality that we wish to maintain. The "liveness" of the Smalltalk environment is also very much in line with how JS/HTML are used, so there may be a natural fit there.

Re: Why I Choose Delphi

#290

Post by frik » Wed, Aug 02, 2017, 6:47 PM UTC

WorldMaker wrote: post #259

frik wrote: post #242

Earlier quoted context omitted.

Delphi and VB4-6 used to be the RAD tools. (RAD = rapid application developed) One could drag and drop controls and create an GUI application in WYSIWYG-style. Then in 1999 when Microsoft abdomen VB for their new dotNet vision, MSFT was about to be split up, etc Web took over and Dreamweaver (and Frontpage) offered a similar IDE experience for HTML4 with a tables and PHP (or ASP, etc). To this day VB6 has the easiest…

You don't use the Start Menu in Windows 10 or the Settings application or the calculator or the WiFi menu or the Action Center or ...? UWP apps are more ubiquitous than you think they are in Windows 10. Zero times visited the Windows Store to directly install apps? Sure, that's possible. Actually using Zero UWP apps? Increasingly unlikely. UWP isn't a failed experiment by most measures, and you may not directly notic…

I have tried Win10, but all these new UWP based parts tacked on Win7 shell are so laggy. I mean click on start button, it takes several noticeable milliseconds to show up, the same for the windows clock pop up (calendar), etc. even the calc has now a loading screen and animation. And even though these UWP parts like the start menu are coded in C++ for the UWP API, they are like 100 times slower than the old C++ WinAPI based applications. I know, I had a discussion with the MSFT startmenu devs over here on HN in a thread several months ago - it's a lot less responsive than what could be done with a WebView control and HTML and CSS yet it's even solver than both a webview and a native C++ WinAPI implementation - sucks. I stay with Win7, which is superb and doesn't suck.