Archive for December 6, 2016

Goodbye G+ Delphi Developers group

December 6, 2016 20 comments
A bit sad today. I typically post blog articles about Delphi, Smart Pascal and embedded projects both on Facebook and Google+, but apparently Smart Pascal is not welcome at Google’s Delphi group. Even examples where Delphi talks with a node.js server on a Linux box is apparently “off topic” and “not Delphi”. So much so that my post was deleted. I’m getting so sick and tired of this double standard. This is not the first time Smart is pushed aside. We were even banned from speaking at Delphi Tage a couple of years back. I really dont understand this attitude at all.
So easy, so powerful and you can deploy it anywhere. An embedded system, a dedicated server - or do a push to your Amazon / Azure cloud stack. Node.js is so powerful once you understand how to use it.

This is from the deleted post. If you look at the picture you will notice a Delphi UDP client/server on the right talking with a node.js service on the left. Aparently this is not Delphi enough for the admin in charge of the Delphi group on G+

I was particularly saddened by this since I have from time to time seen Elevate Software post about their web builder utility. But for some reason Smart pascal is not allowed to do the same (in this case it was a post from my blog). With all due respect for Elevate Software, but when it comes to interfacing Delphi with a modern IOT infrastructure or eco-system, Elevate is not even in the same ballpark. But focus here is on the technical, and Elevate’s web builder is ultimately in the same category as Smart Mobile Studio. So how their system that compiles a subset of object pascal to JavaScript is somehow allowed – while our product is not, I find both morally unacceptable and hypocritical. First of all since Embarcadero have held workshops in Angular.js (!).
Looking into the actual data, with JavaScript leading and JavaScript libraries on client and server side (Angular.js, Node.js) on the rise, it was nice to see that while Delphi was not listed as an option, it was the most typed entry in the “others” category -Source: Marco Cantu
Let me sum up a few facts:
  • Smart Mobile Studio is written 100% in Delphi
  • Smart Mobile Studio was created from scratch to compliment Delphi
  • Smart Mobile Studio supports Remobjects SDK out of the box
  • Smart Mobile Studio supports Embarcadero Datasnap out of the box
  • Smart Mobile Studio helps Delphi developers write the middleware or interfacing that sits between a native Delphi solutions and a customer’s node.js or purely web-based solution. This is 2016 after all.
  • Where a Delphi developer would previously have to decline a job offering because the customer’s existing infrastructure is based on node or emits data unsuitable for traditional Delphi components, developers can now relax and write the missing pieces in a Smart pascal, a dialect roughly 90% compatible with the language they know and love to begin with.
  • Smart Mobile Studio ships with a wast RTL that greatly simplify talking with Delphi. It also has a VCL inspired component hierarchy where more and more complex behavior is introduced vertically. This gives your codebase a depth which is very hard to achieve under vanilla JavaScript or Typescript.
  • Smart Mobile Studio is all about Delphi. It is even used to teach programming in the UK. Teenagers who by consequence and association is statistically more likely to buy Delphi as they mature.
Now I have no problem understanding or respecting the notion of single-topic groups. But having said that I expect the administrator(s) to apply this rule equally and without exception. Not just Smart pascal.
The reality of 2016 is that no Delphi developer use a single language or dialect. That may have been true 10-15 years ago, but that’s not where we are today. When a customer demands that your interface your Delphi software with their existing node.js or io based eco-system there are only 3 options available:
  • Decline the project
  • Learn JavaScript or Typescript and do battle with its absurd idiosyncrasies, lack of familiar data types, lack of inheritance and lack of everything you are used to
  • Use Smart Mobile Studio to write the middleware between your native solution and the customer existing infrastructure

If you pick option number two, it wont take many days before you realize just how alien JavaScript is compared to Delphi or C++ builder. And you will consequently start to understand the value of our RTL which is written to deal with anything from low-level coding (allocmem, reallocmem, fillmemory, move, buffers, direct memory access, streams and even threading). Our RTL is written to make the JavaScript virtual machine palatable to Delphi developers.

Banning dialects?

Once you start banning dialects of a language or an auxiliary utillity designed to empower Delphi and make sure developers can better interface with that aspect of the marketplace – where does it stop? I am curious to where exactly the Google+ Delphi group draws the line here to be honest.

Should Remobject Oxygene likewise be banned since it helps Delphi developers target the dot net framework? That would be odd since Delphi shipped Oxygene for years.

Should script engines be banned? What about SQL? SQL is a language most Delphi developers know and use – but it is by no measure object pascal and never will be. Interestingly, Angular.js seems to be just fine for the Google+ Delphi group. Which is a bit hypocritical since that is JavaScript plain and simple.

What about report engines? Take FastReport for instance: FastReport have for the past decade or more bolted their own scripting engine into the product, a script engine that supports a subset of object pascal but also visual basic (blasphemy!). On iOS you are, if we are going to follow the Apple license agreement down to the letter, not even allowed to use FastReport. Apple is very clear on this. Any applications that embed scripting engines and at the same time download runnable code (which would be the case when downloading report files) is not allowed on appstore. The idea here is that should some code be downloaded that is harmful, well then Apple will give you a world of hurt. And even if you consider it a report-file, it does contain runnable code – and that is a violation.

So is Fastreport Delphi enough? Or is that banned as well?

Where exactly do we draw the line? I can understand banning posts about dot net if it’s all about C#, but if it’s in relation to Delphi or deals with Delphi talking with dot net (or an actual dialect like Oxygene) then I really don’t see why it could be banned or deleted. Even Delphi itself uses dot net. It’s one of the pre-requisites for installing Delphi in the first place. I guess Delphi should also be banned from the Delphi group then?

In our group on Facebook, all are welcome. Embarcadero, Lazarus and Free Pascal, Elevate software (be it their database engines or web builder), Pax compiler, DWScript, Smart Pascal, NewPascal (or whatever it’s called these days) and even Turbo Pascal for that matter. And we sure as shit dont delete posts of Delphi talking to another system.

So goodbye G+ and good luck