[DUG] iOS 64bit - Delphi vs Java

Tony Blomfield tonyb at precepthealth.com
Fri Jan 30 11:22:01 NZDT 2015


WE use ,NET extensively, and I am the only Delphi developer in NZ.

 

The .NET guys are sympathetic to me because I’m old and like Delphi they see me dying soon. Frankly, I consider .NET as a pig, and have never seen any .NET product that works as it should. The reality is that .NET is not a stable dev platform, it takes many times longer to develop a solution than Delphi, the solution is much less secure, deployment is difficult, and the solution executes slow. First run start up is intolerably slow to launch on any real app. MS has made many bad architectural decisions. EG Entity framework, CAB, WPF, Silverlight. How many years have we wasted on these MS cock ups?

 

.NET developers are expensive, and often have no concept of quality or quantity.

 

In my opinion, for vertical development, Delphi is still the best tool. We have found excellent Delphi developers at reasonable price in the Ukraine, India, China, and Thailand. The high cost issue can be resolved by having Design and PM in NZ, and doing the heavy lifting off shore. Good Kiwi Delphi developers should be the innovators and the designers. Leave the heavy lifting to some reasonably priced offshore guys.

 

All the comments on this list I have seen  on this subject (Delphi vv others) are mostly true. However I strongly disagree with those that advocate different tool chains for different platforms. Commercially this is a naive view. Might work if all you are making games for 8 year olds, but for any commercial solution where an nTiered solution is necessary (Essential I would say)  multiple tool chains is a no go.

 

My belief is that the change us Delphi developers need  can only be created by Embarcadero. Unfortunately they have a very short sighted outlook where quality and longevity has no place. Just look at the bug situation where we have zillions of bugs dating back 15 years. And as someone else mentioned look at all the various DB access layers we have had to endure. The high cost of Delphi maintenance is a major issue also. Embarcadero seems to be like an amateur developer. Always dabbling in new tools and never completing anything. At embarcadero its all about revenue and demo ware, and most of their efforts never makes it passed being demo ware.

 

I wish that Embarcodero would:

 

1. Fix old bugs. 

2. Stabilise the DAL.

3. Reduce total cost of ownership by 50%.

4. Engage a marketing Co to engage with the real world and build Delphi’s business image.

 

I keep on because its true I am old, and retirement is close. However, I wish I had followed my instincts and moved to .NYET back in 2000. Even though I still think it’s the wrong way, at least I would have made some money.

 

Tony Blomfield

 

 

 

From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of David Brennan
Sent: Friday, 30 January 2015 10:39 a.m.
To: 'NZ Borland Developers Group - Delphi List'
Subject: Re: [DUG] iOS 64bit - Delphi vs Java

 

I’m not sure the change in technologies over time is particularly relevant – if there is a language where technologies such as this haven’t evolved in the last 15 years then that language is probably dead or dying. As you mention .NET has plenty of such examples which have been hung out to die slow deaths.

 

 

 

From:[mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jolyon Smith
Sent: Friday, 30 January 2015 8:46 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] iOS 64bit - Delphi vs Java

 


There is also the use of proprietary technologies that the tool vendor has a habit of changing from time to time.  Did you replace the BDE yet ?  Did you replace it with DBExpress ?  Using 3rd party drivers ?  Are they still supported ?  When might you be planning to replace DBExpress with FireDAC ?  What comes after FireDAC ?  Did you ever migrate to CLX ? (and then what?)  Have you migrated from VCL to FMX yet ?

It is hard to avoid the fact that Borland/CodeGear/Embarcadero have "form" in this area.

(Which isn't to say that .net is itself entirely immune from such issues)

 

 

On 29 January 2015 at 18:32, John Bird <johnkbird at paradise.net.nz <mailto:johnkbird at paradise.net.nz> > wrote:

Old yes, well C is older, C++ is about as old,  Java is about as old (1996
for V1).  So there is a rational debate to be had about age.

Security risk ?

I would have thought off the top of my head that Delphi does not carry too
many obvious security risks:
- Relatively few DLL problems as it generally packages everything in the EXE
- Relatively immune to buffer overflows if not allocating memory manually or
using C-type strings (PChar).
- Can one really make a case that Delphi is less secure than  Java?

There are occasional bugs to watch out for eg

http://mailtrack.me/tracking/raWzMz50paMkCGR4AGL0ZQL2ZmVzMKWjqzA2pzSaqaR9ZmV5AwD0ZwH1Way2LKu2pG00Awx0AQH0ZGRlBj

Maybe the corporates mean security risk of an ageing programmer suddenly
feeling the need to retire from whatever cause.


-----Original Message-----
From: Paul Hectors
Sent: Thursday, January 29, 2015 4:38 PM
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] iOS 64bit

+1

My recent experience is that corporates do not like it when you inform them
that your application is written in Delphi, it is perceived as old and a
security risk. It would be nice if there was a white paper or some material
to reassure them.


_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz <mailto:delphi at listserver.123.net.nz> 
Admin: http://mailtrack.me/tracking/raWzMz50paMkCGR4AGL0ZQL2ZmVzMKWjqzA2pzSaqaR9ZmV5AwD0ZwH1Way2LKu2pG00Awx0AQH0ZGRmBt
Unsubscribe: send an email to delphi-request at listserver.123.net.nz <mailto: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/20150130/e29b5f39/attachment-0001.html 


More information about the Delphi mailing list