Talk:Delphi programming language

This redirect was nominated at Wikipedia:Redirects for discussion on 10 September 2021. The result of the discussion was retarget.

At the disadvantages topic there is stated that delphi only supports interface polymorphism. This is SO untrue! Delphi, in fact, was one of the first object oriented languages with a visual form designer available for windows... i'm talking early 90's here!... I won't edit the article myself, since i'm not a wikipedia contributer. —This unsigned comment was added by 193.244.32.140 (talk • contribs) .

What has the form designer to do with how the language support for polymorphism? That doesn't make sense to me. AFAICS the statement is correct, especially when contrasted with dynamic languages. --Craig Stuntz 14:30, 16 March 2006 (UTC)Reply

---

I removed, "The class helpers concept was implemented by Chuck (Charles) Jazdzewski (who went on to Microsoft to work on XAML) and implemented in C# 3.0 as extension methods." for a couple reasons. First, although I appreciate the call-out, pointing out that I implemented them has no real value. Second, C# 3.0 proposed extension methods, although similar in concept, are much different than class helpers. Chuck Jazdzewski

---

I reacted to this: "the successor, C#, to one of today's most popular programming languages, C++." Very NPOV. What concensus is there on C# being the "successor" of C++? C# is a commercial project that appropriated the C prefix and cleverly added two more pluses ("++" --> "#") but that does not make it the "successor" to C++ more than the D language is. -- Mikademus

---

Afaik Delphi isn't even a programming language, it's the name of a Borland programming tool in which you use Object Pascal to program. In that case, the article title would be incorrect. And further... Why am I getting the impression that this text was ripped out of some advertizement broschure for Deplhi?

Untill last year the langauge was called Object Pascal and the IDE / product was called Delphi. Since Borland was making significant improvements on the langauge, yet again, to support .NET as well as other changes the changed the name to the Delphi langauge. This should probably be two different articles, one on Delphi Studio (the new name of the IDE product) and the other on the Delphi programming langauge. I didn't write the original article (I don't think), but AFAIK this is not based even loosly on any Borland adverts. I think that if the article were split in two then it would read better since one would be about a product while the other would focus on the langauge itself. The "features" and "selling points" could be isolated to the product article while the technical aspects could be in the language one. -- Jim

In that case, shouldn't "formally known as Object Pascal" be "formerly known as Object Pascal"? By the way, many of the (POV) "remarkable features" of Delphi sound like features that appeared in other languages long ago, in one form or another. (e.g. transparent getters/setters were in CLU 10 years ago). (With some of the features, I can't tell exactly what they mean; e.g. how does a "type safe method pointer" differ from an ordinary type-checked function or method pointer?) —Steven G. Johnson

You are correct on the formerly part. I fixed that. Feel free to NPOV the article any if you feel it is too POV. I don't have much emotional attachment to it. -- Jim 01:00, 7 Oct 2003 (UTC)

I made an attempt to NPOV it. What it could really use is a list of disadvantages. BTW, I removed "Support for latest technology and standards" from the advantages list, because it seems like a bit of an empty claim. Which new technologies and standards are supported? -- ComaVN 21:37, 16 Mar 2004 (UTC)

AFAIK the name change Object Pascal -> Delphi already predates the .NET extensions in D7. It's a sideeffect of a renewed focus (at least on PR level) on Delphi after the namechange from Inprise back to Borland. Marco van de Voort.

Slight correction: The name change was regarding the company's name, changing from the original Borland to Inprise, and then subsequently back to Borland. -- Stevietheman 19:03, 16 Jul 2004 (UTC)

Delphi's/Object Pascal's main adversary is C/C++. Most claims (the type safe proc-pointer) must be seen in that light. Personally, I think the outdated library design (even though the VCL is quite cool) are a bigger problem than the language. E.g. the possibilties of interfaces were never exploited in newer versions of the VCL Marco van de Voort

I also don't like the .NET angle that has been added. Delphi and Delphi.NET are quite different, since only basic GUI and db operation can be .NETized easily (due to pointer and win32 use), and even for that, the VCL.NET framework is probably only temporarily supported for legacy reasons. All normal pascal code must be rewritten, and 3rd party components structurally updated for .NET. Maybe a split in a Delphi and Delphi.NET page (that reference eachother) is wise. Marco van de Voort

Wasn't there also an Apple dialect of Pascal called Object Pascal, with different extensions than Borland's version? Does anyone know enough about this to comment?

Yes, it was even formalised into an Object Pascal standards draft. Borland based on this draft for Delphi (though it kept _some_ compability with the old TP objects too). So Delphi is more or less a Borlandified version of that Apple dialect (I have Think Pascal manuals, and the dialect for objects is the same) Marco van de Voort

What does it mean when it says "Not a top-tier language" in the disavantages? That should be explicit in the article. The first thing I thought was that it wasn't suitable for b2b, but the enterprise and architect versions are mostly directed twards that. If it means the language is not a formal standard, the line saying "Partial vendor lock-in" is enough to describe that.

