EMBT gets a Swift Kick in the Assetts

In case you haven’t heard yet, Apple has created a new language meant to be more friendly than Objective C. ¬†They call it Swift, and it is aptly named judging from the benchmarks which show it to be significantly faster than Objective C even though it uses the same run-time and is compiled using the LLVM toolchain.

What does this mean for Delphi? ¬†Perhaps a few developers looking to produce truly native (UI and code) will take another look at Apple’s development tools that they already have to access to as part of the development program.

6 Responses to “EMBT gets a Swift Kick in the Assetts”

  1. Jenny says:

    obvisiously Apple dont want to promote the concurrent Android world.

    So i would guess its a advantage to develop in Delphi if you want to
    get more platform-independent.
    Maybe at some special corners, Swift will have some soft speed advantages, if you really nead this and are willing to specialice adequate.

  2. Gad D Lord says:

    Looks really great!

    I love some of the stuff from first glance – i.e. functions in side enums.

    And yes “We are looking into ways to produce truly (not in the EMB way) native apps.

  3. Joseph says:

    What it *should* mean for Delphi is that EMBT stop hiring minimum wage Romanians and hire some people with actual academic credentials to overhaul the Delphi language and similarly bring it up to speed with modern language standards. What it *should* mean is that Delphi die-hards on the EMBT forum stop telling me that type inference is “impossible” and “the compiler just guessing”, that modern language structures are “fads” that language designers add “just to be cool”, that automatic memory management is evil (thanks to Swift I’ve now still to find one language created in the 21st century that has lacked memory management), etc.

    So many of the language features Swift is incorporating are features I specifically suggested should be in Delphi (and some are already incorporated in DWScript, Oxygene, and/or Nimrod)… named parameters, type inference, automatic memory management, tuples, multiple return values, map/filter/reduce operations, ditching semicolons, etc. Instead I get told “You want to turn Delphi into C# or Python!” (As if either of those would be a bad thing).

    On the downside, Swift appears to be tied to one OS like Delphi used to be and you’re similarly limited to doing your development on one OS.

    Honestly, I don’t expect EMBT to focus on making the language simpler anytime soon and continue to forget that the “RAD” in RAD Studio was all about increasing developer productivity (today the remaining Delphi developers seem to be obsessed with premature micro-optimizations instead).

  4. Simelane says:

    I love Delphi’s cross-platform abilities. I am a long time Delphi developer and I see Delphi XE6 as making my many years of Delphi investment relevant in today’s mobile and cloud centric world.

    My frustration is that while Embarcadero has done a great job of porting Delphi’s strengths to the mobile and cloud world, they have done a poor job of extending Delphi to support those things that make mobile a different beast from just a computer with a small screen that lacks a keyboard.

    So, I have been contemplating an Apple Passbook / Samsung Wallet / Android Passwallet project that integrates the passes with iBeacons (BLE sensor profile on Android). There is simply no way of doing this in Delphi, even though I can do the entire app (across iOS and Android) in Delphi – sans the mobile wallet and BLE bits.

    I think that emphasising desktop compatibility/portability is hindering Delphi from embracing capabilities that are inherently mobile or cloud centric and do not have an equivalent construct on the desktop.

    So, I have been dreading starting my project using Objective-C (and then having to rewrite, not port, it to Java). A quick look at Swift has convinced me that there are places that Delphi is unlikely to ever go… not because it can’t, but because it won’t… and if it does, it will always be several mobile and cloud generations behind because it is trying so hard to do all things equally well.

    I was impressed with the capabilities that Apple exposed to developers during the keynote… I wanted to be young again so that I could code all day and all night. I want the mobile wallet app I am developing to use TouchID on iPhones that support it… I want to expose some of my apps features as extensions… I want to integrate into HealthKit so that the wallet can be a store of more than just tokens… I want to support handoff because I am also building an OS-X app… I want my app to publish a widget so that you can interact with it from Notification Centre… lets not even imagine what a game developer could do with Metal, SpriteKit and SceneKit. And when I look at my beloved Delphi, I realise if I want to do anything that is more interesting than a form based app, I will have to look elsewhere. Swift looks like a great place to start from someone coming from Delphi… a whole lot better than Objective-C.

  5. And another apple hype – and another time for people falling into the stockholm syndrome.

    @Joseph: While I agree with some points I think often people forget that EMBT is not Microsoft or Apple or Google. They simply don’t have the resources for things like that. Also while they are also are pascal dialects you forget that DWScript is a scripting language and Oxygene is a language originally targeting the .NET platform. Comparing that with Delphi is like apples and oranges.
    Again I agree that Delphi needs modern language features itself instead of yet another bunch of highlevel components (3rd party vendors can do them but they cannot change the compiler so that should be the no1 focus of EMBT)

  6. AnonymousMethod says:

    Faster than Objective C? Haha, no. A lot slower.

Leave a Reply