[DUG] EMBARCADERO MY GRIPE

Wed Jul 29 09:56:19 NZST 2015

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20150729/683809d0/attachment.html 