I’ve closed the mini-pool, below are the results, obtained after 500 respondents, as well as some other stats not obviously evident from the poll results (as it was a multi-choice poll).*
They’re of course only relevant as the measurement to the audience of this site.
(more…)
…or at Work if your prefer.
This is a small poll to gauge the audience of this site,, try to answer about the environments you use for production, not for experimenting, testing or fiddling.
If you use several version, feel free to check as many entries as you feel are relevant.
Work and processing classes are typically short-lived, created to perform one form of processing or another then freed. They can be simple collections, handle I/O of one kind of another, perform computations, pattern matching, etc.
When they’re used for simple workloads, their short-lived temporary nature can sometimes become a performance problem.
(more…)
As a followup to the TIOBE & Pascal micro saga, thanks to David Champion, DWScript programming is now a (very) small part of the TIOBE TPCI stats, and Oxygene became its own language at position #163.
Here is an excerpt from the TIOBE update for July 2013
(more…)
Worst thing in popularity is not being considered, or found.
Looks like TIOBE is not alone in differentiating Delphi and Pascal, other popularity indexes share the same issue:
More indexes I looked at didn’t show the “runners up”, only the top 5 or top 10, but they may as well have differentiated.
For lang-index, merging Pascal (rank 11) and Delphi (24), would be enough to reach rank 10, ahead of Ruby, just shy of Perl.
For some unfathomable reason, the TIOBE index distinguishes between “Pascal” and “Object Pascal”, and the “Pascal” category is seeing growth:
So it can’t be the old classic procedural Pascal, can it? That leaves only Object Pascal dialects (FreePascal the largest, but also Oxygene and SmartPascal/DWScript). Pascal programming isn’t dead or dying.
In this new episode of the TMonitor saga is a comparison of its locking features vs TRTLCriticalSection, aka the OS-supported critical section mechanism. Is it fair? is it fast?
Fairness means that if you have several threads attempting to lock the same resources, they’ll all get a chance and none of them gets the lion’s share. In other words, that there are no race conditions.
Speed is obvious, it’s about the overhead the locking mechanism incurs.
Edit 2013-08-24: looks like the issue discussed here should be resolved in XE5, cf Monitoring the Monitor by Allen Bauer.
Weak references and their zeroing is managed in Delphi NextGen through a global hash table, with a global lock, see Arnaud Bouchez take on it:
Performance-issue-in-NextGen-ARC-model
Also apart from the global locking which itself is bad enough, there are a couple further performance issues:
One of the “novelties” of the NextGen Delphi compiler is immutable strings, which I find quite puzzling, for lack of a better word, given that Delphi already had reference-counted copy-on-write strings, and the NextGen compiler uses reference-counted strings.
I always considered that Delphi’s String type was one of its remaining strong points, being a high-level abstraction (higher than Java’s or .Net’s String/StringBuilder dichotomy) with excellent low-level performance (on par with C/C++ character arrays).
From the recent discussions, it appears many don’t know what makes/made Delphi String so special, so here is a quick summary.
Visual Basic in its various incarnations and off-springs has super-powers when it comes to OLE Automation, aka late-bound COM through IDispatch.
Where do they come from?