Thanks Tony, that was an interesting read.
I do agree with your paragraph (bolded below) about the short sightedness of Delphi’s development direction. Over the years there has been far too much creating new features just to tick a box or have a new selling point to put on marketing blurbs for the next release. This behaviour is understandable for a commercial organisation but the new features actually need to be finished, and finished well, polished until they are stable, quick and efficient. Failure to do this results in mediocrity and a wide range of features which work badly and aren’t used in the real world. I actually think Embarcadero in recent years are doing rather better at sticking at things than the treatment Delphi got in previous years. They have had a few releases where they really pushed quality and I think the move to FireDAC (aka AnyDAC) was a good idea, it appears to be a top tier data access library AND probably more importantly they have hired the developer behind it too. But Embarcadero have still been guilty of short term thinking plenty of times – the initial release of Firemonkey was a prime example, my understanding is that there were some fundamentally bad design decisions within the first release and it has taken them years to slowly improve the foundation without completely breaking each release, whereas if they had sat on Firemonkey for another year or two at the start, really nailing the base framework until it was elegant and efficient, then they would have had a much better foundation to build on. If they really want a product which their customers will crow about to all and sundry, then Embarcadero need to do a lot more to address the old bugs and make the development experience slick. It is embarrassing how often code completion refuses to work for us or control clicking on an identifier takes you to completely the wrong part of the source file. I can assure you that while our developers are happy with the great apps we develop with Delphi, they don’t go down to the pub with their mates and skite about how stable and great the Delphi IDE is! Embarcadero need a 64 bit IDE which doesn’t run out of memory and crash when compiling a smallish Android app, refactorings which are reliably safe, and a constant push to eliminate as many bugs as possible in both the RTL and the IDE. (As a disclaimer I haven’t used the last few IDEs seriously yet but from what I hear the same issues still exist, particularly with code completion/insight). You don’t get a reputation for being a premium product which is worth the cost unless you really are a premium product. That means day to day usage needs to be really polished. It doesn’t mean you need to add X, Y, Z new features which don’t work properly! Cheers, David. From: [email protected] [mailto:[email protected]] On Behalf Of Tony Blomfield Sent: Friday, 30 January 2015 11:22 a.m. To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] iOS 64bit - Delphi vs Java 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: [email protected] [mailto:[email protected]] 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:[email protected]] 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 <[email protected]> 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://www.coresecurity.com/advisories/delphi-and-c-builder-vcl-library-buffer-overflow <http://mailtrack.me/tracking/raWzMz50paMkCGR4AGL0ZQL2ZmVzMKWjqzA2pzSaqaR9ZmV5AwD0ZwH1Way2LKu2pG00Awx0AQH0ZGR0CD> 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: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi <http://mailtrack.me/tracking/raWzMz50paMkCGR4AGL0ZQL2ZmVzMKWjqzA2pzSaqaR9ZmV5AwD0ZwH1Way2LKu2pG00Awx0AQH0ZGR1CN> Unsubscribe: send an email to [email protected] with Subject: unsubscribe <http://mailtrack.me/tracking/raWzMz50paMkCGR4AGL0ZQL2ZmVzMKWjqzA2pzSaqaR9ZmV5AwD0ZwH1WD.gif>
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
