TPersistent.com

I started using Object Pascal (Delphi) because it was VB like without the ugly syntax of VB, and it had the power of C++.   Namely that you could create as well as consume COM objects and it was natively compiled with at the time a very fast compiler when compared to C++.  The VCL was a stable UI framework that was simple to use and flexible enough that unusual use cases were still possible.

Sadly, now I use Delphi less and less and for maintenance work only, or personal and open source projects.  The community has dwindled from what it was once, local jobs are harder to find, and many luminaries have been lost to the evil empire (M$) and it’s technology.

I must admit that I am now working predominantly on C# .NET Core projects. I would gladly come back from the dark side if someone wanted to entice me with a interesting Delphi project. I find C# syntax more terse and unreadable than Object Pascal, but there is no mistaking the power of LINQ, the PPL, and the abundance of open source projects and technical resources. .NET native also makes adoption of C# even more tempting. If they can write Kestrel in C# you should be able to write anything that requires good performance in C#. I would love to see some Delphi web server benchmarks and how they compare to Kestrel. Favorable results might generate more interest in Delphi as would compiler benchmarks.

I love Delphi. I wish it a bright future.  Without new developers it will most certainly fade away over time.  New developers shy away from languages that won’t get them jobs.  An investment in learning a language, an IDE, and run-time libraries simply has to pay off.  Without a growing market share, expensive tools have to provide developers with a competitive edge. For this reason, I applaud EMBT’s release of the Community Edition. I hope it will bring new blood into the development community and spark more open source projects. There are some amazing open source projects out there that could use Community Edition to further their efforts.

There are also many exciting things happening in the land of Pascal that I hope will expand the community. REMObjects has released their Oxygene compiler that can also target WASM as well as native code. Smart Mobile Studio has released version 3 of their Pascal language targeting Javascript, and TMS has introduced a similar product called WebCore based on the FPC Javascript transpiler.  EMBT has hired Jon Aasenden and purchased Sencha so who knows what they have planned. With UniGUI and other frameworks Object Pascal (or rather different dialects) have many more options to target the web than only a couple years ago. I long for the day when I could use the same Object Pascal language for web, desktop, mobile and server development without compromising the results. Is it time for a language standard?

I just bought a pair of BlueDio T4S headphones from Amazon.  I received the package and went to the Bluedio site to verify my purchase for warranty purposes, only to discover that BlueDio is offering the same headphones to consumers for $56.99 ($3 less than Amazon).

I called Amazon to find out why this was the case, and discovered they do not offer a lowest price guarantee like a lot of brick and mortar stores, and claimed they have no control over manufacturers offering their products directly to consumers.

I find it hard to believe that Amazon does not have anti-competition agreements with their vendors, otherwise why would anyone go to Amazon other than to find the product they wished to purchase and then buy it directly from the manufacturer?  The whole capitalistic distribution model would no longer apply, and Amazon as a middleman could be completely cut out.

The moral of the story is, caveat emptor (buyer beware), you may not get the best price from Amazon, so do some research before buying there.

Quite often new features are added into a code stream for demonstration purposes, or need to be hidden because they are not quite ready for release (especially true for monolithic EXEs), or the client cannot upgrade their database structures yet.

There usually are various home grown approaches to accomplish this ranging from command line parameters (beta switches to enable or disable functionality), to one off database metadata queries.  These approaches can be unified in an interface added to your database “data session” as shown in the following code snippets.

type
  TFeatureSupportedPredicate = reference to function(DataSession :IDataSession): Boolean;
  TFeatureInfo = class(TObject)
    Supported :integer;
    FeatureSupportedPredicate :TFeatureSupportedPredicate;
  public
    constructor Create;
  end;

  constructor TFeatureInfo.Create;
  begin
    inherited;
    Supported := -1;  //used to indicate the test for existence has not been performed
  end

type
  TDataSession  = class(TInterfacedObject,IDataSession)
  var
    FFeatureSupportDictionary :TDictionary<string,TFeatureInfo>;
    constructor Create; override;
  end;


  constructor  TDataSession.Create;
  begin
    //do some stuff
    FFeatureSupportDictionary := TDictionary<string,TFeatureInfo>.Create;
  end;

procedure TDataSession.AddFeatureSupportPredicate(
            const FeatureName :string;
            Predicate :TFeatureSupportedPredicate);
var
  FeatureInfo :TFeatureInfo;
begin
  if FFeatureSupportDictionary.ContainsKey(FeatureName) then
    raise EFeatureSupportException.
                      CreateFmt('A Feature Support Predicate is already '+
                                'registered with the Name: ''%s'' ',[FeatureName]);
  FeatureInfo := TFeatureInfo.Create;
  FeatureInfo.FeatureSupportedPredicate := Predicate;
  FFeatureSupportDictionary.Add(FeatureName,FeatureInfo);
