The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,947 other followers

Archive for February 10th, 2021

Kristian Köhntopp explaining theories

Posted by jpluimers on 2021/02/10

A few years back, coincidentally and funnily shortly after Matt Haig compared confidence in Brexit with science confidence, Kristian Köhntopp explained about theories, in response to this (translated from German) question:

Why is the theory of relativity and evolution theory actually still called ‘theory‘?

The essence of this question is that in everyday speak, people have different idea on theory (thinking it is not yet proven, or can be disputed with very little evidence, both more like hypothesis), than in formal or scientific usage of the word theory:


Scientific theories are the most reliable, rigorous, and comprehensive form of scientific knowledge, in contrast to more common uses of the word “theory” that imply that something is unproven or speculative (which in formal terms is better characterized by the word hypothesis).

Theory: Ancient_uses:

The English word theory derives from a technical term in philosophy in Ancient Greek. As an everyday word, theoriaθεωρία, meant “a looking at, viewing, beholding”, but in more technical contexts it came to refer to contemplative or speculative understandings of natural things, such as those of natural philosophers, as opposed to more practical ways of knowing things, like that of skilled orators or artisans.

Theory: Definitions from scientific organizations

The formal scientific definition of “theory” is quite different from the everyday meaning of the word. It refers to a comprehensive explanation of some aspect of nature that is supported by a vast body of evidence.

So Isotopp explained:

