Re: [DUG] Embarcadero article
Personally I don't care much about 64 bit. Cross platform would be nice, but realistically we have 1 or 2 inquiries out of hundreds regarding support for mac or linux - no one has ever asked me about when we are going to support 64 bit. What I want to see in future versions of Delphi is stuff that increases my productivity. Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington Malcolm Groves wrote: Hi Jolyon, As I said, we'll continue to listen and course correct. Feedback we're getting from customers and potential customers worldwide is that cross platform is a higher priority. I don't deny that there are people who desperately want 64 bit, I know people in that boat around Asia. Perhaps those who want cross platform more haven't taken the time to vote on your poll. The ratio of responses on this list has also been interesting. I am genuinely sorry that we can't get them both out earlier, and I sincerely hope this decision doesn't make it impossible for you to use Delphi. Ultimately though, all we can do is gather as much data as possible make the best decision we can, and then adjust as we go. That's what we're doing. Cheers Malcolm CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
What I want to know is, when are Embarcadero going to support interfaces on TObject? Todd. Personally I don't care much about 64 bit. Cross platform would be nice, but realistically we have 1 or 2 inquiries out of hundreds regarding support for mac or linux - no one has ever asked me about when we are going to support 64 bit. What I want to see in future versions of Delphi is stuff that increases my productivity. Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington Malcolm Groves wrote: Hi Jolyon, As I said, we'll continue to listen and course correct. Feedback we're getting from customers and potential customers worldwide is that cross platform is a higher priority. I don't deny that there are people who desperately want 64 bit, I know people in that boat around Asia. Perhaps those who want cross platform more haven't taken the time to vote on your poll. The ratio of responses on this list has also been interesting. I am genuinely sorry that we can't get them both out earlier, and I sincerely hope this decision doesn't make it impossible for you to use Delphi. Ultimately though, all we can do is gather as much data as possible make the best decision we can, and then adjust as we go. That's what we're doing. Cheers Malcolm CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
+1 to productivity enhancements. I don't care about 64 bit (yet), and linux/mac support is interesting but not essential (smart phone support I would kill for). Garbage collection is what I really want, but it's a long way down the list of what will ever get added to Delphi :( Regards Sean Cross CIO Catalyst Risk Management -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Alister Christie Sent: Wednesday, 17 June 2009 11:55 a.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Personally I don't care much about 64 bit. Cross platform would be nice, but realistically we have 1 or 2 inquiries out of hundreds regarding support for mac or linux - no one has ever asked me about when we are going to support 64 bit. What I want to see in future versions of Delphi is stuff that increases my productivity. Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
TObject *does* support interfaces, it simply doesn't *implement* any. I guess what you mean is, when will TObject implement IUnknown and I think the answer to that is a question: Why would it?. TInterfacedObject is a TObject specialisation that implements IUnknown, so if you need a TObject class that can implement interfaces, just derive from TInterfacedObject instead. It does exactly what it says on the tin. :) Then if you want a TObject derived class that *doesn't* implement any interfaces (e.g. because it's lifetime is explicitly or more complexly managed, eg. In a object pool/caching framework), or to which you wish to add an IUnknown implementation that doesn't implement reference counted lifetime management, for example, then you can still do that in exactly the same way that TInterfacedObject does, but providing your own AddRef() and Release() implementation. If TObject implemented IUnknown then *every* class would inherit that implementation, whether it was appropriate to any specific class or not. As it is, we can - if we wish - derive classes with interface support that do not implement non-reference counted lifetime management (I have my own TObject derived class which does this and provides a base class for all such classes that I need, in the same way that TInterfacedObject provides the base class for all reference counted classes that implement interfaces). Personally I'm grateful for the choice. :) -- Smile, they said. it could be worse! So I did. And it was. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Todd Martin Sent: Wednesday, 17 June 2009 12:54 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article What I want to know is, when are Embarcadero going to support interfaces on TObject? Todd. Personally I don't care much about 64 bit. Cross platform would be nice, but realistically we have 1 or 2 inquiries out of hundreds regarding support for mac or linux - no one has ever asked me about when we are going to support 64 bit. What I want to see in future versions of Delphi is stuff that increases my productivity. Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington Malcolm Groves wrote: Hi Jolyon, As I said, we'll continue to listen and course correct. Feedback we're getting from customers and potential customers worldwide is that cross platform is a higher priority. I don't deny that there are people who desperately want 64 bit, I know people in that boat around Asia. Perhaps those who want cross platform more haven't taken the time to vote on your poll. The ratio of responses on this list has also been interesting. I am genuinely sorry that we can't get them both out earlier, and I sincerely hope this decision doesn't make it impossible for you to use Delphi. Ultimately though, all we can do is gather as much data as possible make the best decision we can, and then adjust as we go. That's what we're doing. Cheers Malcolm CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
aiui, you'll be seeing a delivery for your productivity concerns very soon, the Weaver release. And some of the enhancements coming in the IDE look very interesting, as do the far reaching extensions to the RTTI system and long overdue encapsulation of the OpenTools API (which in turn will likely open the door for 3rd party IDE productivity improvement projects). Project X (xplat) and Project Commodore (64-bit) do not impinge on Project Weaver (or indeed on Project Chromium (VS2010 support for Prism)). -- Smile, they said. it could be worse! So I did. And it was. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Alister Christie Sent: Wednesday, 17 June 2009 11:55 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Personally I don't care much about 64 bit. Cross platform would be nice, but realistically we have 1 or 2 inquiries out of hundreds regarding support for mac or linux - no one has ever asked me about when we are going to support 64 bit. What I want to see in future versions of Delphi is stuff that increases my productivity. Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington Malcolm Groves wrote: Hi Jolyon, As I said, we'll continue to listen and course correct. Feedback we're getting from customers and potential customers worldwide is that cross platform is a higher priority. I don't deny that there are people who desperately want 64 bit, I know people in that boat around Asia. Perhaps those who want cross platform more haven't taken the time to vote on your poll. The ratio of responses on this list has also been interesting. I am genuinely sorry that we can't get them both out earlier, and I sincerely hope this decision doesn't make it impossible for you to use Delphi. Ultimately though, all we can do is gather as much data as possible make the best decision we can, and then adjust as we go. That's what we're doing. Cheers Malcolm CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Garbage collection is what I really want, but it's a long way down the list of what will ever get added to Delphi :( Then use C#. I want Delphi as a C++ replacement with as few compromises as possible, not C#. That said, the C# programming model has things I wouldnt mind in the language - data bound objects, decent object inspector and the dynamic interface thingies. Of course, if you are doing 64 bit, would MPI support be too much to ask as well? -- Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232 Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
If you want garbage collection use Prism and run your apps in a managed
environment where garbage collection makes as much sense as it ever will on
current hardware.
In the meantime you can introduce garbage collection into your own code
quite easily by following a few simple patterns, with the added benefit that
your garbage will be collected deterministically.
Example:
In one project I am involved in, we are replacing ALL our database access
code with a new abstraction framework, part of which has involved
introducing a factory for all SQL queries and commands, yielding interfaces
to those objects:
Old code:
Var
Qry: TQuery;
Begin
Qry := TQuery.Create(TheTDatabase);
Try
Qry.SQL.Text := 'some SQL';
// Do work with qry
Finally
Qry.Free;
End;
End;
New code:
Var
Qry: IQuery;
Begin
Qry := Database.Query('some SQL');
// Do work with qry
End;
Not only does this remove a lot of boilerplate try/finally from our data
access code, but that Database.Query() factory method represents some
additional, not immediately obvious benefits. Namely that once all
references to any query object have been released, the object is not
immediately Free'd, but instead lives on in a pool.
(this is possible because we implement our own IUnknown for these objects,
rather than using the simple ref counted lifetime management implemented by
TInterfacedObject)
The pool is flushed periodically, but if some code later requests a query
for 'some SQL' from the pool, and if the required SQL object still resides
in the pool, it can be retrieved without having to create a new TQuery,
assigning the SQL and re-preparing that statement on the server etc.
The pool also takes care of re-use issues.
That is, if 'some SQL' exists in the pool but is already in use (we track
that via reference count) then the factory will yield a new, non-pooled
query object rather than returning a reference to the already in-use query
(since nested/recursive uses of the same query objects will almost certainly
cause problems).
A previous caching mechanism that was used in the code did not make such
allowances and occasionally caused problems when some code called for a
cached query but was unaware that somewhere up the call stack some other
code was already working with that same cached query. Interfaces provide
the automatic reference tracking that allows this mechanism to be reliable
in the new implementation - the previous caching implementation could have
implemented something similar but would have been vulnerable to people
forgetting to call Free when finished working with a cached query.
So, we got garbage collection (not universal, but for this VERY common
aspect of our code) AND performance improvements AND a less error prone
infrastructure.
And all without having to sit around waiting for CodeGear to add stuff (all
this in code that will compile and run beautifully in Delphi 3 ... if it had
been necessary).
:)
--
Smile, they said. it could be worse!
So I did. And it was
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
Re: [DUG] Embarcadero article
I do use C# where it makes sense. It just doesn't make sense for the sort of shareware and desktop apps I mostly do. I have never understood the fanatical hatred of garbage collection that some Delphi developers have (not aimed at anyone in particular but if you either try discussing gc in non-technical, you will get a large amount of vitriol heading your way). It makes some things much easier, and some things harder. Optional GC such as in D seems reasonable to me, but apparently not to everyone. Regards Sean Cross CIO Catalyst Risk Management -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Phil Scadden Sent: Wednesday, 17 June 2009 1:33 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Garbage collection is what I really want, but it's a long way down the list of what will ever get added to Delphi :( Then use C#. I want Delphi as a C++ replacement with as few compromises as possible, not C#. That said, the C# programming model has things I wouldnt mind in the language - data bound objects, decent object inspector and the dynamic interface thingies. Of course, if you are doing 64 bit, would MPI support be too much to ask as well? -- Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232 Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
I have never understood the fanatical hatred of garbage collection that some Delphi developers have Its horses for courses. For predominantly UI based programming, speed is no issue and GC fine. - and for that matter C# very fine. Combinations of large, complex datastructure and cpu intensive calculation (solve a PDE) and GC seems to really slow things done. Maybe its the threading model in combination, I dont know. That said, its a few years since seriously experimented. Faced with multi-platform, 64bit, MPI, all that kind of coding moved to C++ and VS. Coding is a pain compared to Delphi but VS has some very nice features for debugging in this environment. Virgin UI programs get done in either C# or web/js. Component libraries is what delphi programming going. Got a whole lot of stuff that I dont have C++ or C# that's remotely as capable (same argument keeps the Fortran going too). -- Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232 Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
I think the vitriol stems from the idea that people believe (and I think rightly) that the sort of garbage collection that people are asking for is largely an all or nothing affair. i.e. if it's added to the language to please those who want GC (but who - for some reason - aren't inclined to simply use a runtime environment provides exactly what they say they want) then that this necessarily pollutes the language for those who feel that Garbage Collection comes at too high a price and is just pandering to the inherent laziness in all of us (myself included - I'd love to be able to think less, but I know that I'd make more mistakes if I did, not less). The distrust of GC as a technology amongst experienced practitioners (as it typically is) of the black arts of software development stems from: - less efficient use of memory (*) - unpredictably distributed performance across application usage (*) - loss of determinism (debugging complexity) (*) GC assumes a vast over supply of RAM and an availability of application idle cycles in which to recover wastefully over-allocated RAM. The beauty of the GC framework (ref counted lifetime managed via interfaces) that Delphi ALREADY OFFERS (!) is that: - as you say with 'D', it's optional :) - it remains deterministic So don't you already have what you want? All you have to do now is use it. :) -- Smile, they said. it could be worse! So I did. And it was. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Sean Cross Sent: Wednesday, 17 June 2009 14:02 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article I do use C# where it makes sense. It just doesn't make sense for the sort of shareware and desktop apps I mostly do. I have never understood the fanatical hatred of garbage collection that some Delphi developers have (not aimed at anyone in particular but if you either try discussing gc in non-technical, you will get a large amount of vitriol heading your way). It makes some things much easier, and some things harder. Optional GC such as in D seems reasonable to me, but apparently not to everyone. Regards Sean Cross CIO Catalyst Risk Management -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Phil Scadden Sent: Wednesday, 17 June 2009 1:33 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Garbage collection is what I really want, but it's a long way down the list of what will ever get added to Delphi :( Then use C#. I want Delphi as a C++ replacement with as few compromises as possible, not C#. That said, the C# programming model has things I wouldnt mind in the language - data bound objects, decent object inspector and the dynamic interface thingies. Of course, if you are doing 64 bit, would MPI support be too much to ask as well? -- Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232 Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
I don't want to get to deep into a discussion of this, the last time I got into a discussion on GC in non technical, I lost days of my life. However: - Suggesting that I move to prism to get a gc makes as much sense as suggesting that you move to c++ to get a 64 bit compiler - As Phil said It's horse for courses. In the areas you work in, gc is obviously of no use. In the areas I mostly work in, it would make my life much easier. - Personally I get tired of the GC = laziness argument. It's dismissive without any real thought. - I do know how to use reference counted interfaces and smart pointers. I use them for some things. However reference counting doesn't work for circular references without a lot of additional work. Adding to the opf I use would take more time than it would save. Regards Sean Cross CIO Catalyst Risk Management -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Jolyon Smith Sent: Wednesday, 17 June 2009 2:28 p.m. To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Embarcadero article I think the vitriol stems from the idea that people believe (and I think rightly) that the sort of garbage collection that people are asking for is largely an all or nothing affair. i.e. if it's added to the language to please those who want GC (but who - for some reason - aren't inclined to simply use a runtime environment provides exactly what they say they want) then that this necessarily pollutes the language for those who feel that Garbage Collection comes at too high a price and is just pandering to the inherent laziness in all of us (myself included - I'd love to be able to think less, but I know that I'd make more mistakes if I did, not less). The distrust of GC as a technology amongst experienced practitioners (as it typically is) of the black arts of software development stems from: - less efficient use of memory (*) - unpredictably distributed performance across application usage (*) - loss of determinism (debugging complexity) (*) GC assumes a vast over supply of RAM and an availability of application idle cycles in which to recover wastefully over-allocated RAM. The beauty of the GC framework (ref counted lifetime managed via interfaces) that Delphi ALREADY OFFERS (!) is that: - as you say with 'D', it's optional :) - it remains deterministic So don't you already have what you want? All you have to do now is use it. :) -- Smile, they said. it could be worse! So I did. And it was. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Sean Cross Sent: Wednesday, 17 June 2009 14:02 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article I do use C# where it makes sense. It just doesn't make sense for the sort of shareware and desktop apps I mostly do. I have never understood the fanatical hatred of garbage collection that some Delphi developers have (not aimed at anyone in particular but if you either try discussing gc in non-technical, you will get a large amount of vitriol heading your way). It makes some things much easier, and some things harder. Optional GC such as in D seems reasonable to me, but apparently not to everyone. Regards Sean Cross CIO Catalyst Risk Management -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Phil Scadden Sent: Wednesday, 17 June 2009 1:33 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Garbage collection is what I really want, but it's a long way down the list of what will ever get added to Delphi :( Then use C#. I want Delphi as a C++ replacement with as few compromises as possible, not C#. That said, the C# programming model has things I wouldnt mind in the language - data bound objects, decent object inspector and the dynamic interface thingies. Of course, if you are doing 64 bit, would MPI support be too much to ask as well? -- Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232 Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group
Re: [DUG] Embarcadero article
Hi Sean I agree with you, GC is good to have at times. What I am suggesting would allow Delphi to switch on GC, for those that want it, or off, for those that don't. Or even better, provide GC (or not) for a subset of registered classes. Can anyone complain about that? If Delphi provided a notification system which dispatched an event whenever a reference was added or released on a TObject instance, there would be no need for IInterface/IUnknown. TObject would not need any extra methods and therefore would not incur any overhead. Todd. I don't want to get to deep into a discussion of this, the last time I got into a discussion on GC in non technical, I lost days of my life. However: - Suggesting that I move to prism to get a gc makes as much sense as suggesting that you move to c++ to get a 64 bit compiler - As Phil said It's horse for courses. In the areas you work in, gc is obviously of no use. In the areas I mostly work in, it would make my life much easier. - Personally I get tired of the GC = laziness argument. It's dismissive without any real thought. - I do know how to use reference counted interfaces and smart pointers. I use them for some things. However reference counting doesn't work for circular references without a lot of additional work. Adding to the opf I use would take more time than it would save. Regards Sean Cross CIO Catalyst Risk Management -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Jolyon Smith Sent: Wednesday, 17 June 2009 2:28 p.m. To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Embarcadero article I think the vitriol stems from the idea that people believe (and I think rightly) that the sort of garbage collection that people are asking for is largely an all or nothing affair. i.e. if it's added to the language to please those who want GC (but who - for some reason - aren't inclined to simply use a runtime environment provides exactly what they say they want) then that this necessarily pollutes the language for those who feel that Garbage Collection comes at too high a price and is just pandering to the inherent laziness in all of us (myself included - I'd love to be able to think less, but I know that I'd make more mistakes if I did, not less). The distrust of GC as a technology amongst experienced practitioners (as it typically is) of the black arts of software development stems from: - less efficient use of memory (*) - unpredictably distributed performance across application usage (*) - loss of determinism (debugging complexity) (*) GC assumes a vast over supply of RAM and an availability of application idle cycles in which to recover wastefully over-allocated RAM. The beauty of the GC framework (ref counted lifetime managed via interfaces) that Delphi ALREADY OFFERS (!) is that: - as you say with 'D', it's optional :) - it remains deterministic So don't you already have what you want? All you have to do now is use it. :) -- Smile, they said. it could be worse! So I did. And it was. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Sean Cross Sent: Wednesday, 17 June 2009 14:02 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article I do use C# where it makes sense. It just doesn't make sense for the sort of shareware and desktop apps I mostly do. I have never understood the fanatical hatred of garbage collection that some Delphi developers have (not aimed at anyone in particular but if you either try discussing gc in non-technical, you will get a large amount of vitriol heading your way). It makes some things much easier, and some things harder. Optional GC such as in D seems reasonable to me, but apparently not to everyone. Regards Sean Cross CIO Catalyst Risk Management -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Phil Scadden Sent: Wednesday, 17 June 2009 1:33 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Garbage collection is what I really want, but it's a long way down the list of what will ever get added to Delphi :( Then use C#. I want Delphi as a C++ replacement with as few compromises as possible, not C#. That said, the C# programming model has things I wouldnt mind in the language - data bound objects, decent object inspector and the dynamic interface thingies. Of course, if you are doing 64 bit, would MPI support be too much to ask as well? ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject
Re: [DUG] Embarcadero article
I am using MemChk to solve GC in Delphi ;-) I think no overhead. Have a nice day Regards Leigh www.smootharm.com -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz]on Behalf Of Todd Martin Sent: Wednesday, 17 June 2009 3:16 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Hi Sean I agree with you, GC is good to have at times. What I am suggesting would allow Delphi to switch on GC, for those that want it, or off, for those that don't. Or even better, provide GC (or not) for a subset of registered classes. Can anyone complain about that? If Delphi provided a notification system which dispatched an event whenever a reference was added or released on a TObject instance, there would be no need for IInterface/IUnknown. TObject would not need any extra methods and therefore would not incur any overhead. Todd. I don't want to get to deep into a discussion of this, the last time I got into a discussion on GC in non technical, I lost days of my life. However: - Suggesting that I move to prism to get a gc makes as much sense as suggesting that you move to c++ to get a 64 bit compiler - As Phil said It's horse for courses. In the areas you work in, gc is obviously of no use. In the areas I mostly work in, it would make my life much easier. - Personally I get tired of the GC = laziness argument. It's dismissive without any real thought. - I do know how to use reference counted interfaces and smart pointers. I use them for some things. However reference counting doesn't work for circular references without a lot of additional work. Adding to the opf I use would take more time than it would save. Regards Sean Cross CIO Catalyst Risk Management -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Jolyon Smith Sent: Wednesday, 17 June 2009 2:28 p.m. To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Embarcadero article I think the vitriol stems from the idea that people believe (and I think rightly) that the sort of garbage collection that people are asking for is largely an all or nothing affair. i.e. if it's added to the language to please those who want GC (but who - for some reason - aren't inclined to simply use a runtime environment provides exactly what they say they want) then that this necessarily pollutes the language for those who feel that Garbage Collection comes at too high a price and is just pandering to the inherent laziness in all of us (myself included - I'd love to be able to think less, but I know that I'd make more mistakes if I did, not less). The distrust of GC as a technology amongst experienced practitioners (as it typically is) of the black arts of software development stems from: - less efficient use of memory (*) - unpredictably distributed performance across application usage (*) - loss of determinism (debugging complexity) (*) GC assumes a vast over supply of RAM and an availability of application idle cycles in which to recover wastefully over-allocated RAM. The beauty of the GC framework (ref counted lifetime managed via interfaces) that Delphi ALREADY OFFERS (!) is that: - as you say with 'D', it's optional :) - it remains deterministic So don't you already have what you want? All you have to do now is use it. :) -- Smile, they said. it could be worse! So I did. And it was. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Sean Cross Sent: Wednesday, 17 June 2009 14:02 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article I do use C# where it makes sense. It just doesn't make sense for the sort of shareware and desktop apps I mostly do. I have never understood the fanatical hatred of garbage collection that some Delphi developers have (not aimed at anyone in particular but if you either try discussing gc in non-technical, you will get a large amount of vitriol heading your way). It makes some things much easier, and some things harder. Optional GC such as in D seems reasonable to me, but apparently not to everyone. Regards Sean Cross CIO Catalyst Risk Management -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Phil Scadden Sent: Wednesday, 17 June 2009 1:33 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Garbage collection is what I really want, but it's a long way down the list of what will ever get added to Delphi :( Then use C#. I want Delphi as a C++ replacement with as few compromises as possible, not C#. That said, the C# programming model has things I wouldnt mind in the language - data bound objects, decent object inspector and the dynamic interface thingies. Of course, if you are doing 64
Re: [DUG] Embarcadero article
I just don't see it working unless it is possible to take sophisticated applications using the current VCL (ie VCL32) and with some effort but not a complete rewrite (ie NOT replacing the entire component library!) modify the code using ifdefs etc so that you have single source that can compile to either platform. Similarly third party providers (eg DevExpress) need to be able to produce single source versions of their libraries fairly easily. As far as I can tell they are producing a completely new VCL for the Mac just like CLX was for Kylix... if so then that means they are only targeting new applications which is a fatal mistake IMO. Of course doing what I suggest (making the new Mac VCL compatible with the existing VCL32 BUT still making it appear native on other targets) is probably at least an order of magnitude harder than what they are trying... but if they don't then I don't really see the point. Interested to hear what others think. Cheers, David. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Kurt Sent: Saturday, 13 June 2009 7:24 p.m. To: NZ Borland Developers Group - Delphi List Subject: [DUG] Embarcadero article From http://www.theregister.co.uk/2009/06/12/embarcadero_codegear_tools_future/ Embarcadero is now betting on cross-platform for Delphi and its partner C++ Builder, which shares many of the same libraries. 'The most important thing is native cross-platform, Mac and Linux. Some of our biggest customers have moved completely to Mac. Internationally we don't hear as much Mac interest, but Linux is really strong,' Williams said. Wasn't this tried before, at least on Linux, with a 2001 product called Kylix, which nobody bought? 'Two big differences,' according to Williams, at least. 'First, that wasn't a cross-compile approach. People are fine developing on Windows. I need to be able to debug against a remote machine, but I don't need the whole IDE over there. The other difference [is] they were too early as far as Linux goes, and from a visual standpoint now Mac matters. I've never been so sure about an opportunity.' cheers, Kurt ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Do it properly or don't even bother. That is my advice to them. On Mon, Jun 15, 2009 at 4:02 PM, David Brennandugda...@dbsolutions.co.nz wrote: I just don't see it working unless it is possible to take sophisticated applications using the current VCL (ie VCL32) and with some effort but not a complete rewrite (ie NOT replacing the entire component library!) modify the code using ifdefs etc so that you have single source that can compile to either platform. Similarly third party providers (eg DevExpress) need to be able to produce single source versions of their libraries fairly easily. As far as I can tell they are producing a completely new VCL for the Mac just like CLX was for Kylix... if so then that means they are only targeting new applications which is a fatal mistake IMO. Of course doing what I suggest (making the new Mac VCL compatible with the existing VCL32 BUT still making it appear native on other targets) is probably at least an order of magnitude harder than what they are trying... but if they don't then I don't really see the point. Interested to hear what others think. Cheers, David. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Kurt Sent: Saturday, 13 June 2009 7:24 p.m. To: NZ Borland Developers Group - Delphi List Subject: [DUG] Embarcadero article From http://www.theregister.co.uk/2009/06/12/embarcadero_codegear_tools_future/ Embarcadero is now betting on cross-platform for Delphi and its partner C++ Builder, which shares many of the same libraries. 'The most important thing is native cross-platform, Mac and Linux. Some of our biggest customers have moved completely to Mac. Internationally we don't hear as much Mac interest, but Linux is really strong,' Williams said. Wasn't this tried before, at least on Linux, with a 2001 product called Kylix, which nobody bought? 'Two big differences,' according to Williams, at least. 'First, that wasn't a cross-compile approach. People are fine developing on Windows. I need to be able to debug against a remote machine, but I don't need the whole IDE over there. The other difference [is] they were too early as far as Linux goes, and from a visual standpoint now Mac matters. I've never been so sure about an opportunity.' cheers, Kurt ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
| I just don't see it working unless it is possible to take | sophisticated applications using the current VCL (ie VCL32) and | with some effort but not a complete rewrite snip modify the | code using ifdefs etc so that you have single source that can compile | to either platform. I disagree. This is exactly the approach that Borland tried to take with VCL.NET with disastrous results. Even in that case, where the GUI toolkit was essentially the same, a simple recompile for this platform approach results in an application that is not well suited for the platform at all. Far from it. In the case of the Mac and Linux, those platforms are also quite visually different and in the case of the Mac in particular provide a quite different interaction with the user in many cases. How would you single-source VCL apps that assume a regular 3 button mouse with chording support when running on a 1 button Mac or even a Mighty Mouse equipped Mac? It's not necessarily a simple question of $ifdef'ing some event handling code - the different user input devices (and the difference in available user input/interaction controls, if you wish to exploit the native look and feel of the respective platforms) mean that you will almost certainly need to implement a quite different GUI on each version. Either that or dumb your GUI down to the lowest common denominator, resulting in an app that is unacceptably retarded in the UI department to be considered appealing on any of the platforms you choose to support. (for simple apps this might be viable, but you specifically referenced sophisticated applications, and this is my area of interest also). Any NON-visual code should be easily single-source'able, but the V part of the VCL really has to be different for each platform. Visual classes will, by definition, need to be different from platform to platform because, visually, those platforms ARE different. Didn't CLX try to achieve single source cross platform support? How did that work out again? ;) -- Smile, they said it could be worse! So I did. And it was. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Ummm...maybe they should hire someone from the Lazarus project to help them. That compiles the same code (give or take a few exceptions) to just about anything...except Blackfin devices so I have found out. ...grrr Jeremy -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Jolyon Smith Sent: 15 June 2009 20:03 To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Embarcadero article | I just don't see it working unless it is possible to take | sophisticated applications using the current VCL (ie VCL32) and with | some effort but not a complete rewrite snip modify the code using | ifdefs etc so that you have single source that can compile to either | platform. I disagree. This is exactly the approach that Borland tried to take with VCL.NET with disastrous results. Even in that case, where the GUI toolkit was essentially the same, a simple recompile for this platform approach results in an application that is not well suited for the platform at all. Far from it. In the case of the Mac and Linux, those platforms are also quite visually different and in the case of the Mac in particular provide a quite different interaction with the user in many cases. How would you single-source VCL apps that assume a regular 3 button mouse with chording support when running on a 1 button Mac or even a Mighty Mouse equipped Mac? It's not necessarily a simple question of $ifdef'ing some event handling code - the different user input devices (and the difference in available user input/interaction controls, if you wish to exploit the native look and feel of the respective platforms) mean that you will almost certainly need to implement a quite different GUI on each version. Either that or dumb your GUI down to the lowest common denominator, resulting in an app that is unacceptably retarded in the UI department to be considered appealing on any of the platforms you choose to support. (for simple apps this might be viable, but you specifically referenced sophisticated applications, and this is my area of interest also). Any NON-visual code should be easily single-source'able, but the V part of the VCL really has to be different for each platform. Visual classes will, by definition, need to be different from platform to platform because, visually, those platforms ARE different. Didn't CLX try to achieve single source cross platform support? How did that work out again? ;) -- Smile, they said it could be worse! So I did. And it was. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Fair points, but then it isn't really cross platform is it if you can't single source your application? It is just one more way to develop applications for Macs or Linux. Now maybe if there is a real dearth of visual development tools for those OS's then it makes business sense for them to try to fill that niche... but without single source compilation to multiple platforms doesn't it become rather incidental that it is Delphi? For what it is worth the reason CLX died in my view was that it was a completely new VCL. For us to use it we would have had to completely redo the interface for our application which made it something we never even considered. As for VCL.NET, the reason that died is that there was very little point in it. If you could already compile your Delphi application and run it on a Win32 computer then do you really care about running the same application more slowly under .NET on a Win32 computer? BTW I agree with you that you want the application to look native on each OS if you can manage it. I also agree that user interaction schemes differ etc. I don't know what the answer is to all this. I do know that we wouldn't mind compiling our application to run on different OS's BUT we have no interest at all in developing and maintaining multiple GUI's for it. This probably means we aren't the target audience which makes sense to me - I just don't know who is the target audience. David. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Jolyon Smith Sent: Monday, 15 June 2009 8:03 p.m. To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Embarcadero article | I just don't see it working unless it is possible to take | sophisticated applications using the current VCL (ie VCL32) and | with some effort but not a complete rewrite snip modify the | code using ifdefs etc so that you have single source that can compile | to either platform. I disagree. This is exactly the approach that Borland tried to take with VCL.NET with disastrous results. Even in that case, where the GUI toolkit was essentially the same, a simple recompile for this platform approach results in an application that is not well suited for the platform at all. Far from it. In the case of the Mac and Linux, those platforms are also quite visually different and in the case of the Mac in particular provide a quite different interaction with the user in many cases. How would you single-source VCL apps that assume a regular 3 button mouse with chording support when running on a 1 button Mac or even a Mighty Mouse equipped Mac? It's not necessarily a simple question of $ifdef'ing some event handling code - the different user input devices (and the difference in available user input/interaction controls, if you wish to exploit the native look and feel of the respective platforms) mean that you will almost certainly need to implement a quite different GUI on each version. Either that or dumb your GUI down to the lowest common denominator, resulting in an app that is unacceptably retarded in the UI department to be considered appealing on any of the platforms you choose to support. (for simple apps this might be viable, but you specifically referenced sophisticated applications, and this is my area of interest also). Any NON-visual code should be easily single-source'able, but the V part of the VCL really has to be different for each platform. Visual classes will, by definition, need to be different from platform to platform because, visually, those platforms ARE different. Didn't CLX try to achieve single source cross platform support? How did that work out again? ;) -- Smile, they said it could be worse! So I did. And it was. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
David Brennan wrote: I just don't see it working unless it is possible to take sophisticated applications using the current VCL (ie VCL32) and with some effort but not a complete rewrite (ie NOT replacing the entire component library!) modify the code using ifdefs etc so that you have single source that can compile to either platform. Similarly third party providers (eg DevExpress) need to be able to produce single source versions of their libraries fairly easily. As far as I can tell they are producing a completely new VCL for the Mac just like CLX was for Kylix... if so then that means they are only targeting new applications which is a fatal mistake IMO. Of course doing what I suggest (making the new Mac VCL compatible with the existing VCL32 BUT still making it appear native on other targets) is probably at least an order of magnitude harder than what they are trying... but if they don't then I don't really see the point. The VCL is far too tightly coupled with Windows (e.g. depending on deep internal ordering of Windows message delivery, etc.) for a IFDEF/recompile to ever work. Trying to design and build a cross-platform GUI library ahead of time is a pretty big engineering effort - it's essentially TrollTech's (now owned by Nokia) entire claim to fame with Qt and they had a lot of people working full-time on it. That's probably why Borland picked Qt to underly CLX. Trying to take a Windows-specific library that was never originally designed to be cross-platform, and make it seamlessly cross-platform after the fact is an even bigger engineering effort. Effectively, you're reimplementing large portions of the Windows API on Mac and Linux. And the WINE project already attempts to do that and look how much engineering effort that has taken. Even if they did manage to pull that miracle off, the end result would be so full of 'Windows-isms' that the resulting app it always a second class citizen on the platform. And then there is the Gnome (Gtk) /KDE (Qt) split in the Linux sphere. If you want to deliver a VCL Win32 application on Linux or Mac with minimal effort, the only real answer is to use WINE. I think CLX failed because it tried to kinda-sorta-be-like the VCL but the illusion was pretty thin and only possible at all because CLX was so dumbed down that no existing VCL Windows app could reasonably target it. Also, by burying Qt under a translation layer, no Linux app wanted to target it either since as Qt evolved, CLX lagged behind and would always be a second class KDE citizen. And that's if you were happy with a Qt-based app in the first place on Linux since you had the GNOME vs KDE flamewar. That's died down a little now that Qt is finally LGPL but it's still a Linux platform issue. I don't know how Embarcadero is going to tackle that one. As such, it will be interesting to see what Embarcadero does with Linux given the lack of common GUI frameworks. They may have decided to bypass them and build directly on X-Windows with appropriate extra support to wire themselves into GNOME or KDE theming and configuation as necessary. Project X is a rather suspicious title in that regard :-) Cheers, Paul. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
[Reply] At 21:05 on 15/06/2009 Paul wrote Project X is a rather suspicious title in that regard :-) Insightful as ever Paul! kr Gary Ref#: 41006 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Fair points, but then it isn't really cross platform is it if you can't single source your application? I suppose it depends if you demand 100% single source. :) Having a split 90/10, 80/20 or even 50/50 of cross platform/platform specific code in an application is surely better than 0/100 if you have cross platform needs to meet, especially if the platform specific code in those 10, 20 or 50 splits means that your application looks and behaves as well as it is possibly able to on each platform? But I agree that cross platform probably means different things to different people/applications. To me it should mean more than platform neutral (in terms of OS platform). It should mean that my application is available on Windows, Mac and/or Linux, and in each of those environments it should behave as a user of that environment would expect, FULLY exploiting the facilities of that environment and enable my application to be regarded as a Good Citizen, one that potential customers/users will wish to spend time with and hopefully) money on. That HAS to mean a bit of extra legwork on my part, because magic boxes that can do that simply don't exist. Precisely HOW much extra legwork I will have to put in will depend on the way I put my app together. And of course, whether that legwork is worth the effort will depend on how much - in $$$ terms - those various other platforms are actually or potentially worth, to me. But I think simply aiming for (OS) platform neutrality would be a mistake as it would pitch Delphi up against Java, which is a battle it simply cannot win. Not least because those who need, or have needed, that platform neutrality long since turned to Java for that and are not going to turn their backs on it in a hurry. Not, that is, unless Delphi offers something that Java doesn't. Access to platform specific richness in the GUI whilst easily enabling code sharing across those platforms, I believe, is the Unique Selling Point that Delphi must aim to achieve. Along with the performance that comes with native code, of course. But that alone clearly isn't enough (otherwise Java/.NET et al wouldn't have gotten where they have) But at the end of the day, that's just my 2 cents. :) In the meantime I am personally dismayed that 64-bit is now considered a lower priority than Mac or Linux support. We have customers that NEED 64-bit support. They need it more than they need Mac or Linux support and indeed more than they needed Unicode. I can only hope that Embarcadero have VERY good information about their market place on which they based this decision, because it doesn't reflect the needs that I hear expressed. -- Smile, they said it could be worse! So I did. And it was. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Project X is a rather suspicious title in that regard :-) Hmmm, one might speculate that the project name is itself cross-platform and loaded with hidden meaning : OS X X-Windows 10 = X in Roman Numerals .. 20 of course = 2 x 10 .. 2 additional X platforms are in the cross[sic]-hairs) ... 2010 release Oooh the numerologists are gonna have a field day with this one! Or maybe they just couldn't think of a name, called it X to be going on with, and it just, yaknow, stuck. he-he :) -- Smile, they said it could be worse! So I did. And it was. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Jolyon wrote: Project X is a rather suspicious title in that regard :-) Hmmm, one might speculate that the project name is itself cross-platform and loaded with hidden meaning : OS X X-Windows 10 = X in Roman Numerals .. 20 of course = 2 x 10 .. 2 additional X platforms are in the cross[sic]-hairs) ... 2010 release Oooh the numerologists are gonna have a field day with this one! Or maybe they just couldn't think of a name, called it X to be going on with, and it just, yaknow, stuck. I think you're probably right actually. From the blog posts (hah!), Project X is supposedly a cross-platform GUI controlset for OSX, Linux (i.e. X-Windows) AND Windows. So it looks like they're designing their own native cross-platform toolkit from the top before the fact. They may well have come to the decision that layering over Qt was too problematic and they're better to build their own from the ground up - sort of a CLX done properly with no nasty bits. Since they have their own compilers, they don't need the hoary kludge that is moc and the sucky string based signals/slots, etc. that Qt requires to be portable across C++ compilers. The interesting issue is that if Project X 'works' as a 'VCL - the Next Generation', the current VCL becomes a Windows-only parallel framework for Delphi going forward. Then depending on who keeps buying Delphi, the VCL might become a legacy framework since Embarcadero will focus their engineering dollars where the most customer revenue is. If Project 'X' is highly successful (which Embarcadero obviously hopes is the case) and the VCL/NG Linux and OSX Delphi developer base grows strongly, the VCL might become the red-haired step-child with waning Embarcadero and 3rd party component vendor support. Cheers, Paul. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
You can't single source a gui unless it is very basic. OSX has a completely different look and feel than Windows that goes deeper than just different shaped widgets and button ordering. Even if you can get a vcl set that works on both, you are still faced with different user expectation on how things work. That translates into different form layouts possibly different component choices and occasionally different application layouts. Once you finally get a form that works on windows, osx and linux, you are still stuck when it comes to the iPhone apps. If you are doing a remotely sophisticated app, you are going to have to rewrite a large amount of the gui. There is no easy way around it. I've spent most of the night looking at python ides. Most are non native, probably java based. Even the good ones feel a bit strange and the bad ones are just horrid. Sean -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of David Brennan Sent: 15 June 2009 6:03 p.m. To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Embarcadero article I just don't see it working unless it is possible to take sophisticated applications using the current VCL (ie VCL32) and with some effort but not a complete rewrite (ie NOT replacing the entire component library!) modify the code using ifdefs etc so that you have single source that can compile to either platform. Similarly third party providers (eg DevExpress) need to be able to produce single source versions of their libraries fairly easily. As far as I can tell they are producing a completely new VCL for the Mac just like CLX was for Kylix... if so then that means they are only targeting new applications which is a fatal mistake IMO. Of course doing what I suggest (making the new Mac VCL compatible with the existing VCL32 BUT still making it appear native on other targets) is probably at least an order of magnitude harder than what they are trying... but if they don't then I don't really see the point. Interested to hear what others think. Cheers, David. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
My recollection from DelphiLive! (San Jose) is that Project-X is specifically targeting Mac and Linux support, and not involving Windows per se (except in so far as the 64-bit support will also depend on the re-architected compiler). i.e. re-architecting the compiler impacts on/delivers into ALL of the projects to support Mac/Linux/Win32/Win64/etc??!, but Project X is about building a VCL framework (or equivalent) for Mac and Linux GUI apps. I could be wrong, but that was the impression I took away from the event. My own personal hope is that it will involve separate implementations for Mac (Cocoa?) and some other GUI framework for Linux. That is, not 3 entirely distinct and separate VCL's, but 3 distinct visual control frameworks, building on a single-source shared foundation. Imagine having Cocoa/GDE/X-Windows GUI toolkits ALL supported by TActionList's and a cross platform gesture recognition engine, etc etc The worst *possible* idea, imho, would be to try and create a One-Size-Fits-All VCL for Mac/Linux/Windows. -- Smile, they said it could be worse! So I did. And it was. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
If they got the 3rd party buy in and DevExpress (for example - they are our biggest 3rd party supplier and our apps just wouldn't be possible without them) ported all their stuff across then I would be quite happy with the current VCL fading away. However that is a big IF. I don't see it happening (the 3rd party buy in part that is - I see Embarcadero TRYING unsuccessfully to push us this way as a definite possibility!) Interesting getting others take on it all. I still don't think a visual development environment like Delphi can be called cross platform unless you DO allow single sourced GUIs... However I certainly recognise that is very hard to do well which leads me to the conclusion that the whole thing isn't worth trying (too much effort, probably won't be done well as a result). Others have different requirements and see value in a multi GUI but single back end implementation. Could work I guess. ;-) Cheers, David. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Paul Heinz Sent: Monday, 15 June 2009 10:18 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article SNIP If Project 'X' is highly successful (which Embarcadero obviously hopes is the case) and the VCL/NG Linux and OSX Delphi developer base grows strongly, the VCL might become the red-haired step-child with waning Embarcadero and 3rd party component vendor support. Cheers, Paul. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
I don't see a problem with 3 distinct VCLs, one for each platform, provide they all conform to the same interfaces (protected, public and published) and wrap any platform specific stuff like Windows messaging inside the controls. Using a factory to create the VCL components on a form would allow a developer to simply change a configuration flag and a whole new set of controls would be instantiated, without needing to change the class inheritance in the application. Surely that's one of the strong points of object oriented design and polymorphism. As far as Java is concerned, I think fast natively compiled code without the need for a runtime engine distinguishes Delphi enough. Surely C/C++ is still widely used in MacOS and Linux for that very reason. Todd. Jolyon Smith wrote: | I just don't see it working unless it is possible to take | sophisticated applications using the current VCL (ie VCL32) and | with some effort but not a complete rewrite snip modify the | code using ifdefs etc so that you have single source that can compile | to either platform. I disagree. This is exactly the approach that Borland tried to take with VCL.NET with disastrous results. Even in that case, where the GUI toolkit was essentially the same, a simple recompile for this platform approach results in an application that is not well suited for the platform at all. Far from it. In the case of the Mac and Linux, those platforms are also quite visually different and in the case of the Mac in particular provide a quite different interaction with the user in many cases. How would you single-source VCL apps that assume a regular 3 button mouse with chording support when running on a 1 button Mac or even a Mighty Mouse equipped Mac? It's not necessarily a simple question of $ifdef'ing some event handling code - the different user input devices (and the difference in available user input/interaction controls, if you wish to exploit the native look and feel of the respective platforms) mean that you will almost certainly need to implement a quite different GUI on each version. Either that or dumb your GUI down to the lowest common denominator, resulting in an app that is unacceptably retarded in the UI department to be considered appealing on any of the platforms you choose to support. (for simple apps this might be viable, but you specifically referenced sophisticated applications, and this is my area of interest also). Any NON-visual code should be easily single-source'able, but the V part of the VCL really has to be different for each platform. Visual classes will, by definition, need to be different from platform to platform because, visually, those platforms ARE different. Didn't CLX try to achieve single source cross platform support? How did that work out again? ;) -- Smile, they said it could be worse! So I did. And it was. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
I don't see a problem with 3 distinct VCLs, one for each platform, provide they all conform to the same interfaces (protected, public and published) and wrap any platform specific stuff like Windows messaging inside the controls. Using a factory to create the VCL components on a form would allow a developer to simply change a configuration flag and a whole new set of controls would be instantiated, without needing to change the class inheritance in the application. Surely that's one of the strong points of object oriented design and polymorphism. As far as Java is concerned, I think fast natively compiled code without the need for a runtime engine distinguishes Delphi enough. Isn't C/C++ is still widely used in MacOS and Linux for that very reason. Todd. Jolyon Smith wrote: | I just don't see it working unless it is possible to take | sophisticated applications using the current VCL (ie VCL32) and | with some effort but not a complete rewrite snip modify the | code using ifdefs etc so that you have single source that can compile | to either platform. I disagree. This is exactly the approach that Borland tried to take with VCL.NET with disastrous results. Even in that case, where the GUI toolkit was essentially the same, a simple recompile for this platform approach results in an application that is not well suited for the platform at all. Far from it. In the case of the Mac and Linux, those platforms are also quite visually different and in the case of the Mac in particular provide a quite different interaction with the user in many cases. How would you single-source VCL apps that assume a regular 3 button mouse with chording support when running on a 1 button Mac or even a Mighty Mouse equipped Mac? It's not necessarily a simple question of $ifdef'ing some event handling code - the different user input devices (and the difference in available user input/interaction controls, if you wish to exploit the native look and feel of the respective platforms) mean that you will almost certainly need to implement a quite different GUI on each version. Either that or dumb your GUI down to the lowest common denominator, resulting in an app that is unacceptably retarded in the UI department to be considered appealing on any of the platforms you choose to support. (for simple apps this might be viable, but you specifically referenced sophisticated applications, and this is my area of interest also). Any NON-visual code should be easily single-source'able, but the V part of the VCL really has to be different for each platform. Visual classes will, by definition, need to be different from platform to platform because, visually, those platforms ARE different. Didn't CLX try to achieve single source cross platform support? How did that work out again? ;) -- Smile, they said it could be worse! So I did. And it was. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Not sure of the pitfalls etc, but the idea is surely worth pursuing, it is after all pretty much the holy grail of software. The ability to at least move a pure VCL over several platfrorms to give native versions on each (or complile all on Windows for instance) would be wonderful. The areas where difficulties arise no doubt will be the moment the VCL or hte programmer wants to start calling win32 stuff, a rewrite of VCL internally to abstract that sounds like a terrific idea. For the programmer will there be some even limited ability to call some win32 routines - ie some subset emulated as part of the newer VCL? Maybe maybe not. Some thoughts as I use to maintain a codebase of a large number of software packages that could be recompiled across PDP's, DOS, Windows and SCO Unix: -the program code was as much as possible written to have no OS IfDefs in it, what remained where minimal -anything that was OS variant was abstracted to a library routine that was internally ifdef'd and recompiled once for that OS in the approprate version of the library. -Some entire programs were also largely different versions for each OS, as they involved generating system commands, mainly programs to do with backup and printing as the commands used for each were OS specific backup and printing commands. These programs still shared most of their code base and the areas that differered were separated out to text command parameter files. -Some fixed values most use literal characters for that you did not think about were also abstracted into constants that were redefined on each platform, eg CRLF as that differs everywhere. Considering the intracies of dealing at the low level with PDP terminal escape sequences, DOS ANSI character sequences for colour and screen positioning, and Unix termcap entries, it all became a nice uniform programming environment that did get most of the benefit from each OS visual features. So especially if the stuff that really differs from OS to OS can be abstacted out at least to some degree so that the calling code is the (mostly) same then this has a real chance of being a winner. I think a benchmark to aim for is it should be about as easy or difficult as catering for the existing versions of Windows (98,2000,XP,Vista) and with and without themes as far as the programmer goes. This ideally would be an alternative way to virtualising an OS to get cross platform functionality... Actually the more I think about it - the more an important an idea this is!.Hardly anyone else is doing this, Microsoft certainly are not. Other cross platform languages like Qt or XULRunner (Mozilla) do not have the userbase of Delphi or have their own specialised area.. Also there is the possibility of getting some serious commercial backig for such a project, I imagine Skype would be just one of the vendors interested in supporting a version of Delphi for other OS's - I don't know how they do the Max and Linux versions so far, but they are always behind the Windows versions. I would add to the list of OS-X/Windows/linux also look at mobile platforms, and if at all possible consider a version for the Web using Delphi code - might it be possible to run a recompiled version of a Delphi app as a web page If you could do that you may not need the other native versions of Delphi at all.My guess however is that current Web technology is still a long way below native program in functionality and simplicity. well Delphi for PHP is there, and ASP already does something similar using C# code for both program and Web pages.. But surely the future of computing is one super language to use anywhere, including Web pages, not owned by any one corporation. We may not able to get there yet, maybe until HTML and Ajax is much more developed, but that is a goal to not take ones eyes off. John ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Hi guys, Just to clarify, we're not doing cross platform and then Win64, we're doing them in parallel (one of the benefits of an increased RD budget under Embarcadero). Cross platform will make it to market earlier however. Mike Swindell covers it more in a comment on Marco's post here http://blog.marcocantu.com/blog/delphi_cross_platform_anderson.html : Crossplatform and 64bit are two separate projects running in parallel. 64bit is moving fast but will take longer to get to market than xplat. 64bit has many implications on the existing customer Delphi and VCL Windows codebase. xplat is certainly a lot work (new compilers and VCL framework) but has a different type of of impact and expectation on existing code bases. ie we're more free to make breaking changes when going cross platform than 64bit. I get that it's disappointing to some people, that's unfortunate, and we looked long and hard at how we could do this any other way. Unfortunately but any major roadmap decision is likely to be make some people unhappy. We'll get them both out as soon as we can. Cheers Malcolm CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Thanks for the clarification Malcolm... Cheers, C. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Malcolm Groves Sent: Tuesday, 16 June 2009 2:49 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Hi guys, Just to clarify, we're not doing cross platform and then Win64, we're doing them in parallel (one of the benefits of an increased RD budget under Embarcadero). Cross platform will make it to market earlier however. Mike Swindell covers it more in a comment on Marco's post here http://blog.marcocantu.com/blog/delphi_cross_platform_anderson.html : Crossplatform and 64bit are two separate projects running in parallel. 64bit is moving fast but will take longer to get to market than xplat. 64bit has many implications on the existing customer Delphi and VCL Windows codebase. xplat is certainly a lot work (new compilers and VCL framework) but has a different type of of impact and expectation on existing code bases. ie we're more free to make breaking changes when going cross platform than 64bit. I get that it's disappointing to some people, that's unfortunate, and we looked long and hard at how we could do this any other way. Unfortunately but any major roadmap decision is likely to be make some people unhappy. We'll get them both out as soon as we can. Cheers Malcolm CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
No problem Conor. I know this is disappointing to you as well. Sorry. I'd have them both today (or more accurately, some time ago) if I could. Cheers Malcolm -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Conor Boyd Sent: Tuesday, 16 June 2009 1:07 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Thanks for the clarification Malcolm... Cheers, C. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
That isn't actually incompatible with Wayne Williams comments - nobody has suggested that one is being *done* before the other, only expressed dismay at the intent to *deliver* one before the other. Delivery dates are a function of technical stretch AND priority assigned to meeting that technical stretch. If 64-bit were given a *higher* priority, and therefore more resources, it could be delivered sooner, no? -- Smile, they said. it could be worse! So I did. And it was. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
That isn't actually incompatible with Wayne Williams comments - nobody has suggested that one is being *done* before the other, only expressed dismay at the intent to *deliver* one before the other. Err, righto. As I said in my email, I wanted to make sure people understood the 64 bit project was not on hold. If everyone understood that already, my apologies. If 64-bit were given a *higher* priority, and therefore more resources, it could be delivered sooner, no? Yes, up to a point. That sort of thinking doesn't scale endlessly of course. Given we want to do both, and allowing for the dependencies both technical and in terms of team-member skills, this was the best option we came up with. We'll continue to take feedback and adjust, but right now this is the plan. Cheers Malcolm CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Malcolm, Obviously the solution is once Project X is completed, don't release it until the 64bit compiler is done. Then release Project X a few weeks after the 64 bit compiler is available ;-) cheers, Jeremy ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Thanks for the continuing feedback and insight Maclolm. Very much appreciated. Can I suggest you take a peek at the poll running on my blog and the comments to my post on the subject? (www.deltics.co.nz/blog) I know it's a very small sample size but as I commented in my blog post, the idea that there exists greater demand for either Linux or Mac than there is for 64-bit came as a genuine surprise to me and to everyone I've spoken to about it (and note also the comment from one visitor, that even if Linux support is to come first, it really has to be 64-bit to be of any practical interest - i.e. for server side Linux purposes where most commercial potential surely exists. An observation which makes perfect sense to me but which had not previously occurred to me directly) For sure there is definite and very real *interest* in Mac and Linux support, for the future, but I'm not sure that that necessarily translates into demand (commercially rewarding demand being an even smaller subset of any actual demand that there may be, especially in the Linux space which is still, afaik, a largely free software ecosystem). Speaking personally - I would *love* to be able to play around with knocking out some Mac apps with my beloved Delphi. But even if it were available today I wouldn't be buying because I can't justify the cost. In the meantime my paying customers are asking for 64-bit Windows apps, not Mac apps. I still *want* Mac support, and the prospect *excites* me more than 64-bit Windows. But we *need* 64-bit Windows. Of course, Embarcadero may have access to a wider and more accurate sample size on which to base these decisions. And again, as I observe in my post, I have to hope that that is the case. But even then, that would have to leave me wondering if Delphi is actually the right tool to continue using, since the wider Delphi community - if accurately reflected by this prioritisation - would seem to be heading down a different path than meets our needs, and if Embarcadero are going to service those needs more urgently than ours then we should perhaps be considering other options. -- Smile, they said. it could be worse! So I did. And it was. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Hi Jolyon, As I said, we'll continue to listen and course correct. Feedback we're getting from customers and potential customers worldwide is that cross platform is a higher priority. I don't deny that there are people who desperately want 64 bit, I know people in that boat around Asia. Perhaps those who want cross platform more haven't taken the time to vote on your poll. The ratio of responses on this list has also been interesting. I am genuinely sorry that we can't get them both out earlier, and I sincerely hope this decision doesn't make it impossible for you to use Delphi. Ultimately though, all we can do is gather as much data as possible make the best decision we can, and then adjust as we go. That's what we're doing. Cheers Malcolm CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
Re: [DUG] Embarcadero article
Hi Malcolm, Great to have you listening and posting! However I am surprised to hear that your feedback is so in favour of cross platform over 64 bit. Speaking bluntly, I wonder if the feedback you are getting is based on a dream that isn't actually achievable (this version anyway). I mean, are those people saying they prefer cross platform to 64 bit support answering question 1 or question 2 below: 1. Would you prefer totally awesome fully native looking yet single sourced and comprehensive bug free cross platform Delphi or solid Win64 support? 2. Would you prefer the useful first iteration of something which might turn into awesome cross platform support (but will probably start out fairly anaemic for the first version at least) or solid Win64 support? I suspect they are answering question #1. I really don't think question #1 is a realistic question. I don't mean any disrespect whatsoever to Embarcadero/CodeGear in saying so - I would say the same if Microsoft/Insert your most successful and wealthy development company said the same thing. I'm basing my assessment on the significant number of organisations who have attempted such things in the past (including Borland) and the time span you are trying to do it in, amongst other things. If you asked people question #2, which I think is more realistic, then maybe you would get a different answer? Cheers, David. -Original Message- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Malcolm Groves Sent: Tuesday, 16 June 2009 5:28 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Embarcadero article Hi Jolyon, As I said, we'll continue to listen and course correct. Feedback we're getting from customers and potential customers worldwide is that cross platform is a higher priority. I don't deny that there are people who desperately want 64 bit, I know people in that boat around Asia. Perhaps those who want cross platform more haven't taken the time to vote on your poll. The ratio of responses on this list has also been interesting. I am genuinely sorry that we can't get them both out earlier, and I sincerely hope this decision doesn't make it impossible for you to use Delphi. Ultimately though, all we can do is gather as much data as possible make the best decision we can, and then adjust as we go. That's what we're doing. Cheers Malcolm CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