end;

function TDataSession.IsFeatureSupported(const FeatureName :string) :boolean;
var
  FeatureInfo :TFeatureInfo;
begin
  Result := False;
  if FFeatureSupportDictionary.TryGetValue(FeatureName,FeatureInfo) then
  begin
    if FeatureInfo.Supported = -1 then
      FeatureInfo.Supported := ifthen(FeatureInfo.FeatureSupportedPredicate(Self),1,0);
    Result := Boolean(FeatureInfo.Supported);
  end;
end;

Now wherever you pass or inject your IDataSession interface, which in a Client/Server application is almost everywhere, you will have access to the FeatureSupport functionality, and you can add/test predicates with the following code snippets:

  AddFeatureSupportPredicate(SomeFeature,
    function(DataSession: IDataSession): Boolean
    begin
      Result := DataSession.TableExists('SomeTableForTheFeature');
    end);

if DataSession.IsFeatureSupported(SomeFeature) then ....

We all know that software engineering is not at all like any other engineering discipline.  It is both a creative endeavor and an expression of technical acumen.  Applying the term “engineer” to this career is somewhat akin to the title “Domestic Engineer”.  If wasn’t, software engineers would not take an initial design, and then change the design after 90% of it was implemented as a SOP (standard operation procedure).  If civil engineering did such a thing you would see a lot more bridges collapse, and buildings like this one

Plans Change

String handling in Delphi has always been quick, but this has lead to the abuse of the data type.  I have seen code where strings are used to store all kinds of data (ie: Float) and is continually converted back and forth depending on whether it’s needed for the UI, a calculation, or to generate dynamic SQL.  Whenever data is stringified, it is open to interpretation by all consumers of that data.  Should it be handled as a string or converted to another data type and if so what type with what kind of precision and scale is necessary to avoid loss?  Who is responsible for conversion (the caller or the callee)?

By not using the native type for a given piece of data it becomes unclear as to how the data should be transformed in order for it to be stored for example to disk in the form of a config file entry, or used as a string in a SQL clause built using the Format() function.  Environmentally sensitive functions like Format() can cause massive code breakage when the user changes for example the decimal separator character, resulting in invalid SQL statements being generated.

The identifier name used for fields or variables representing data from a database column may be re-used to identify the stringified fields, causing confusion and compilation errors over the data type differences if hungarian or some other notation is not used as part of variable names.

Once data is stringified, there is no longer a data contract, and what ensues is a lot of wet (aka not DRY) brittle code (repeated data conversions) thrown together in a haphazard fashion in an effort to just “make it work”.  Making little changes like supporting different locales with say a comma instead of a decimal point for float values becomes a painful experiment if the applications are not properly layered.

My advice; write true native code, keeping fields and variables in their native type, and avoid stringification as much as possible.

I installed the latest CnPack’s Wizards 1.09.89 a couple days ago and DX Seattle suddenly seemed much slower, sometimes pausing for several seconds before presenting an hour glass and coming back to life.  A few times Windows actually detected it as not responding and prompted if I wanted to Debug or Close Delphi.

Today I uninstalled CnPack and DX Seattle is again responsive.  Too bad, I like a few of their add-ins.  Hopefully a subsequent release will resolve it.

At work I have an SSD which is only 220 GB so it is almost full almost all of the time.  Gone are the days of lean software deployments, and I am a hoarder when it comes to information.  As a result, I was attempting to install DX Seattle on my SSD and Install Aware told me I had sufficient space after unselecting various features.

After proceeding, Install Aware told me it does not have enough!

In the end I did manage to free enough space to get DX Seattle installed, although it was like playing Russian roulette.  I ended up removing vital components for SQL Server Management studio that I then had to repair.

I recently upgraded to DX Seattle which contains the long awaited (7+ releases) resolution for the “Out of Memory” issue.  I was pleased to see that DX Seattle is now Large Memory Address aware, in addition to using memory more efficiently according to Marco Cantu.

So far, after installing Update 1 with the Modern Style hot fix I have not experienced a single Out of Memory error.  As a result, we are upgrading our licenses for the first time in 3 years even though there is a big push to move the core products to .NET.  If only EMBT would have addressed this earlier, perhaps we wouldn’t be so motivated to move.

I got notified today again about the IDE memory consumption issue (RSP-9568) I continually encounter even in XE4, although it seems to be more severe in later versions.  The Atlassian graph is very telling.  It seems EMBT is not even treading water, let alone making progress addressing quality issues.

