[DUG] EMBARCADERO MY GRIPE

Wed Jul 29 10:01:47 NZST 2015

Hi Jolyon,

I think that mono support OS X which you can write c# code to run on OS X.

Regards
Leigh

On 29 July 2015 at 09:56, Jolyon Smith <jsmith at deltics.co.nz> wrote:

> Yes, there is no denying that it would be a hard sell to get elements
> introduced into an enterprise or even ISV setting.
>
> But for the enthusiast/hobbyist/independent ObjectPascal (in particular)
> developer it has much to offer against the likes of Delphi or even FPC
> (which ime is frustratingly lacking in the polish you may be used to from
> commercial dev tools and falls *far* short of the "just works" goal when
> it comes to mobile dev... I suppose if you enjoy spending more time getting
> your compiler to even work than you do developing apps, then it may appeal).
>
> Even if you are keen on (or willing to suffer C#) Elements has some
> advantages even compared to the comparably affordable version of Xamarin,
> not least being complete platform support (Indie Xamarin does not support
> OS X or System.SqlClient, for example).
>
> And using Elements I am at least also learning the platform SDK's, so if I
> ever am asked to do Android or iOS development "properly", everything I am
> learning in the meantime can be applied directly (I am no stranger to Java
> / Eclipse or Objective-C / X Code, I just prefer ObjectPascal).
>
>
> On 29 July 2015 at 08:13, Jeremy Coulter <jscoulter at gmail.com> wrote:
>
>> I guess for me, not ever seeing a role advertised that requires
>> RemObjects experience, I would be confined to tinkering with the free
>> version of the "Silver" tool.
>> And given its not main-stream, it would be hard to get it into our
>> development environment.
>> Thats not saying it itsnt a good tool, just the commercial reality.
>> However, like all of you, I am getting a little concerned about EMB.
>> direction. For me personally, having to re-install my controls every six
>> months or so is just not economic. Instead of releasing new versions ever 6
>> months or so, do one a year with six month updates that doesnt require me
>> to re-install all my controls.
>>
>> Jeremy
>>
>> On Wed, Jul 29, 2015 at 8:03 AM, Jolyon Smith <jsmith at deltics.co.nz>
>> wrote:
>>
>>> RemObjects # of users - sorry, I have no idea.
>>>
>>> Community support - there are two prongs to this...
>>>
>>> First, the RemObjects forums are quite active with contributions both
>>> from users and RemObjects staff thmselves.  To give an example of the type
>>> of support you get, on one occasion during my early days with the product I
>>> encountered a problem using a particular aspect of the Android SDK which
>>> was traced to an esoteric bug in the compiler.  This was identified in a
>>> few days and by the end of that week a build had been provided to me
>>> personally to test, before the fix was incorporated in a subsequent beta
>>> and later release build.
>>>
>>> As a subscriber you have access to the current and previous releases and
>>> betas and you also have a "private downloads" area where specific builds
>>> may be provided to you.  Betas are updated on a more or less monthly basis
>>> with full releases usually coming quarterly, along with regular updates on
>>> the development plans (a "roadmap" if you like" via the blog, as well as
>>> formal updates to those plans with each release (they tell you what the new
>>> release delivers and what they are working on next).
>>>
>>> http://blogs.remobjects.com/blogs/mh/2015/07/16/p7096
>>>
>>> I should add that I am enjopying only *BASIC* support.  Premium support
>>> is a cost-extra option, should you feel the need for it.
>>>
>>>
>>> Second, "Community Support" is also on offer from beyond the strictly
>>> delineated boundary of "RemObjects Users" itself. by virtue of the fact
>>> that you are developing directly against the platform SDK's.  I have
>>> learned all my Android and iOS development from the Java and Objective-C
>>> examples online and by perusing questions and answers on Stack Overflow
>>> couched in terms of those platform native languages and API's.  Applying
>>> that knowledge to RemObjects elements is a trivial exercise in syntax
>>> conversion.
>>>
>>>
>>> On the point of Java and "one language everywhere".... something to bear
>>> in mind here is that when you compile RemObjects Elements code - whether
>>> ObjectPascal (Oxygene), C# or Swift - for Android, what the compiler emits
>>> is Java byte-code.  It is indistinguishable from the output of a Java
>>> compiler!  The front end language syntax may be different, but the output
>>> is essentially Java.  This applies equally to consuming other Java code.
>>> Classes etc from Java are simply consumed directly in your code by adding
>>> the relevant JAR to your project references.
>>>
>>> So in a way, RemObjects Elements is an active participant in that "Java
>>> everywhere" phenomenon - when compiling for a Java platform.  In the
>>> Oxygene compiler they have cleaned up the syntax of some of the aspects of
>>> Java, whilst retaining this compatibility.  For example. Java has no formal
>>> specification for the concept of a "property".  But you can still declare
>>> properties in Oxygene for Java - the compiler emits corresponding getXXX
>>> and setXXX methods as you would expect (even if you have not explicitly
>>> declared these accessor methods).  Equally, if you consume a Java class
>>> (e.g. from the Android SDK) which implements get/set methods, then these
>>> can be accessed as if they were properties:
>>>
>>>    Java methods:    v = o.getName(); / o.setName(v);
>>>    Oxygene:            v := o.Name; / o.Name := v
>>>
>>> Similarly if provide your class implementing a read/write "Name"
>>> property to a Java developer (in a jar file) then they will see a class
>>> with getName and setName methods, just as they would normally expect.
>>>
>>> Equally when compiling for .net then Elements is an active participant
>>> in that ecosystem/platform.  And ditto w.r.t iOS / OS X when compiling for
>>> those platforms.
>>>
>>>
>>> As I think I said, impressive and innovative technology.  :)
>>>
>>>
>>>
>>>
>>>
>>> On 29 July 2015 at 00:25, John Bird <johnkbird at paradise.net.nz> wrote:
>>>
>>>>   I don’t know RemObjects C# or Oxygene.   I read the site and their
>>>> viewpoint on using native API’s is a worthwhile debate.    I would have
>>>> these queries:
>>>>
>>>> 1 – Where does it rate on the number of users?   Community support,
>>>> code snippets etc is as important as everything else.
>>>>
>>>> 2 – It is the opposite of “one language fits everywhere”   yet the
>>>> language currently scoring top on the Tiobe index of programming languages
>>>> does just that – Java.
>>>>
>>>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>>>>
>>>>
>>>> I noticed Delphi is up another few places, to 13.   Pascal is rated
>>>> separately too at 20.
>>>>
>>>> On the comments about the IDE, at work have used D5 , D2007, XE2 XE5
>>>> XE7 XE8 and each version was a definite improvement.
>>>>
>>>>  *From:* Jolyon Smith <jsmith at deltics.co.nz>
>>>> *Sent:* Tuesday, July 28, 2015 5:03 PM
>>>> *To:* NZ Borland Developers Group - Delphi List
>>>> <delphi at listserver.123.net.nz>
>>>> *Subject:* Re: [DUG] EMBARCADERO MY GRIPE
>>>>
>>>>  I'll say it one more time... RemObjects manage to provide very good
>>>> support for good quality products with extensive, impressive and innovative
>>>> technology that does indeed "just work" (as in effortlessly, not "barely"
>>>> LOL) at a very reasonable price.  $49 Turbo Pascal it certainly isn't, but
>>>> lined up against the likes of Delphi and Xamarin and particularly after
>>>> adjusting for inflation (for comparison with the $49 TP) it isn't far off.
>>>>
>>>> Cheap(er) = lower quality is *not* a rule, and certainly not a
>>>> Universal Constant.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> NZ Borland Developers Group - Delphi mailing list
>>>> Post: delphi at listserver.123.net.nz
>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz
>>>> with Subject: unsubscribe
>>>>
>>>
>>>
>>> _______________________________________________
>>> NZ Borland Developers Group - Delphi mailing list
>>> Post: delphi at listserver.123.net.nz
>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
>>> Subject: unsubscribe
>>>
>>
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at listserver.123.net.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
>> Subject: unsubscribe
>>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20150729/2f2284d5/attachment-0001.html 