[DUG] Seattle questions

[Jolyon Direnko-Smith]

John,

Scientific measures are OK.  But there are numerous problems with the TIOBE
index, not least being that it provides a global view which may be of
abstract interest, but businesses require a relevant, local perspective.
 it is no good "knowing" that Delphi is 0.5% up on last year and cheering
that if the up-tick is coming from an increase in localised activity in
Ukraine but you need to hire developers in NZ.

To that extent, local observations count for more than global metrics, no
matter how "scientific".  After all, the origins of the "Scientific Method"
lie in observation.  Measurement is only one form of observation, the key
is to observe that which is important and relevant to the topic under
study, not merely that which is observable and to avoid what I call "The
Metric Trap".  That is, basing decisions on thing you can "measure" simply
because they are more easily/cheaply measurable.


Unless I missed something, I don't see where you identify the contradiction
in my comments re Microsoft and open source.  I wonder what definition of
"proprietary" you are using when you say that you don't consider
Embarcadero/Delphi to fall under it.

You can use C# compilers from multiple vendors.  Today.  Microsoft may be
the main vendor, but there are others (and the code compiles and runs on
the Microsoft platform, as well as others).  Microsoft's source code for
the compiler as well as the runtime is freely available and may be used and
modified to whatever purpose you see fit.  Other vendors (e.g. RemObjects)
may not publish their particular compiler source, but their language
implementation is directly compatible with that of Microsoft.

Delphi can only be compiled with Delphi.

Other variants of Pascal compilers have some [very] limited support for the
Delphi dialect, but this is very limited and any (almost all) Delphi
project will involve more than just Delphi syntax, being also dependent
upon the VCL or FireMonkey frameworks.  It is quite possible to write
Pascal code for these other compilers (usually library code, rather than
applications) which will also compile as-is in Delphi.  Going the other
way?  Not so much.  In particular if you are using VCL or FMX (which
ironically started life as a FreePascal project).  If you use VCL or FMX(*)
you have no choice but to have a license from Embarcadero.

They may provide the source for most of those libraries, but that is
reference material only.  It's Published source, not Open Source.

And they do not make the source code of the compiler available at all.


[(*) And if you are using Delphi but NOT using the VCL or FMX then you
really need to ask yourself why you are paying through the nose for Delphi
when you could be using FreePascal instead].



As far as where this all started - the default safety of null terminated
strings - your initial statement was simply factually incorrect, that's all.

But it was also misleading in assuring the (relative) safety that this
implies.  Not only are strings in Delphi null terminated, there also remain
functions in the RTL which rely on this null terminator rather than paying
attention to the described length.  But if your intended meaning was that
the explicit length of a string made Delphi strings fundamentally more safe
than .NET then this compounds the inaccuracy because this too is incorrect.

Strings in .NET have precisely the same characteristics:  a length
descriptor AND a null terminator.

One big difference is that in .NET you cannot - as you can in Delphi -
simply cast a string as a pointer and then freely manipulate it directly.
Of course, nothing requires you to do this in Delphi, but nothing stops you
either if you don't know better or are intent on extracting the last few
clock cycles of efficiency out of your string handling code, in which case
you have to be very careful to get things exactly write or you can very
easily - if inadvertently - create exactly the sort of buffer over(or
under)run problems you mention.

Pointers are a far greater part of the picture and unsafe code generally
far easier to write in Delphi than in .NET, if you don't know what you are
doing.

This is the great trade off between Delphi and .NET....  .NET goes much
further in preventing you from making mistakes, for which you give up some
efficiency.  But if you know what you are doing you can regain that
efficiency.

The real problem is that since Delphi and similar unmanaged languages are
no longer the focus of the formal or post-formal education system, if you
take a "qualified" developer and put them down in front of a Delphi
compiler, they will make exactly the sorts of mistakes that the managed
languages are specifically designed to prevent because they simply haven't
been taught that it was ever possible to make those mistakes.

An experienced, skilled Delphi developer knows both how to avoid those
mistakes and produce efficient code.

But, as I don't think is under any doubt, the lack of availability of those
experienced, skilled Delphi developers is the single biggest. practical
problem that is causing businesses to abandon Delphi.


To your final two points:

1) It's not enough for Embarcadero to want to promote Pascal as a teaching
language.  Even if they were serious about such an initiative (and it has
to be said that there is no reason to think that they will change their
tack on that after all these years) the institutions also must want to
teach it.  Modern syllabuses (syllabi?) are driven by what institutions
perceive as in demand in industry and commerce.  As a result, that
particular vicious circle has long since been closed to Pascal,
unfortunately.  Even if Embarcadero were to start pushing, I'm afraid they
would find themselves faced not just with a heavy door but a wall.