In the list of cons, the article says "Access to platform and third party libraries require header files to be translated to Pascal." Personally, I fail to see how this is a disadvantage. If I write a useful library in Pascal, then C programmers would have to create headers for it, so why isn't that in a list of C/C++ disadvantages? I just think that there is probably a better way to say this without saying what amounts to, "Delphi sucks because it's not compatible with C" (which IMO, is the best feature any programming language can have). I hope you guys, who are experienced with editing Wikipedia, can come up with an appropriate wording.

"Delphi 2005 (brand name for Delphi 9) provides both win32 and .NET code generation (...)" - win32 needs to be substituted with a phrase that has a clearer meaning. Silver hr 03:45, 21 Jun 2005 (UTC)

Should these topics be separated? There's an article about Pascal, but it doesn't discuss extensions made by Borland (object-orientation).

• Object orientation is not just a Delphi extension. TP has it too. Several other dialects too. There even was a O-Pascal draft standard. (IIRC proposed by Apple). Also the language is quite changed going through (soon 9) versions.
• I think separating the lemma into .NET and native is better. These are quite incompatible to the point that they are actually separate (but related) products. D.NET breaks code that worked since TP3, and even on non Borland Pascals

-- Marco van de Voort.

And I really hate to see Delphi categorized as .NET language. It isn't, not even close. Common code doesn't compile under .NET, only thoroughly .NETified or trivial code does. ... And strangely enough it is not categorized as object oriented. If C++ is OOP, so is Delphi. Marco van de Voort

I removed the garbage collection notes because nearly every lined contained a flaw, amongst others:

• Garbage collection does not require a VM/bytecode concept, even if .NET and Java do so. So it being dependant on the platform is incorrect. According to the standard, even C++ can be fitted with GC, and still be standards compliant.
• Languages _are_ affected by what they run on, due to what they specify over pointers, timeframe of destructor execution etc. Plain Delphi has pointers, they had to be pruned to make a .NET language variation.
• Moreover Java can be compiled and be Java VM less.

Or in general: the paragraph was about how Java/.NET do it, not about GC an sich. And notes about Java/.NET CLR explanation doesn't belong here, see their respective pages for that. Marco van de Voort

I added the section on GC as I thought it not fair to flag up a language as deficient for not having garbage collection. Hence the reference to C# and Java both of which use the platform and not the language to achieve GC. In other words although there are languages which compile with GC built in, you would not normally expect a compiled (as opposed to interpreted) language to handle garbage collection. The very nature of GC is something you DON'T have to do. When C++ is fitted with GC it is done by providing replacement memory allocators, and either the source code that implements the GC or links to binaries that implement it. In both cases the C++ language is not changed and is not providing the benefit. The same GC tools can be plugged into delphi on win32, so in this case has the language been adapted to get GC? The language in all these examples is not providing the benefit.

.. Yes, I agree GC is not a deficient. (I changed it from a disadvantage to the current text that opinions vary). A lot of beginners simply can't program without GC. (Zomg!! :)) )

• Native Delphi is compiled and does GC on interfaces, dynamic arrays and strings. Again, just because Java does it this way, doesn't mean that is a key aspect of GC, and C# is a mere Java clone.
• JIT is not equal to interpreted.
• You seem to confuse the generic term garbage collection with a Boehm style garbage collector. Reference counting is GC too (see point one), and has an advantage, since it plays nice with native code.
• Moreover, there still is a benefit, also for C++. The purpose of GC doesn't necessarily have to be about totally automatic memory management, even though the token GC languages do it that way. It can be e.g. about avoiding memleaks in server applications that must have long uptimes etc.

Marco van de Voort

Ok Removed section on garbarge collection. Reference counting is not GC. GC as implemented in most platforms requires replacement Mem Alloc and De-Alloc routines which can easily be used by dephi as shown in Delphi's use of GC in the .NET version and the ability to use WIN32 replacement Memory Managers which will give you GC on all memory not just strings and interfaces.

A simple question If GC should be considered part of the language, then what is the construct or call you make to free the memory automatically?

Also removed the comments on Top Tier language Delphi is considered a Main stream language. Source: Programming Community Index Also added some real issues with Delphi so you do not think I am a delphi zealot

---

Ref counting is GC. There are no such requirements. Not everything GC is abotu OOP/.NET/JVM. However in this case your definition is easier to understand I think without integrating a complete GC chapter. And GC is not easily used in Delphi. For Delphi.NET so many mods are necessary to support GC that I regard Delphi.NET as a separate product line from Delphi. (so D8 or D2005 compiling for .NET). I already stated this before. IMHO BCB is closer to Delphi than Delphi.NET

GC "part of the language" is hard. Delphi does GC as part of the language for strings and interfaces (ref counting). Just not for everything. And there is no fixed way. Some types of GC (like ref counting) call something on exit-of-scope. Some (like Boehm style) call it regularly in a separate thread or in code. With a lot of Boehm style collectors one can often forcedly call the GC to force it to clean too.