Issues: 239 created and 202 resolved

So without buying the latest release, when or more to the point if issues like the Out of Memory problem actually get fixed, do you really think you will get an update for free?  No you will have to buy the latest release with all the new bugs.

Effectively you are paying for the new bugs at the same time as you pay for the old ones to get fixed (if they do), not to mention the cost in terms of lost productivity, component upgrades, and installation time.

With .NET Native coming, soon Delphi will not even be able to claim to be king of the hill in terms of ease of deployment and fast startup times…we certainly cannot claim to have a superior IDE in terms of stability or productivity even it appears with the addition of Castalia.

I tried to post a comment on Nick’s blog, but for some reason I never got the email for verification of my address so I thought I would respond here.

I find it very interesting that a former EMBT employee still with close ties, would write such a post.  I understand how he drew some of his conclusions, but I think he is mistaken and I hope EMBT does not share the same views.  Understanding the marketplace is very different from software development.

First of all, code quality is more about developer skill, and the processes employed during development and QA. The earlier defects are found the cheaper and easier it is to fix them. The number and age of unresolved bug reports does not speak well to EMBT’s (and their predecessors) concern for code quality. However, the primary driver, as with all things produced by a company, are the decisions made by management.  While no code is perfect, if you accept that it is not possible to produce bug free software then you have lost the incentive to try.

Having “volunteers” go through QC reports says that a company isn’t even willing to pay their staff to properly evaluate bug reports. Having a broken voting system and web QC, as well as an antiquated Windows client that not being maintained speaks volumes about what is important to a company.  Admittedly, the bug tracking systems have finally changed.  It doesn’t seem to have affected the number of fixes for long outstanding issues though. As people we spend our time on what we believe is most important. Same thing for companies.

Allowing half baked (incomplete) or non-working visible things like the panel at the bottom of the object inspector that Marco wrote an add in to remove, Error Insight, and the Refactorings remain in the product for years without fixing them is not only stupid IMHO, but a software development nightmare. Web companies are making money on minimalist applications that satisfies a small need, but does it extremely well. EMBT seems to prefer the old school thinking of a humongous application that does everything under the sun, but does some things very poorly, and taints everything else with the same code smell. They don’t even seem to be willing to consider using the plug in system to provide ‘a la carte’ choices to their customers, or drop existing functionality that is not required to limit their technical debt going forward. What other company has someone external to the company provide bug fixes for their IDE that apparently never get incorporated into the product because Andreas is still churning out IDEFix pack!

Only in an emerging marketplace can you continue to sell flawed products that look good on the surface, but don’t work as well as they should, to be used daily for someone to make their living. Development markets are not emerging ones, nor are they without stiff competition.

Developers are smart people. EMBT is fooling no one with their choices when it comes to resource allocation. Hire cheaper developers around the world to cut costs, focus on emerging markets where quick profits can be made, and increase the cost of the tools by coupling the mobile pack with the core dev tools and charging for each, effectively double dipping, while raising the cost of the product across the board and providing diminishing product quality. Typical of a company acquired to provide profits to it’s purchaser, and not for any ideological reason.

The definition of insanity is doing the same thing over and over expecting a different outcome.  Developers will only continue to buy EMBT licenses or subscriptions as long as they have to in order to support their products, or where their is some advantage (none come to mind right now) because they aren’t insane.  EMBT on the other hand cannot continue indefinitely down this path, unless they want to drive away their user base, or intend on getting as much cash from their users until the bottom falls out, and they close the doors.

Delphi is no longer a bleeding edge tool, even in the mobile space.  It has more competition than ever, and a major challenge with Microsoft/Xamarin/.NET Native and Apple competing in the market place.  One of the reasons for it’s current success is the older user base supporting existing applications built when Delphi was bleeding edge, or trying to use their skills in the mobile space.  That ride won’t last forever.

Perhaps I have digressed a little, but my point is that EMBT has shown it’s colours.  They don’t care about code quality or their actions would speak more to it. Instead they want to add just one more feature into the box.   Perhaps a subscription model would help a little, but it won’t result in more bugs fixes.  We have been voting with our wallets for some time now, in QC, and on the forums and they are still not getting the message!  As a customer I would have to be insane not to recognize their pattern, and refuse to pay for bug fixes (it’s a great money making machine if you can convince users to do so), and choose another toolset from a company that does care.  If they did we would have seen bug bounties a long time ago…

At work we’re developing C# .NET replacements for our Delphi apps as we speak!  Good luck to EMBT.  XE4 with the infamous  ‘Out of Memory issues’ will be the last release we buy…