2) Running "Delphi" in a browser is a non-sequitur for the reasons
mentioned above w.r.t "Delphi" vs "Pascal".  "Delphi means not just the
specific Delphi dialect of Pascal but also the VCL and/or FMX).  Without
those things you are not talking about Delphi but simply "Obejct Pascal".
And if you want to run Object Pascal in a browser... well you first need
some engine capable of running Pascal code in a significant proportion of
the world's browsers.  Which means displacing JavaScript or getting Pascal
in alongside somehow.

Or, you could treat JavaScript as your target "binary" code, compiling
Pascal to JavaScript.  And you can do that today.  Smart Mobile Studio does
exactly that, and does it very well by all accounts (I have no direct
experience of it myself, but I follow it's evolution with interest).

This is the last "major platform" that Delphi no longer reaches ?  What
about .NET ?  You honestly don't consider that a "major platform" ?



On 11 April 2016 at 23:44, John Bird <johnkbird at paradise.net.nz> wrote:

> As I said this was my perspective, my experience.
>
> There are a wealth of commentators with their opinions on what is good,
> coming from a scientific background I like to look at the data, so an
> automated index rather appeals to me – its sort of factual with all its
> limitations of how it is compiled, data rather than opinion.
>
> A couple of the points you made seem to be contradictory – you say
> Microsoft is more natively cross platform and refer to Embarcadero as
> proprietary – I tend to look at Embarcadero as a much less proprietary
> vendor than Microsoft and almost all out there, even Oracle with Java.
> Also I don’t see that having a large free/open source variant (Lazarus/free
> Pascal) out there as a bad thing.   If Embarcadero ever did bite the dust
> financially I reckon most people would like to see and would work to Delphi
> becoming open source, much like Firebird.
>
> About zero terminated strings – the point I am making is that Delphi is
> not so prone to buffer overflows simply because it does not continue until
> finding a null terminator – the length for native Delphi strings is at the
> beginning.  (Yes it supports null terminated strings but that is beside the
> point I am making about its default safety)
>
> Most of us were not expecting so much focus on iOS or Android even 5 years
> ago, nor Bash appearing native on Windows (later this year).  I saw
> commentary that Google may be contemplating moving away from the Java API
> and all proprietary aspects of Java because of the on-going strife with
> Oracle.   So the IT market will continue as always to be unpredictable and
> changing and the longest lasting tools will be those that are the best
> designed and do not get sunk as being too embedded in an eco-system that
> moves out of market popularity
>
> Overall I see Delphi in a sweet spot in the market, a legacy language not
> tied to any major OS vendor and hence well placed to respond to new
> architectures, and these will continue to surprise.
>
> There are two things I think Embarcadero/Delphi could do that it is not:
>
> 1 - Some student program – give away value tools for IT students to get
> them used to Delphi, new young Delphi programmers, as well as
> C/C#/Java/Python/PHP/Ruby which most of them are working with – after all
> it was designed for that - as a teaching language.
>
> 2 – Some way of running Delphi programs in a browser – in a way its the
> last major OS they haven’t ported to as a target platform.
>
> *From:* Jolyon Direnko-Smith <jsmith at deltics.co.nz>
> *Sent:* Monday, April 11, 2016 8:21 PM
> *To:* NZ Borland Developers Group - Delphi List
> <delphi at listserver.123.net.nz>
> *Subject:* Re: [DUG] Seattle questions
>
> Um, John.... Delphi has had zero terminated strings since Delphi 2 and
> still does.  They are zero-terminated AND they have a payload descriptor
> which specifies the length.  This can actually lead to problems when a
> string is both terminated by a zero but also ends up CONTAINING a zero
> (i.e. an additional zero within the string length described for the string,
> BEFORE the terminating zero).
>
>
> Surveys don't mean anything when it comes to credibility.  TIOBE in
> particular (not a survey incidentally, but an automated index) is
> poo-poohed when it shows Delphi in decline but is suddenly now reliable?
> And there was a recent bit of an upset when someone (at Embarcadero but
> supposedly with no particular axe to grind... yeah right) managed to
> finally get the TIOBE index to count "Object Pascal" in the Delphi numbers,
> something which some parts of the Delphi community have always claimed was
> why Delphi was under-represented in that index.  So as of February this
> year, Object Pascal does now count towards Delphi (even though there is a
> LOT of non-Delphi Object Pascal activity) and the difference it made was
> ... negligible.  In fact, no difference at all, despite some people posting
> some spurious comparative claims about performance in the last 12 months
> (in the TIOBE index).  A proper analysis of TIOBE shows no such thing
> unfortunately.
>
> On the ground I can say that Delphi skills are in shorter supply (in NZ)
> than ever as the result of there being no new "intake" and the old guard
> continuing to drift away (or retire).  And as well as corporates not having
> heard of Delphi or believing it to be "out of business", there are also
> many who do know full well what the current state of affairs is and for
> precisely those reasons are actively engaged in removing it, and their
> dependency on it from their businesses.
>
> It is difficult to think of Delphi "still going strong" when it is hardly
> "strong" now.  However, I doubt it will ever disappear.  Programming
> languages never really die.  Even Gupta, PowerBuilder and Omnis are still
> going after all these years, supported by eye-watering prices (if you need
> to ask you can't afford it) paid by a tiny user base (sound familiar?).
> Consider that the cost of a new user Delphi "Ultimate" license is now over
> NZ$10,000.  You don't need to sell many of those to make a bit of money.
> Which is a good thing, because you won't (sell many that is).
>
>
> As for outliving C# for the reasons you gave.  I think Pascal will
> absolutely live on, so Wirth's legacy is secure.  FreePascal is getting a
> LOT of attention these days, not least on the back of the popularity of
> devices like the Raspberry Pi, which you can use FreePascal on.  Even
> Lazarus, the Delphi-like IDE.  But the Delphi incarnation of Pascal .. ?
> I'm not so sure.  Certainly not for the reasons you mention.
>
> C# is now also "officially" cross platform and could be argued to have
> been so for a long time (thinking of Mono in general and Xamarin more
> recently in particular) and in a far more complete and robust fashion than
> FireMonkey.  .NET core is a "natively cross-platform" framework, rather
> than a lowest common denominator cross platform runtime environment "bolted
> on" and reliant on on-going support from the underlying platforms for the
> approach to even remain viable.  If Google ever decide to end of life the
> NDK (e.g. if they decide that the Java SDK + ART delivers all the
> performance that developers need) then FireMonkey has no place to go on
> Android.  For example.
>
> If nothing else, Delphi faces a problem in being proprietary to
> Embarcadero.  With Microsoft now embracing Open Source, expensive
> proprietary, closed systems such as Delphi look increasingly out of place.
>
> Worth noting is that FreePascal is also open source, also cross-platform
> and has been for longer than Delphi and supports many more platforms than
> Delphi.
>
>
> Apologies if this comes across as doom or nay saying but if Delphi is to
> be assessed properly in the current context then we need to make sure we
> are properly across that context and not looking at it through rose tinted
> specs.
>
>
> On 11 April 2016 at 16:33, John Bird <johnkbird at paradise.net.nz> wrote:
>
>> My perspective, and its a partial one.  But I work in a house using both
>> XE8/Seattle and C#
>>
>> Q1 – XE8 is fine (our current production version) and all the comments
>> about Seattle I have heard are good – large projects more stable in
>> particular.
>>
>> Q2
>>
>> ·         Which is more effective at producing finished product. (Faster
>> to market)
>>
>> Both are fast – Delphi compiler and single file deploy is still very hard
>> to beat.
>>
>> ·         Which is more effective at meeting customer’s needs. (Faster
>> customisations)
>>
>> Everyones opinion will differ on this
>>
>> ·         Solution performance. Which is better. (How snappy is the
>> solution to use)
>>
>> Delphi performance is hard to beat.   A lot of .NET is also very good
>> these days.   But not all.
>>
>> ·         Security. Which is better. (.NET seems inherently flawed in
>> this respect)
>>
>> Delphi does not have zero terminated strings – this has to be a huge
>> advantage as buffer overflows in strings are likely the main security
>> weakness in C family of products.  Runtime languages such as .NET and Java
>> have a spotty reputation too.   Security is ultimately much more than the
>> language, but to my eyes Delphi starts with less weakness.
>>
>> ·         Deployment. Which is easier?
>>
>> Single file vs a folder structure of hundreds of files – and the issue of
>> figuring which files of those files to deploy for a new version.
>>
>> ·         Does the Delphi team sit comfortably alongside the .NET team ?
>>
>> Yup, 3 teams using both.   Each team prefers one or other, but uses
>> both.   Remember Anders Hejlsberg designed both
>>
>> ·         Which product fits better with latest business strategies such
>> as IOT and Cloud ?
>>
>> Everyone’s opinion varies according to what they know and like.
>>
>>
>>
>> Q3 – WPF - Yes with differences – merits in both
>>
>>
>>
>> Q4 – Credibility - refer surveys – latest TIOBE index has Delphi at
>> Number 11, at half to two thirds popularity of C#.   Higher than Objective
>> C and Swift still.  Java, C and C++ are still the biggest
>>
>>
>> http://www.tiobe.com/tiobe_index
>>
>> Q5 – IOT/Cloud - Delphi does Web Services, IIS and DBs, and cross
>> compiles to Win32, Win64, OSX, iOS, Android and linux server soon.  Others
>> can add more specific cloud points.
>>
>> Q6 -  Where - Europe seems strongest bastion of Delphi, but everywhere.
>> Maybe not India – they all want to seem to do SQL Server, C# and Oracle
>> there so they can get jobs in California.
>>
>> Q7 – Cost - Cost is reasonable to me.   If it has to be free looks like
>> Free Pascal is a decent alternative too - never had to look at it myself.
>>
>> Q8 – Support - Mainly good.   Generally resolve any issues within days or
>> hours – and its usually the way I’m doing it that is at fault
>>
>> Q9 – Developers - Mainly older developers tis true.  But only mainly.
>> Some of them think that Delphi may still be going strong when C# fades from
>> popularity – mainly for the reasons of:
>>
>> a – its a good language (Thanks Nicholas Wirth – designed as a good
>> formal teaching language)
>>
>> b – its already cross platform, so competes with the biggies of C and
>> Java with advantages over each.
>>
>> *From:* Tony Blomfield <tonyb at precepthealth.com>
>> *Sent:* Monday, April 11, 2016 1:21 PM
>> *To:* NZ Borland Developers Group - Delphi List
>> <delphi at listserver.123.net.nz>
>> *Subject:* [DUG] Seattle questions
>>
>>
>> I hope the group does not mind me asking a few business oriented
>> questions about Seattle.
>>
>>
>>
>> I have had Seattle since its original release, but so far have not used
>> it. I have become quite cynical about Delphi as a result of my XE2
>> experiences.
>>
>>
>>
>> 1.       I’d like to hear from anyone that is using Seattle in full
>> production, general thoughts about its features, and productivity.
>>
>>
>>
>> 2.       If there is anyone also using .NET? It would be particularly
>> useful if they could compare from a *Business perspective* the pro’s and
>> cons. For example.
>>
>>
>>
>> ·         Which is more effective at producing finished product. (Faster
>> to market)
>>
>> ·         Which is more effective at meeting customer’s needs. (Faster
>> customisations)
>>
>> ·         Solution performance. Which is better. (How snappy is the
>> solution to use)
>>
>> ·         Security. Which is better. (.NET seems inherently flawed in
>> this respect)
>>
>> ·         Deployment. Which is easier?
>>
>> ·         Does the Delphi team sit comfortably alongside the .NET team ?
>>
>> ·         Which product fits better with latest business strategies such
>> as IOT and Cloud ?
>>
>>
>>
>>
>>
>> 3.       Does Seattle have any comparative presentation layer to compete
>> with WPF ? Does anyone used it ? Does it support well MVVM ?
>>
>> 4.       Market credibility for Delphi is low. Most International
>> Corporate clients have never heard of it, and those that have are very
>> cynical. How to overcome this marketing hurdle?
>>
>>
>>
>> 5.       What is the Delphi developers strategy for Cloud deployment ?
>>
>>
>>
>> 6.       Which country has the greatest penetration of Delphi Seattle ?
>> Where are the best developers available ?
>>
>>
>>
>> 7.       How do you feel about the high cost of Delphi compared to VS ?
>>
>>
>>
>> 8.       How is the support for Delphi ? User groups, and Embarcadero
>> maintenance contract ?
>>
>>
>>
>> 9.       And finally:  How is the market availability of Delphi
>> developers these days ?
>>
>>
>>
>> Thanks very much,
>>
>>
>>
>> Tony
>>
>>
>> ------------------------------
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at listserver.123.net.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
>> Subject: unsubscribe
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at listserver.123.net.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
>> Subject: unsubscribe
>>
>
>
> ------------------------------
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20160412/0bb67b61/attachment-0001.html