The Top Tier part is hard. Your own "issues" you added confirm that, since they are pretty much in the same category. Microsoft Visual C++ and VB6 are then the only really Top Tier ones, since they are the only ones for which you can find an example for nearly every aspect of windows. Such code will typically not compile with a different C++ compiler.

However I agree Delphi is at least partially top tier, the existance of a large commercial components market makes it more top tier than most other platforms (VB and VC++ excluded). In that light I agree with your decision to remove the remark

Note that I give a lot of comments, but didn't change anything, I agree with the changes :) Marco van de Voort

I disagree on the "cons" of the delphi language, its says:

1. Partial single vendor lock-in (Borland alone can set the language standard, the compatibles have to follow).

Lock-in? with GPC? Free pascal? i don think so.

2. Limited cross-platform capability for Delphi itself. Compatibles provide more architecture/OS combinations.

Well, yes, but you got kylix for that, and it comes with delphi.

3. Access to platform and third party libraries require header files to be translated to Pascal.

Yes, well, there are tool that do this automatically.

4. Documentation of platforms and techniques hard to find in Pascal language (e.g., access to COM and WIN32).

This is bullshit, you ever have written a COM object in Delphi? is much more easy and elegant than C++.

You can call any win32 api transparently with Delphi.

-- Alfredo Ortega

(Alfredo: I numbered your points to make it easier to reply to, hope you don't mind)

1. GPC is not even Delphi compat, anyway, both fall under the compatibles. Do you really think if FPC implements an extension, that Borland will follow it and remain compatible with FPC?

2. If I try to look at it as positive as possible, then Kylix is in the fridge (and i only say that to not have to say it is dead). Moreover it is linux/x86 and highly distro dependant. Where is Mac OS X, where are the 64-bit platforms? And even if it had those, it would only be a pale comparison to e.g. the number of platforms where most competitors except Microsoft can run on.

3. I personally translated large sets of headers to Pascal for FPC. Thinks like commctrl etc. If you really have one that works, let me know (hint: there isn't any)

4. That's exactly what I mean. If it is not in unit windows (which pretty much contains the win98 win32 API), you have to translate it yourself from a VB or C prototype. It is hard to get up to date info with examples and prototypes in the Delphi language

-- Marco van de Voort

Borland has choosen to divest itself of Delphi. It has been openly discussed that some current Borland managers will move to the head of a new company that will own Delphi. This shows that the new company will be a spin off rather than an outright Delphi purchaser. After this spin off, if Borland were to fold or acquired, this action will preserve Delphi's owners/managers postions. If you want to edit out these facts, please provide an argument here. Sysrpl 16:58, 4 March 2006 (UTC)Reply

There's a couple major problems I see here. First, unless a statement about motives comes from a company's PR department, anything about the company's motives is speculation. The thread you link to shows exactly how credible this source is -- not at all. Also, even if it were true and we had official confirmation, it is still attached to the wrong article entirely: The article on Delphi programming language should not be talking about Borland's manuevers at all, except insofar as it changes the language. --Steven Fisher 17:06, 4 March 2006 (UTC)Reply

As (1) a moderator of the newsgroup in question and (2) someone who is under NDA with Borland and has close connections with many employees there I can assure you that anonymous posts on the Borland newsgroup are not a reliable source, generally speaking. They certainly don't meet WP:V. Wikipedia is not a crystal ball. You may also want to read Wikipedia:No_original_research. Note that Verifiability and No original research are not my personal opinion; they are official policy on Wikipedia. I edited out the speculation; I don't see any verifiable facts in what you added. --Craig Stuntz 02:04, 5 March 2006 (UTC)Reply

This article talks about a programming language and Delphi is just an IDE which uses that language. The language is commonly known as Object Pascal or Delphi Pascal. Someone who knows how to use wiki proper, unlike me: please fix this.

Done. Dybdahl 06:17, 23 July 2006 (UTC)Reply

The Delphi Language is not Object Pascal and if Object Pascal deserves its own article so does the Delphi langauge, as it is much more widely used. Please put back the content relating to the Delphi language. Plastic rat 09:58, 17 November 2006 (UTC)Reply

I've split Delphi IDE information into Borland Delphi. Delphi product information should go there. This article should be for the Delphi Pascal language itself. Please change. thx

I moved all content of this article to either Object Pascal or Borland Delphi, sometimes rephrasing things to make sure that things are now better than it was before. However, there are still minor things to clean up, so please visit these two articles, read them, and fix things you think is wrong. I suggest that continued talk is done using the talk pages for these two articles. Dybdahl 06:19, 23 July 2006 (UTC)Reply

The only problem with this is that the Delphi programming language is explicitly not Object Pascal. --Steven Fisher 03:26, 17 November 2006 (UTC)Reply

I agree with Sdfisher above - there shouild be an article for delphi pascal langauge, separate from the Delphi IDE and Object Pascal language. The Borland Pascal language is used by e.g the free pascal compiler, and the delphi compiler can be used alone independent of the IDE, so this is a separate topic. Please revert this change. Plastic rat 09:53, 17 November 2006 (UTC)Reply