Slashdot Mirror
Four Years On, Developers Ponder The Real Purpose of Apple's Swift Programming Language (monkeydom.de)
Programming languages such as Lua, Objective-C, Erlang, and Ruby (on Rails) offer distinct features, but they are also riddled with certain well-documented drawbacks. However, writes respected critic Dominik Wagner, their origination and continued existence serves a purpose. In 2014, Apple introduced Swift programming language. It has been four years, but Wagner and many developers who have shared the blog post over the weekend, wonder what exactly is Swift trying to solve as they capture the struggle at least a portion of developers who are writing in Swift face today. Writes Wagner: Swift just wanted to be better, more modern, the future -- the one language to rule them all. A first red flag for anyone who ever tried to do a 2.0 rewrite of anything.
On top of that it chose to be opinionated about features of Objective-C, that many long time developers consider virtues, not problems: Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature. Define the convenience and elegance of nil-message passing only as a source of problems. Classify the implicit optionality of objects purely as a source of bugs. [...] It keeps defering the big wins to the future while it only offered a very labour intensive upgrade path. Without a steady revenue stream, many apps that would have just compiled fine if done in Objective-C, either can't take advantage of new features of the devices easily, or had to be taken out of the App Store alltogether, because upgrading would be to costly. If you are working in the indie dev-scene, you probably know one of those stories as well. And while this is supposed to be over now, this damage has been done and is real.
On top of all of this, there is that great tension with the existing Apple framework ecosystem. While Apple did a great job on exposing Cocoa/Foundation as graspable into Swift as they could, there is still great tension in the way Swift wants to see the world, and the design paradigms that created the existing frameworks. That tension is not resolved yet, and since it is a design conflict, essentially can't be resolved. Just mitigated. From old foundational design patterns of Cocoa, like delegation, data sources, flat class hierarchies, over to the way the collection classes work, and how forgiving the API in general should be. If you work in that world you are constantly torn between doing things the Swift/standard-library way, or the Cocoa way and bridging in-between. To make matters worse there are a lot of concepts that don't even have a good equivalent. This, for me at least, generates an almost unbearable mental load.
On top of that it chose to be opinionated about features of Objective-C, that many long time developers consider virtues, not problems: Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature. Define the convenience and elegance of nil-message passing only as a source of problems. Classify the implicit optionality of objects purely as a source of bugs. [...] It keeps defering the big wins to the future while it only offered a very labour intensive upgrade path. Without a steady revenue stream, many apps that would have just compiled fine if done in Objective-C, either can't take advantage of new features of the devices easily, or had to be taken out of the App Store alltogether, because upgrading would be to costly. If you are working in the indie dev-scene, you probably know one of those stories as well. And while this is supposed to be over now, this damage has been done and is real.
On top of all of this, there is that great tension with the existing Apple framework ecosystem. While Apple did a great job on exposing Cocoa/Foundation as graspable into Swift as they could, there is still great tension in the way Swift wants to see the world, and the design paradigms that created the existing frameworks. That tension is not resolved yet, and since it is a design conflict, essentially can't be resolved. Just mitigated. From old foundational design patterns of Cocoa, like delegation, data sources, flat class hierarchies, over to the way the collection classes work, and how forgiving the API in general should be. If you work in that world you are constantly torn between doing things the Swift/standard-library way, or the Cocoa way and bridging in-between. To make matters worse there are a lot of concepts that don't even have a good equivalent. This, for me at least, generates an almost unbearable mental load.
They already have one for consumers, this just makes it easier to put one up for developers.
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
Apps written in different languages are hard to compile across platforms.
That's what you get for coding with Apple's proprietary garbage language instead of a standards-compliant one like C or VBA.
It's gonna be swifty!
Introducing the world to a safer form of programming.
Like the many languages that have unsuccessfully tried to do that over the decades. Jack of all trades, master of none.
Don't look for reasons why Swift may be technically superior. Look for reasons why Apple wants Swift to keep developers locked inside the Apple world. Every minute that a developer uses to learn Swift, is a minute not spent on learning a non-Apple technology.
https://www.youtube.com/watch?v=I1188GO4p1E
After writing an entire application stack in Obj-C / Cocoa (ExactScan, OCRKit, ...) we will not continue using Apple only technology. To much vendor lock in, too much extra work porting and sharing code with other platforms. Yes, Swift may be partially vendor neutral, however all the Cocoa / AppKit / UIKit et al. APIs do not help, and Swift is otherwise not too native on Linux and Windows.
The only criteria that's relevant if you're already supporting a profitable application on either iOS or OS X platforms - maintainable. How fast does a language enable the rev of your code base, does it abstract your code base above platforms and can its libraries and API's bridge between manufacturer hardware swaps and recompiles without cost of a total rewrite.
Those were lessons learned during NeXT transitions from little to big endian and Mac OS X revs that Apple made 3X/yr during SteveJobs reign.
Working for a well known chip company here. I'm one of the DB guys. I know we dumped out in-house iOS team when the whole "port to Swift" BS started. Management took one look at the cost and out-sourced the lot to east Europe.
Firstly itâ(TM)s not lock in any more than objc is. No other (serious) platform uses objc. So stop whining about lock in. Programmers on the Apple platforms donâ(TM)t give a crap about that anyway. Weâ(TM)re there because we want to be. And most of us learned objc after learning other languages, because the iOS sdk hasnâ(TM)t been around forever, so we all came from other languages. We arenâ(TM)t so stupid we canâ(TM)t learn something else, kthx.
Secondly it addresses some real pain points from objc. One is verbosity. Another is the fact that nil objects donâ(TM)t crash the app which makes bugs hard to find. Inconsistent message vs function call syntax. Inconsistent property vs method syntax. I could go on and on.
Thirdly it addresses type safety. Objc will let you have an array of id, which is like having an array of java.lang.Object and trusting the programmer to use it appropriately. Anyone who argues that strong type safety isnâ(TM)t better has never worked outside of some niche application. This is enough of a pain point with objc that it deserves its own paragraph.
Fourthly it brings functional programming to the table better than objc. Yes you can pass blocks around in objc but itâ(TM)s syntactically painful where as Swift makes it easy (aka first class citizen).
I could continue but Iâ(TM)m tired of typing on my phone. The point is there actually are plenty of real world gains in Swift.
Outside of /. where everyoneâ(TM)s mind is already made up and Apple is the devil, I donâ(TM)t know anyone that has used swift for real who doesnâ(TM)t think itâ(TM)s massively superior to objc.
Is it finalized? No. Itâ(TM)s a language in flux and theyâ(TM)re taking community feedback too. So everyone is an early adopter by definition and they expect some upgrade pain. Itâ(TM)s really not that bad in practice and Xcode handles 90% of it. Itâ(TM)s no worse than switching to a new iOS version and dealing with depreciations every year.
Again, weâ(TM)ve all chosen the platform and the language because we think itâ(TM)s superior. We arenâ(TM)t stupid. We arenâ(TM)t locked in. We all know other languages. Thanks.
Cue the haters.
There is a pattern and it is like this
- School do not teach anymore why things are done the way they are, the reasons
- Students are not interested, have low attention span, generally consider the teaching "old stuff"
- Computer science is populated by freshers, you are old at 40
the result is:
- Reinventing the same solution, worse
How to stop this total waste of time,money ?
- Keep older developer around and when they say that the "new shiny idea" has been done before, listen to them.
A list of already done things:
1) AI (in the current form), it is Neural net, learned 30 years ago, yes, now you have a supercomputer on desk but it is not new tech and has all the same issues it had before.
2) Blockchain, can anybody think of a revision system ? GIT, SVN ?
3) Languages, lots of them, really, are we so dumb that to save a few keystrokes we produce something that is obscure after the third line ?
Can we agree that all possible logic and consistency tests should be done at "compile time" ? (no Unit testing is not the same thing)
FInally, a question: How do we get rid of the pointy haired boss ? (See Dilbert)
He knows nothing, makes random decisions (on a good day) and sucks half of the budget in bonuses...
Concurrency is mentioned in TFA.
Look at die photos (of A4...A11 and mobile Intel) and compare allocation of space for CPU vs GPU over the last decade.
Now compare time and effort spent on languages and toolchains that can't run on the GPU, and can.
> Classify the implicit optionality of objects purely as a source of bugs
Among other issues, this remains my biggest complaint.
Obj-C generally "did the right thing" with nil in most contexts. Sure, nil-pointer errors are a pain, but declaring them away and just forcing everyone to type ! everywhere does not eliminate them. It does, however, eliminate the simplicity of binding a nil to a text field and just getting a zero, precisely what has to happen in code now.
Needs to find a way to provide intuitive usage of all those cores. One of the reasons C was so successful was it abstracted the hardware into a human understandable model. One of the problems with all the new languages is they try to fit a square peg in a round hole and ignore how the hardware works. Yes hardware has gotten much much much faster, but so much of that speed has been consumed with layers and layers and layers of abstraction. If someone figures out how to do what C did for uni-processor computers on multi-cores, that will be gold.
All us cool kids have switched to Go and Rust. It is better to use the latest languages produced and controlled by a single corporate entity to keep your skills "sharp". By the way, can someone find me a job? I don't know C or C++ but I know how to use the latest frameworks!
I don't know jack about Swift, but does it prevent people from assuming things about the CPU?
It could very well be that Apple has been planning a transition to ARM CPUs for a long time and Swift is one of the step required to have everyone coding in a language were re-compiling for a new CPU is as effortless as possible to make sure all programs can make the jump to the next generation of their computers.
#DeleteFacebook
The summary seems like a plea to bring back Objective C features that do not exist in Swift, which seems to pretend like Objective C was a good language. Apple finally replaced it because they realized that Objective C was the most limiting
The message passing system can be added as a layer on top of your own code in Swift, rather than being a jumbled mess of "it's awesomely powerful once you learn it" features that Objective C offered alongside some of the most overly complex syntax that I can remember in a modernly used language.
Anyone hoping to solely use Swift is specifically an Apple developer and that is its point. You cannot take libraries written in Swift and make them transferable -- the language didn't even compile on Windows for a long time. If you want to develop on MacOS/iOS and you honestly want your code to be transferable, then use a framework or develop things in another language that is intended to run on Android (and Windows), then write the UI in Swift if you want. That should allow you to get a native look and feel with minimum effort across every platform that you choose to support.
Given the size of Apple's bank account, shouldn't we be writing Appl€?
#DeleteFacebook
When every platform had it's own incompatible suite of tools. And porting software between them was a real pain. It was a big deal to port your game from C64 to DOS and TRS-80 CoCo.
Everything that is old is new again.
-or-
Swift is the emporer's new clothes.
Anytime we change a software standard, it's an act of violence. It is disruptive. It will cause stuff to fail. It will cause cost and harm to people. So we need to be really careful when we revise the standards because there is that cost. We have to make sure that we're adding so much value to offset the cost.
"First they came for the slanderers and i said nothing."
Define the convenience and elegance of nil-message passing only as a source of problems. Classify the implicit optionality of objects purely as a source of bugs.
This is what they choose to complain about, fixing the "billion-dollar mistake"? They actually want the language to implicitly accept all messages sent to nil as no-ops with a default return value, regardless of the intended interface, and to allow nil to be passed for any reference parameter even when it makes no sense for the parameter to be omitted?
I would be among the first to promote language-agnostic APIs and allowing the developer to choose the language best suited to the problem domain. However, complaining about the parts of Swift that Apple got right is not very likely to make me more sympathetic to their cause.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
That article might have just said "I don't like swift" and saved us a whole lot of time. I am not a super fan myself. Though I have never understood why you need most languages... C/C++. and Perl/Python pretty much cover most any need. Occasionally there is an intelligent discussion of problems that must be solved inelegantly that some language makes beautiful, but if they're truly valuable, they usually make their way into other languages. but if it makes Graphical and OO apps easier to program then god bless
I was a huge fan of Objective-C. I still think it's an elegant language. I love the delegate patterns, I love the quirky stuff like method swizzling, I love the runtime message passing.
When Swift first came out, it was really rough. The Obj-C bridge APIs were all using forced-unwrapped optionals and the like, and Apple didn't do a great job explaining why all of that was in place. Only with Swift 2, 3, and 4 did it become clear that you should never force-unwrap unless using some crufty API that required it (which it turns out is almost never these days).
I do miss some things like nested message passing, but I also don't miss a lot of things. I love the map, reduce, and filter capabilities, I like the more nuanced closures vs completion blocks. There are still things that frustrate me, but they generally get better every year. Swift is one of my favorite languages to code in these days.
- Vincit qui patitur.
And ironically solves NIH by copying elements from nearly every other programming language in existence.
Reduce bugs + Retain performance... Quite often those two are not aligned.
Apple live in a world where the real value of their product is dependent on 3rd party developers.
(1) iOS apps crashed more than android apps. The common causes for application crashes on iOS and noticed that the majority of crashes are based on poor coding due to legacy syntax which can be corrected. Shown below are some extracts from 2016.
(2) Typical of any virtual machine is the initialization cost of the VM. This means that you need to take a fully compiled approach otherwise you lose perceived performance advantages. JVM code is often more performant than a typical C, written at the same skill level, once the VM is warm/hot and great for server workloads however initialization costs are unavoidable.
Everyone forgets history.
FYI - ios apps crash more than android apps: https://www.techspot.com/news/...
FYI - some infoq: 47% of apps crash more than 1% of the time: https://www.infoq.com/news/201...
Android 2.3 'Gingerbread' had a crash rate of 1.7%, for example, while iOS 6 apps crashed 2.5% of the time.
FYI - AppCoda: https://www.appcoda.com/apteli...
3 Most Frequent iOS Crashes , 23rd May 2016
SIGSEGV (50%) - This signal occurs when your app attempts to access memory that has not been allocated by the program.
NSInvalidArgumentException - This crash occurs when a method is being called on an object that can’t respond to it.
SIGABRT - You’ll see this in your debugger when there is an unhandled exception (see #2). However, in a deployed app SIGABRT appears when there is an assertion failure or abort method called within the app or the operating system. Often raised during asynchronous system method calls (CoreData, accessing files, NSUserDefaults, and other multithreaded system functions).
See subject: Via Delphi (especially XE 10++) or FreePascal + Lazarus IDE 1.8.2 APK Hosts File Engine 64-bit https://news.slashdot.org/comments.pl?sid=12218294&threshold=-1&commentsort=0&mode=thread&pid=56764940/
I ported to Linux, Windows, BSD & MacOS X (phones handled by Delphi IF I wish to spend the coin, & I don't + I think "smartphones" are security issue riddled TOYS - I actually LIKE FreePascal BETTER now).
* Tools for development, especially in PROVEN older languages (especially for my program, it was C++ or Pascal to me (my favs) & since C is roots of C++ & C has buffer overflow security issues? Object Pascal it was for me since my program deals HEAVILY in stringwork (no buffer overflow possible as length's built-into Pascal strings)).
APK
P.S.=> Truthfully? It was a VERY EASY PORT from Delphi code for Win32/64 into Linux/BSD/MacOS X (except for some differences in TCP/IP ICMP stack API work which I "busted thru" finding out ping had MAC restrictions on it, NOT the RAW IP stack Linux has vs. WinSock2 LIMITED ones by default to most users))... apk
* Memory Safe (that catches about 50% of CVE exploits)
* Developer controls object lifecycle, unlike Java and C#
* Because of that:soft-realtime capability, unlike GC languages
This IS a step in the right direction, because left and right computer systems are pwned.
http://altwissenschaft.ddnss.de/Ansaetze.html, Section 5.
children. Everyone is a programmer now per Tim Cook. First thing he brought up at WWDC. lol
Microsoft has Visual Studio (C/C++, C#, Basic, etc). Google has GO. Apple has a pissing contest, I mean, Swift.
I wanted to like Swift, but it's just like a really uninspired rip-off of Kotlin. I used Swift for one app, but then when it became clear Apple would just randomly be making breaking changes every year, instead of wasting time "maintaining" code that was perfectly fine in the last version, I decided to never use Swift again.
I paid the bills as a Carbon (who knew?) developer. Considering I've always been able to keep current and learn new skills every few years, I was blindsided by Cocoa/Objective-C and the change to the Apple Developer tools. Inside Macintosh was a great resource and when Cocoa was born Inside Macintosh was left by the wayside. The small independent/inhouse developer was left to flounder. For all the greatness attributed to Steve Jobs, he seemed to have abandoned the small developers who couldn't go to "boot camps" or wherever else folks went to get on board the new platform. OS X is nice, but Carbon was a well documented and easy to navigate environment. Carbon made the Mac what it was and Apple and Steve Jobs decided to push NeXT OS instead. I am not alone in having fond memories of Carbon while using Microsoft's tools to ply my trade.
My user name was a mistake. Input wasn't restricted, my bad.
FTFY. One dude with a blog is not "Developers"
you P.O.S.
Apple touted it as a more human-readable, easy to grok language, but it's only marginally more easy to deal with than the unwieldy Obj-C it's meant to supplant. Frankly, I don't think Apple should be focusing on Languages, they clearly do not understand how to support developers or produce a language that streamlines development. Perhaps they should copy MS and produce a language that rip-offs the Java API with Obj-C or Swift as it's underpinnings, as much as I can't stand MS, I opted for C# for some Unity projects and was quite happy to work with it and had little issues with diving in and working with it with no prior exposure to it
"..an unbearable mental load" - a language is a tool, ffs, it has issues; so learn them and use it if you have to or become a florist.
Apple didn't want business logic developed in C++11. That would have allowed sharing between Windows Phone and iOS.
Swift started out very rough with a shitty toolchain and bridge to Cocoa, but it has improved leaps and bounds. I've been developing in it since late 2014 and have written an application that is being used by thousands of people daily and generating millions per year in revenue. Only a very small part of the app is written in Objective-C.
Swift was very jarring to start using, just like when I moved to Objective-C from C++. After working in Objective-C for a few years I had a revulsion to working in C++ and now I have a similar feeling when having to work in Objective-C.
Some of the cool things you can do with Objective-C like method swizzling and dynamic message handling are things you really shouldn't be doing, but if you do need to do those things there's still nothing stopping you from adding some Objective-C code into your Swift project.
Swift is far and above Objective-C in terms of readability and ease of use and makes working with blocks a lot easier. It requires a bit of a shift in mindset compared to Objective-C, but you'll end up writing better code. Working with immutable data wherever possible, combined with blocks makes multiprocessing easier. Our defect count is much lower since adopting Swift.
The most exciting thing about Swift is that Apple have open-sourced it and you can use it on backend code. We've been working this year to replace some our backend with Swift, with the end-goal of having the client and server sharing common data model and business logic code.
.. i.e. less scary to most people.
However, if you want to establish a PL it has to be cross-plattform. That's a given. And better at cross-plattform than any other PL. I mean GUI builder, binary compiler, FOSS all the way, hardware trickery, etc. Fall short on that and you'll have a hard time getting tracktion. .Net anyone? We have enough flaky half-assed shit in the PL space already - i.e. every freakin' PL out there. Apple has fallen a little short of this.
The only other possible option for them is offering a zero-fuss experience for those who want to develop for the Apple ecosystem. The GP hints that this is not entirely the case - which would be a drag and a shortcoming on Apples behalf.
About 7 months ago I pondered getting a stack of Apple hardware (Phone, Tablet, new MB Pro) and professionally develop Apple code for a living. This GP post has me glad I didn't. Web it is for me still as I decided. Open plattform technology. Nice. Can be a serious pain doing tricky stuff, but then again that stuff is rare. Just right for neat x-plattform UIs and shoveling data about. ... The only problem are the douchebags and halfwits in the webdev space - that's a real downer and a pill. The magnitude of shitty code and utterly clueless decisions is absolutely staggering and time and time again manages to have me stand with awe and amazement as to how these people even manage to get things working.
As I just experienced once again today after a hard workday at my current agency. .... aaaah, agencies, ... don't even get me started ...
We suffer more in our imagination than in reality. - Seneca
I decided a little under 2 years ago to move into the iOS development world. Had a project I could sell ;) I did not have any Apple devices or computers and had not used an Apple product since an Apple II. ;) to deploy. But it does work pretty well considering I am managing and supporting devices scattered through out the US remotely. The biggest issue during the process was Apples repeated updates broke everything from the code, to signing, to deployment again and again and again. But with the latest XCode and Swift 4 seems to be better and stable. ;) ;)
;)
So I picked up a Mac Mini and installed XCode and I was off. While I was more comfortable with Obj-C. I made the choice early to go with Swift. I think it was Swift 2-2.5 or something.
The hardest part was moving to the Apple/Swift way. And the Apple Developer/VPP/DEP/Apple Enterprise Developer/MDM Management world. It is in my mind a bit complex
Anyway, What I delivered/got paid for by my client was a Swift 4 app with some Obj-C in specific places
I think Apple will move to Swift for all development eventually. But as with all things Apple they could turn on a dime in future and head off on an entirely new direction abandoning everything and everyone Swift
Just my 2 cents
And Fluttershy for MLP! Yay!
#DeleteFacebook
You using it wrong, peepaw!
It appears that there is currently only one Swift compiler in existence and no ANSI or ISO standard. That means the language is not ready for prime time (just like C# and Java).
So Swift was a rip-off a language released 2 years later, and Apple accurately stated that source compatibility would be broken. You are mixed-up and stupid.
Very verbose syntax, and at least for me, hard to read/parse.
I agree with the lack of introspection and dynamic dispatch being a bummer, though. And the Smalltalk style message passing appeared attractive.
There was a time that this was not an issue because the alternatives were equally clunky and probably worse. But I would not be programming anything on iOS these days if it were not for Swift.
Swift is perhaps slightly better than javascript.
Which, believe me, is the faintest praise I can imagine.
Apple recently announced they were withdrawing support for OpenGL, even though it's now the most widespread graphics platform. Instead Apple expects developers to write only for their Metal platform.
Fuck Apple. It's Microsoft all over again. The irony is today Microsoft is more open than Apple!
Programming languages such as Lua, Objective-C, Erlang, and Ruby (on Rails)
People, including TFS, seem to always conflate Ruby with Rails. Ruby is a programming language with many features, including easy metaprogramming for the creation of DSLs and useful frameworks. Rails is just one of these frameworks. It is definitely not a programming language in the way Lua, Objective-C, Erlang, or Ruby is.
Swift was created to be an easier & less error prone language to develop iOS apps (and now macOS apps).
When I decided to create a mobile game (Slide Tilt Roll for iOS - 100% free) I took a look at the landscape and decided to go with iOS as I already had an iMac, so the toolchain & libraries are free to use. I then looked at Objective C versus Swift. While I've been programming in C for 30 years, I went with Swift as the syntax was much easier to read.
Sure there were hiccups. I had to sacrifice iOS 7 compatibility because of a catch-22 which Swift 3 introduced in OpenGL uniforms. And I know the lack of a stable ABI is a major limitation for some developers.
Didn't we all wonder the same thing about C# ?
Same thing with Ruby, Rust, Java?
What a turd Java is. Man thing is always needing to be updated. It's also like the cockroach of languages. Never know where in the filesystem you'll fine an instance of old java laying around because the developers didn't know how to write java code such that it would work under newer versions. Lots of incompetent Java people out there.
I've been an iOS developer since 2009 - wrote a few free apps for fun, made a good chunk of change from some freelancing work doing it.
I tried for fun to rewrite one of my aging tower defense games in swift, but this time I thought I'd improve on the game emmensely and maybe sell it for $0.99 on the app store. Who knows maybe I'd make a bit off of it. This was when Swift was still a 1.X and they had just announced swift 2.0. I thought, ok how bad could it be - how much could they change, might as well just make it for 1.X and just migrate the code later when 2.0 comes out.
Turns out 2.0 came out and after updating Xcode and running the migration tool, I ended up with so many errors, warnings, and broken code that the entire app I had just spent months remaking was completely broken, and I had no idea what I needed to do to fix all of the issues. I got discouraged, annoyed, and so upset that I haven't touched the code again since. The app would even crash immediately after trying to open it on my phone - but only after an iOS update - no reuploading to the phone to make everything break.
This isn't the first time I've been burnt by apple - I was doing Mac Apps during the period of ARC becoming non-optional after always doing my own memory management - meaning huge refactors everywhere that time too. All the while, anything I've ever written for android or windows still plugs along to this day.