[WayBackKristian Köhntopp auf Twitter: “Weil sie das sind. Ein System von Theoremen, die ein Modell der Realität darstellen, das es erlaubt Vorhersagen über die Welt zu machen.”

[WayBack ]Thread 1 by @isotopp:

Weil sie das sind. Ein System von Theoremen, die ein Modell der Realität darstellen, das es erlaubt Vorhersagen über die Welt zu machen.

The Quark And The Jaguar: Adventures in the Simple and the Complex…

Das Buch geht auf diesen Aspekt und noch viel mehr in einiger Länge ein und ist generell hilfreich um zu verstehen was Wissenschaft ist und was nicht

[WayBack] Aljoscha Rittner auf Twitter: “Ich glaube es wird noch sehr lange dauern, bis wir über den Punkt hinaus sind, nur mit Modellen unser Universum beschreiben zu können.”

[WayBack] Thread  2 by @isotopp

Äh, das tun wir seitärun… Es ist das Wesen des Modells, einen Scope und einen Fehler zu haben. Scope – die Newtownschen Gesetze beschreiben die Bewegung von Dingen mit Masse in Vakuum. Nicht in Atmosphäre, …
… nicht von Dingen ohne Masse und nicht bei sehr hohen Geschwindigkeiten. Fehler – wir wissen, das Newtons Theorien eine Vereinfachung sind, und Einsteins Formeln den Sachverhalt gebaut beschreiben, aber Einsteins Formeln degenerieren für v<<c zu denen von Newton.
Es ist der Sinn von Modellen, uns zu befähigen, Vorhersagen zu machen, wie sich die Welt verhält. Das Modell ist dabei oft beschränkt und ungenau, es seine Anwendbarkeit nicht einschränken muss, weil wir oft Fehler hinnehmen oder Beschränkungen im Anwendungsgebiet akzeptieren

[WayBack] Frank Hartmann auf Twitter: “Ist eine Theorie, die bewiesen wurde, nicht mehr von alleine keine Theorie mehr? Sondern vielmehr ein Fakt?… “

[WayBack] Nathaniel Bernstein auf Twitter: “Du meinst „Hypothese“, wo du „Theorie“ schreibst.… “

[WayBackFrank Hartmann auf Twitter: “Nopp. Man hat eine Hypothese. Dann stellt man eine Theorie auf, forscht und beweist diese. Oder auch nicht. Dann beantragt man mehr Forschungsgelder gg”

[WayBack] Thread 3 by @isotopp

Eine Theorie, ein System von Theoremen, ist nicht bewiesen und oft auch nicht korrekt (dh bekannt falsch, beschränkt und ungenau)

Darum mein abzielen auf Vorhersagen. Daltons Atommodell… ist beschränkt, war aber in der Lage, Dinge zu modellieren…

… die vorher nicht modellierbar waren. Wieso reagieren Wasserstoff und Sauerstoff 2:1 in der Knalleraktion?

Thompson, Rutherford, Bohr haben bessere (genauere) Modelle, die an Ende als Verfeinerungen oder Verkomplizierungen von Dalton aufgefasst werden können.

Diese Modelle leisten, was ihre Vorgänger jeweils konnten und mehr (größeres Anwendungsgebiet, bessere Genauigkeit)

Du kannst eine Theorie “beweisen” in den Du sie für Vorhersagen verwendest und dann schaust, ob die taugen.

Du kannst sie widerlegen: Die Vorhersagen sind unzutreffend oder für den Zweck zu ungenau.

Du kannst nichts tun, wenn sie Theorie keine Vorhersagen liefern kann

Das Wesen von Wissenschaft ist, das Theorien Weltmodelle liefern, die Vorhersagen machen, die sich in Experimenten prüfen lassen
Deswegen bleiben Theorien dennoch immer Theorien, Systeme von Theoremen, und sie bleiben unvollkommen (Modelle, effektiv Vereinfachungen, mit Anwendungsgebiet und Genauigkeitsgrenzen)

Via [WayBack] Frank Hartmann auf Twitter: “Wieso nennt man die Relativitätstheorie und Evolutionstheorie eigentlich immer noch ‘Theorie’? #Science”


Read the rest of this entry »

Posted in LifeHacker, Power User, science | Leave a Comment »

Some LCID links and notes

Posted by jpluimers on 2021/02/10

Document locations changed, so here are some links to newer and older documentation on LCID related things:

More Delphi related links:



Posted in Development, Internet, link rot, Power User, Software Development, Windows Development, WWW - the World Wide Web of information | Leave a Comment »

The Delphi interface reference counting compiler bug that will never get fixed as it is marked “as designed”

Posted by jpluimers on 2021/02/10

A long time ago, I write a question [WayBack] delphi – Should the compiler hint/warn when passing object instances directly as const interface parameters? – Stack Overflow in 2010.

It was marked by (now former) compiler engineer Barry Kelly [WayBack1/WayBack2] as bug:

It’s a bug. The conversion from instance to interface reference in RunLeakCrash should be to a temporary variable, keeping it alive for the duration of RunLeakCrash.

Added to that was a comment that this has happened since at least Delphi 6, so I filed a bug WayBack QualityCentral Report #: 90482 The compiler should keep a hidden reference when passing freshly created object instances directly as const interface parameters.

Just for years later, it was marked with “As Designed” which means it is never going to be fixed, especially since in the mean time Embarcadero got rid of most the senior Delphi R&D team members and went down the path of hiring contractors.

The problem is that I run into the two manifestations every now and then, and it usually takes a long time debugging to zoom into the actual location of the spots.

First manifestation: crash

This is the bug in the first manifestation (by now the root interface is IInterface instead of IUnknown, and you usually have an interface derived from it):

procedure ReferTo(ValueReference: IUnknown);
// remove the comments to reproduce it in earlier Delphi versions (I reproduced it in Delphi 5, 2007, 2009 and XE)
//  if not Assigned(ValueReference) then
//    ;

procedure PrematureFreeCrash(const Reference: IUnknown);
  ReferTo(Reference); // the second call will crash inside ReferTo because the object instance that Reference referes to just got destroyed

procedure RunPrematureFreeCrash;

The good thing is that the first manifestation will crash, especially if you run it under FastMM4 debug mode where freed memory will be filled with a $80808080 pattern, as you can see in these blog posts

Second manifestation: memory leak

The second manifestation is that you just access a member of the interface (like a method or property of an interface like IMyInterface) instead of calling ReferTo.

Now – since there is no reference counting, the object you created will never have _AddRef or _Release called, still have a FRefCount of zero (with which it was initialised) and live happily ever after.

In other words: now you have a memory leak that is very hard to track down.

Related but simpler bugs got solved

There have been quite a few similar bugs have been solved, for instance [WayBack] delphi – Unused interface reference is not destroyed – Stack Overflow.

I wonder what sets those apart from the above one.

In a similar way const string parameters can be dangerous as stated by Marco: [Wayback/Archive] The Case of Delphi Const String Parameters

Daljija Prasnikar indicates it is a can of worms but also argues it is not a bug because “this is why const is used for speed optimization in the first place.” in [Wayback/Archive] Are const parameters dangerous?.

I totally disagree with that. For me the side-effect for const is that it is a speed optimisation, but the primary reason is a promise that you cannot change the parameter.

The problem by now is that the Delphi compiler team has moved to think about the const parameter from having a semantic meaning into an optimisation meaning, so these bugs will never be fixed.

Why it is hard to find the manifestations

The biggest problem on why the manifestations are hard to find is a three part thing:

  • the use is often not limited to a few levels, so there can be a large stack trace you need to trace back to the cause if you get one at all
  • the stack trace usually involves crashes around things like TInterfacedObject._Release which very often results in incomplete stack traces
  • very often things like COM or OLE Automation are involved (hence my earlier reference to it from Links to debugging COM stuff for Office Automation in Delphi)


Two work-arounds that both add extra reference counting::

  1. Replace the const parameter with a non-const one (basically removing the const bit) which will incur automatic _AddRef and _Release reference counting in the method.
  2. Store the value of the const parameter in another reference, which will incur manual _AddRef and automatic _Release reference counting in the method.

Both solutions will call the _AddRef and _Release on the interface.

Of course this incurs extra overhead, much more than the compiler based solution Barry Kelly wrote about would, but it at least introduces the reference counting


Posted in Delphi, Development, Software Development | Leave a Comment »

%d bloggers like this: