[link|/forums/render/user?username=ToddBlanchard|ToddBlanchard] writes:

[My Delphi Experience] Is admittedly limited to having an office mate who was gaga for it and gave me several forced demos.

Heh, yeah... We're like that. :-)

But, hey, OTOH -- doesn't that tell you something about it, that it can, uh, "generate" zealotry like that? (Here's hoping that was an otherwise likeable and clued-up office mate, so this comment won't put you off investigating it even more... Or, failing this, that you somehow think *I* am. :-)

At the superficial level it sure seemed like a 4GL kind of thing that generated code.

I could be wrong.

Well, "yes and no"; or, "that depends"... Depending on what you mean by "generate[d] code", it could be that you're more right than wrong, or vice versa.

It *certainly* doesn't run off and "generate" reams and reams of code behind your back, like the "ATX-macro"-infested bloateroon M$ "Visual" [Hah!] C++ did on the few occasions I had to try it.

Sure, if you double-click an event slot in the "Object Inspector" (the design-time property editor), it creates a procedure skeleton:

Procedure Button1Click(Sender: TObject);
begin

end;

in the code editor, and takes you to it -- but that's all. (And if you click the wrong slot by mistake -- that can happen, apparently not too infrequently, since they built this in -- just leave it empty, and the IDE removes the empty skeleton for you.) That's not too much, is it?

And if you create or open a form in the IDE, and drop a bunch of components on it[*], then it saves a form definition file that lists all the components on the form, and the values of their properties. (But, given what you say below, that *can't* be too much! :-)

([*]: Yes, both visual and non-visual components; there's even a non-visual type of form, to hold *only* non-visual components -- it's called a DataModule, so guess what it's mainly used for. :-)

Also, I have a little experience with Object Pascal from MacApp days. Its still an "emulated" OO language in the spirit of C++ and Java rather than a dynamic one in the spirit of Smalltalk and ObjectiveC.

Well, that's basically (as almost everything is, once you boil it down enough) a question of semantics -- how to define "OO language"?

Personally, I'm a bit put off by your apparent implication that strongly-typed languages are somehow inferior or "less OO" (cf "emulated", above) than loosely-(or dynamically-)typed ones. Where in the Bible does it say that those things necessarily have anything to do with each other?

Which means I don't much care for it on a conceptual level.

Hmph, yeah, well... What am I supposed to say to that? What you're saying is basically, "My mind is made up, because my mind is made up" -- sounds rather Tablizer, actually... The only reply that comes to mind is, "Your loss".

My third bias against it is that it runs on PCs - something I've never cared to work on. Unix servers are pretty much the only place I ply my trade.

Yeah, well, again with the definitions: So what does "Unix servers" mean?

I've heard Delphi now works on Linux?

Yup -- it's called "[link|http://www.borland.com/kylix/|Kylix]"; the Delphi-language version of [link|http://www.borland.com/kylix/professional/|Kylix Professional] comes with [link|http://www.borland.com/delphi/delphi_professional/|Delphi Professional] (and the same goes for the Enterprise editions of both, I gather). The "Open Edition" (you can distribute GPLed apps only) of Kylix is available for [link|http://www.borland.com/products/downloads/download_kylix.html|free download], though.

[link|http://www.borland.com/delphi/|Delphi 7] "[link|http://www.borland.com/delphi/delphi_personal/|Personal Edition]", for Windows, OTOH, costs money; US$99.- or so, I gather -- and you don't get to distribute apps commercially! But hey, if you think you'll *ever* come near a Windows PC to try it out on, couldn't you sacrifice just ~16 Euro [you're still in Paris, right?] to try it out? If so, just buy [link|http://www.pcplus.co.uk/magazine/default.asp?pagetypeid=2&articleid=10451&subsectionid=392|issue 196] (December 2002) of British [link|http://www.pcplus.co.uk/|PC Plus] magazine; it has D7Personal on the cover [link|http://www.pcplus.co.uk/magazine/default.asp?subsectionid=393&subsubsectionid=0&pagetypeid=2&articleid=10452|CD]/[link|http://www.pcplus.co.uk/magazine/default.asp?subsectionid=394&subsubsectionid=0&pagetypeid=2&articleid=10453|DVD]!)

But that would reqire me to buy a PC and I have no use for PCs. I'm quite happy with OSX.

Oh, so you have a Mac? You know you *can* actually run Linux on that? Not that it'd help, though -- the Kylix compiler only generates x86 binaries. :-/

Cobalt / Intel / BSD "Unix Servers", though... Are they "Unix Server" enough for you, or do you insist on calling everything you don't want to know about "PCs"?

Why I think Cocoa is the coolest thing:

The NextStep UI Builder (called InterfaceBuilder or IB) is radical in what it does. You actually visually assemble objects together - they don't have to be UI objects either.

Uuh... You aren't talking about that "Visual Programming" fad from the late eighties, I take it -- where you were supposed to *literally* "visually assemble" objects, by drawing lines from one thingy's doodad-output knob to another doohickey's doodad-input slot, and so on? Because that, as I gathered at the time, only served to mess up your IDE with a literally *visual* expression of the term "spaghetti code"...

In Delphi, if you had, say, a TDoohickey component that takes a TThingy component's output as its input (or vice versa), the TDoohickey would have a Thingy property that you set to point to the TThingy (or Doohickey, if it's the other way around) you want, usually by just selecting it from a drop-down list in the Object Inspector with your Doohickey (or Thingy, if it's that way around) selected on the Form. These mutual pointing-to relationships are what constitutes the "assembling" -- is that visual enough for you, or should we call it "semi-visual"? :-)

Once you create an assembly (this thingy connects to that doodad via this property and sends this message on getting this event....) it *serializes* the set of objects into a file (called a nib file for the extension used). Usually this is a window with widgets and your home-made controller class and maybe some model objects. Doesn't have to be though.

Muahahahaa!!!

And what do you think Delphi (and C++ Builder, and Kylix) does, then?!? :-)

Except Delphi isn't MVC-based; the TForm-descendant class you build is kind of a "View and Controller rolled into one", I suppose(?). Also, Delphi components don't "send[s] this message on getting this event", they "execute an event-handler procedure" in stead. Yes, events are single-cast in Delphi. (Your "message sending" means they can be multi-cast in InterfaceBuilder/Cocoa, I assume?) And Delphi's files are called [whatever].DFM, for "Delphi ForM", instead of .NIB.

So when you want a new instance of that window (or other kind of assembly), you reinflate the nib again. The nib acts as a sort of template.

Heheheh... You do exactly the same thing in Delphi, only the terminology is different: We'd call it "creating a new instance of your form". :-)

This means you don't subclass nearly as much in Cocoa programming (hardly ever actually).

in Delphi, you usually build just one sub-class per form, the window object class itself. (And the IDE makes this so transparent that many [most?] users probably aren't even aware that that is what they're doing -- for good or bad...)

Instead, you just assemble stuff.

Precisely!

I suppose Delphi owes quite a lot to to NextStep and InterfaceBuilder... Hey, you think it's a coincidence that the original name they considered (still visible in the "Window Class" name of the IDE itself, on Windows) was "AppBuilder"? :-)

But then it also owes a lot to -- Ouch! This hurts, but I gotta say it: -- Visual Basic. Only, Delphi got it *right*, OO-wise and component-wise. One way to describe Delphi would be, I dare suggest, "NextStep/IB/Cocoa underneath, looking like Visual Basic on top".

OK, so the parallell to NextStep/IB/Cocoa isn't exact, given the different typing and object models; but the more I hear about it, the closer it sounds.

(And, uhm, I'm not quite sure on the time-line here -- but, does perhaps even NextStep/IB/Cocoa owe some small debt to VB... Or is it the other way around? :-)

This is kind of what Java beans wanted to do with its serialization and stuff, but Sun messed it up and the implementors couldn't get their head around real serialization so they all punted and did code generation.

Exactly... Only, the creators of Delphi *didn't* punt or mess up; they didn't have to, 'coz they *did* "get their head around real serialization" (AFAICT).

I also think they sort of had to because of Java's static binding nature.

Apparently not for *that* reason (at least not that alone), since Delphi is "statically-bound" (? Assuming this means what I'd call statically-typed) too, and still manages to get it right.


Scott -- buglet?:

<blockquote type="cite">None</blockquote>

Can't see that "None" in Todd's post.

Created as new thread #59420 titled [link|/forums/render/content/show?contentid=59420|Oh yeah, sorry...]

Created as new thread #61815 titled [link|/forums/render/content/show?contentid=61815|You were supposed to.]