Four Years On, Developers Ponder The Real Purpose of Apple's Swift Programming Language (monkeydom.de) 262
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.
Walled garden (Score:3, Insightful)
Re: (Score:2, Troll)
This.
The purpose of Swift is to make it more expensive to support multiple platforms.
Re: (Score:3)
Near as I can tell this is one of two purposes. The other purpose is that many "app" developers are not professional programmers.
Anyway, the lack of support for C/C++ is going to hurt them in the long run, probably not even that long run. For example if they want to improve Metal adoption, they probably need to get C support out there soonest.
There are plenty of languages out there that address one concern or another that various types of programmers have or don't want to deal with, and C/C++ support ensure
Re: (Score:2)
For example if they want to improve Metal adoption, they probably need to get C support out there soonest. ... why not write straight in assembler?
I doubt you find many macOS or iOS developers that are fluent in C - or willing to use C. Why would anyone even think about C for a desktop OS or writing Apps is beyond me
Re:Walled garden (Score:4, Insightful)
Most programmers aren't going to write directly against a graphics API either, but those APIs are typically consumed by big engines that are written in C/C++, for good reasons, and it is hard to write swift that calls C/C++ and vice versa.
Re: (Score:3)
C++ objects and Swirft objects don't interact seamlessly, however writing the relevant glue code is easy to google, e.g. http://www.swiftprogrammer.inf... [swiftprogrammer.info]
For C-APIs you don't need glue code, only Swift function definitions: https://theswiftdev.com/2018/0... [theswiftdev.com]
So what exactly is your point?
Re: (Score:3)
This is the opposite of what is needed. If you have your favorite high level graphics engine (not necessarily Unity or Unreal, if you're a small indy), it's probably in C++, sometimes plain old C. The good ones have abstracted the underlying OpenGL/DirectX interaction, so if you want to support Metal, which you really might wish to do, you have to figure out how to call it. It's designed to be called from Swift. You're not going to rewrite your entire engine in Swift just to support OS X, which isn't the wo
Re: (Score:2)
Calling C is trivial in Swift. Grouping C and C++ together in this respect just makes you look like an idiot.
Re: (Score:2)
What lack of C/C++ support? Swift can't bridge to C++, but it does bridge nicely to C. And all platforms which Swift supports also support C and C++. Do you have an actual argument, or are you just spouting stuff that looks technical, but makes no sense?
Re:Walled garden (Score:5, Informative)
Indeed. Sell it as the next greatest thing that everybody must use and then, when everybody not too smart is on it, change is so that there is no way out, support on other platforms gets very difficult and independent implementation become non-viable. Pretty classical attack.
And name me other Apple Open Source projects where they have employed your paranoid business plan.
Bonjour: Open Source, and certainly not Apple-Specific.
launchd: Open Source, and certainly not Apple-Specific.
GCD: Open Source, and certainly not Apple-Specific.
Webkit: Open Source, and certainly not Apple-Specific.
Swift: Open Source, and certainly not Apple-Specific.
OpenCL: Open Source, and certainly not Apple-Specific. (In fact, now even Deprecated by Apple).
CUPS: Acquired by Apple, and continues as non-Apple Specific Open Source.
LLVM: Open Source, and certainly not Apple-Specific.
Clang: Not Apple owned, but Apple is the major contributor to the Open Source Project.
ResearchKit, CareKit. Open Source iOS Projects that are apparently not Apple-Specific.
Darwin: Open Source, and somewhat non Apple-Specific. ...and many more.
Re: (Score:2)
You haven't made any arguments, either. Only some ridiculous accusations for which no evidence exists.
Re: (Score:3, Insightful)
If Swift is to be considered a 'walled garden', then so should just about every other programming language out there.
No, just programming languages that are primarily used by a single platform, with very little real use outside of that platform, where that platform is controlled by a vendor big enough to encourage people to put up with it. In the present day, Objective-C might actually fit that definition too. Of course C# is probably an even better example of this.
Re: (Score:2)
Apple fully supports the Linux port, and there is an unofficial Windows port. That covers every server and desktop that matters these days. (The Windows port still needs a lot of work.)
Re: Walled garden (Score:5, Insightful)
Are you saying I can take a Swift app designed for macOS or iOS and recompile on Linux with almost no effort? If most of the frameworks are not ported as well it is not really a viable solution. For C# there is Mono and even this is not getting a huge traction beyond a few projects.
Re: Walled garden (Score:2, Insightful)
Is Linux a 'walled garden' since we can't take software using Linux-specific APIs like cgroups and ALSA and evdev and easily compile/run them on OSes like macOS and Windows?
Re: Walled garden (Score:5, Insightful)
Is Linux a 'walled garden' since we can't take software using Linux-specific APIs like cgroups and ALSA and evdev and easily compile/run them on OSes like macOS and Windows?
Exactly this.
So many Slashtards want to assign the epithet "Walled Garden" to ANYTHING Apple does, regardless of how much they Open Source it, or make it as platform-agnostic as possible.
It's just ridiculous.
Re: Walled garden (Score:4, Insightful)
Actually, you should separate the language from (OS-specific) libraries.
For example, we are currently developing a large-scale software consisting of various components.
Some servers are written in GoLang and some others are written in Swift.
The beauty is that the part that is written in Swift can be developed & tested on MacOS directly in Xcode. This server-component is written by a former iOS/macOS-developer, who knows Swift very well.
The runtime environment is Linux. So, we develop on Linux AND macOS (depending on what each developer knows best), in Swift AND GoLang and since all server components communicate using REST-API with each other, nobody really cares which language is used - as long as it works.
Our experience so far with developing server (or: systems-)software with Swift (4.x) is really great. The turnaround times are very short since the developer in question already knew all the Swift-quirks.
Of course, we don't use any macOS libraries at all, only those that come with standard Swift for Linux (plus some FOSS libraries).
When the whole system is up and running, we will evaluate both languages on performance (development- & runtime), cost, maintainability and decide whether we continue doing it in both languages or decide for one or the other.
So, I don't really see a walled-garden here...
Re: (Score:3)
Are you saying I can take a Swift app designed for macOS or iOS and recompile on Linux with almost no effort? If most of the frameworks are not ported as well it is not really a viable solution. For C# there is Mono and even this is not getting a huge traction beyond a few projects.
Not no effort. Swift is available for Linux. But it's not the same. The standard library is different. No such thing as Cocoa on Linux. This is one language where platform is definitely important.
Re: (Score:2)
Objective-C is still a better language than Swift.
I think even Apple would agree at this time.
But since Objective-C was born out of Smalltalk about 1981, lets see how good Swift is in about 40 years...
Re:Walled garden (Score:5, Interesting)
Apple really likes to play up Objective-C as the competitor to Swift, but the elephant in the room is Objective-C++, which (since C++11) is a far better language than either. You can have the late binding of Objective-C objects and the compile-time specialisation of C++ templates and switch between them easily. With ARC, you can store Objective-C object pointers inside C++ collections and have the memory management work properly (which was the biggest irritation of pre-ARC Objective-C++). If you use C++ objects as instance variables in Objective-C, then their destructors run automatically after -dealloc, so the memory management works both ways (you can, for example, use C++11 unique_ptr or shared_ptr to manage ownership of non-Objective-C resources by Objective-C++ objects). Most importantly, it has a trivial way of using C++ libraries, something that Swift can achieve only if you wrap them in [Objective-]C.
Re: (Score:2)
Apple has supported Objective-C since 2000, or so (I'm too lazy to check when exactly OS X 10.0 was released).
Real purpose: lock-in (Score:4, Insightful)
Re: (Score:2)
The problems are not the languages but the UI Frameworks (and Filesystem and Network Access).
Re: (Score:2)
Mac OS is based on one of the BSD's... it should just be POSIX-compliant. That's WHY we have standards.
Re: Real purpose: lock-in (Score:2)
ABIs are largely irrelevant with open source, so languages without large communities of developers working inside walled gardens don't prioritize that.
Re: (Score:2)
You can open source iOS apps, and you have closed source on Windows and Linux. The two are orthogonal. And the benefits of ABI come with the libraries. Specifically, the ability to ship standard or common libraries with the OS, and expect that apps will be able to use them. Even glibc relies on ABI compatibility.
The one language to rule them all (Score:2)
Re:The one language to rule them all (Score:4, Funny)
Re: (Score:2)
That's been quoted here so often I now recognize it by number. (mod guideline: -1, painful truth)
You're looking in the wrong place... (Score:3, Insightful)
Re: (Score:2)
> Every minute that a developer uses to learn Swift, is a minute not spent on learning a non-Apple technology
And that was true of Obj-C for the last 30 years, so... yeah, solid argument there.
Re: (Score:2)
...And that was true of Obj-C for the last 30 years, so... yeah, solid argument there....
Obj-C was not developed by Apple. It was used by Apple (and, btw, NeXT), but it was developed separately from Apple by StepStone.
Re: (Score:2)
Can you name a platform that has an Objective-C compiler today, and not a Swift compiler? An original NeXTstation, I guess.
Re: (Score:2, Informative)
gcc has an Objective-C compiler. It’s just as standard as the C and C++ compilers, though your package manager almost certainly have it as a separate package from the C and C++ compilers (which are, themselves, also usually separate).
It’s not particularly difficult to get your hands on an Objective C compiler.
Re: (Score:2)
"No" is a lot easier to type.
Re:You're looking in the wrong place... (Score:4, Informative)
Every linux distro that installs the gcc suit has an objective-C compiler ...
And if you really want to: a Switft compiler to, directly from swift.org: https://swift.org/download/ [swift.org]
Re: (Score:3)
Clang supports all of the features of Objective-C on all *NIX platforms and Windows. The GNUstep Objective-C runtime, in combination with clang, supports a superset of the language features of Apple's implementation and is used by Microsoft in their Windows bridge for iOS. You might be surprised at some of the places Objective-C ends up - there are quite a few larger (mostly non-Web, though there are also things like SOGo) server systems that use Objective-C - I've consulted for a couple of companies that
Re: (Score:2)
Every single platform has an Objective-C compiler. Just because it's not in VisualStudio doesn't mean it doesn't exist.
Re:You're looking in the wrong place... (Score:4, Informative)
...And that was true of Obj-C for the last 30 years, so... yeah, solid argument there....
Obj-C was not developed by Apple. It was used by Apple (and, btw, NeXT), but it was developed separately from Apple by StepStone.
Because Apple used Pascal, then extended it to object pascal. Then people wanted C, but they needed object semantics to port the object pascal libraries and C++ wasn't ready and was ugly as sin, so they went with Objective C, which is uglier. They were swept along with the stream like everyone else.
The real problem with Swift is not the language, it's that when you try to use swift to program a mac or iphone, you spend most of your programming time interacting with the libraries in arbitary ways invented by Apple and every example on the internet seems to be written in Objective-C. You're left guessing at what the Swift equivalent would look like.
Re:You're looking in the wrong place... (Score:4, Informative)
You have your history completely wrong.
Objective-C was created by Dr. Brad Cox in the Mid 1980s - https://en.wikipedia.org/wiki/... [wikipedia.org]
Objective-C is a mashup of ANSI C and Smalltalk. Smalltalk is the original Object Oriented programming language created by Alan Kay in the 1970s. Alan Key coined the term, "Object Oriented", to describe Smalltalk. He later said, "I coined the term Object Oriented, and I promise, C++ is not what I had in mind." He has also said he wished he called Smalltalk "Message Oriented" because messages are the key, not objects.
Steve Job's NeXT Computer Corp. used Objective-C to create NeXTstep graphical frameworks currently known as Cocoa (Foundation Kit, App Kit, etc.) and Cocoa Touch (UIKit etc.) NeXTstep shipped commercially in October 1988.
Apple purchased NeXT in December 1996, and NeXtstep eventually became Mac OS X and iOS.
Re: (Score:2)
>You have your history completely wrong.
Not at all.
I'm talking about Apple's adoption of languages. If you are of a certain age, you will remember a time before NeXT, before SJ left Apple when there were Apple ][s, Apple //es, Lisas, Early Macintoshes. At no point did I claim that Apple invented these languages. Why are you implying I did? Why is the name of the creator of Objective C relevant to my statements about Apple's adoption of Objective C?
You may be 12 years old and so were not around when these
Re: (Score:2)
Object Pascal was Borland's dialect of Pascal.
Re: (Score:2)
Re: (Score:2)
Just because no one else is doing serious development with ObjC does not mean you are locked in. The clang compiler is part of the LLVM suite, and is available on every platform that the rest of LLVM is available on. Nothing is stopping anyone from creating ObjC libraries on non-Apple platforms.
Re: (Score:2)
...And that was true of Obj-C for the last 30 years, so... yeah, solid argument there....
Obj-C was not developed by Apple. It was used by Apple (and, btw, NeXT), but it was developed separately from Apple by StepStone.
Yeah, for awhile, then it was licensed by NeXT in 1988, who extended the language a bunch, then it was transferred to Apple when Apple acquired NeXT.
It is currently listed as being owned by Apple.
Re: (Score:2)
Yeah, it is true that Objective-C was also a lock-in language, but Obj-C itself is behind the times. Most userland is moving to managed code, and even Apple couldn't keep programmers away using a 30-year old outdated language. So Apple needed - and created - a new lock-in languages. It's called Swift.
Yeah, they're Lock-In Languages, alright.
Objective-C is part of the gcc compiler.
Swift is Open Source and already has ports in Linux and Windows.
Sounds Locked-In to me.
Idiot.
Re: (Score:2)
Why do people write such nonsense?
How can a developer be locked in? If I'm payed to write software for Apple OSes ... why would I care that "I'm locked to Swirft"? Next year I write software for Linux and use C++ and Qt ... wow, that was easy.
Re: (Score:2)
...why would I care that "I'm locked to Swirft"?...
You don't need to care, Apple does. If you are writing for Swift, that is time you are not honing your skills in, or learning, other languages. Unless, of course, you've figured out how to tap into your other selves in the multi-verse...
Re: (Score:2)
Apples does not care about that.
If at all a programmer cares ... because it is his job future that is at stake. Apple does not care if you switch from Mac/iOS development to Android/Linux/Windows ... aka C/C++/Java. It is completely irrelevant for them what a single developer or a group of developers does.
If you are (1)writing for Swift, that is time you are not (2)honing your skills in, or (3)learning, other languages.
Get a clue. What are you doing? Writing a program (1) for profit?, honing your skills in
Re:You're looking in the wrong place... (Score:5, Insightful)
How can a developer be locked in?
It will become self-evident to you after you have written your first major application in a platform-specific language and/or environment that you want to make available on some other platform.
Until then, I will provide you with the most common scenario:
You are a company or independent developer who has unwisely decided to write thousands, tens of thousands, hundreds of thousands, or millions of lines of code which uses a vendor-specific language. You are happy with your product, and you are happy with your vendor. All is good in your world. You have spent a huge amount of time and money on making your products, and you can't afford to do it all again from scratch. But you're okay with that, because your vendor is AWESOME, and you just can't foresee a reason why you would ever leave such an incredible experience.
You become disillusioned and/or pissed off with your language vendor (for whatever reasons; they don't matter for this discussion. Just know that it happens a lot), so you decide, "screw them! I'm out of there!" But, oops! You have written yourself into an intractable dependency on that vendor, because you didn't have the experience to understand how vendor lock-in works. You don't have the resources to rewrite from scratch, so you wind up having to surrender yourself to the whims of your vendor.
You plead with your vendor to be reasonable, but your vendor DOES have the experience to know how vendor lock-in works. So not only does your vendor ignore your pleas for mercy, but they raise their prices and/or make more unreasonable demands of you that you have absolutely no power to fight. You find yourself with no choice but to either cave to your vendor's demands, or go out of business.
You realize too late that had you used cross-platform technologies from either the very start, or at least switched to cross-platform technologies early on, you could have told your scumbag vendor to piss off; and then you could have found a different vendor to support you.
Re: (Score:2)
You do realize you are contradicting yourself?
Either I'm happy with my product and sell it good, and hence I'm not (yet) affected by vendor lock in, or I'm not, then I switch immediately.
If I'm happy I make so much money that I can rewrite the software anyway, so: "the I don't have the resources" scenario can actually not happen.
Then again: it is the customer who decides. If the customer runs only Macs, I have to write for Macs, plain and simple.
Regarding the topic: you can easily write software for Macs in
Re: (Score:2)
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.
Um, Swift is Open Source.
How does that lock ANYONE in to an "Apple World"?
You stupid Haters REALLY need to think before posting your stupid, imbecilic drivel.
Re: (Score:2)
...What a dumb argument. That applies to most other programming languages, too....
Except that Swift is Apple's language. Duh. :)
I'm out (Score:2, Insightful)
Re:I'm out (Score:4, Interesting)
It is pretty hard to avoid vendor lock-in due to APIs nowadays.
And of all the languages, I daresay Swift is one of the few that's in a clear direction heading away from vendor specificity and toward open access.
Re: (Score:2)
How is it not "native" on Linux? The toolchain creates native binaries, and Swift can interop with C, including the clib, just fine. There's no pre-existing UI toolkits, but that's hardly Apple's fault. Not as if Apple wrote UI/AppKit just for Swift, after all.
Re: (Score:2)
Swift is otherwise not too native on Linux and Windows.
What exactly is native? I mean being native on Windows / Linux means being C/C++ or on Windows .Net thanks to a pretty herculean effort by MS to provide very complete platform integration (and you still have to call into even first party C/C++ libraries sometimes to get some things done effectively).
As to Python / Ruby neither can do anything at all natively other than file and socket operations. Both do offer good web stacks probably because socket operations were easier than doing any kind of native inte
Re: (Score:2)

After writing an entire application stack in C#/.NET we will not continue using Micr
Bottomline == Maintainable (Score:5, Insightful)
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.
Swift made us dump our in-house iOS group (Score:2, Informative)
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.
Re: (Score:2)
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.
Mmmm. Bet that is going just peachy.
Stupid PHBs.
Re: (Score:2)
Why on earth would you rush to port your entire existing app to swift? The languages interoperate pretty well.
Oh please. (Score:5, Insightful)
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.
Re:Oh please. (Score:5, Funny)
Thâ(TM)at woâ(TM)rks ouâ(TM)t siâ(TM)nce Iâ(TM)m tiâ(TM)red oâ(TM)f râ(TM)eading iâ(TM)t.â(TM)
Re: (Score:2)
Re: (Score:2)
You're really blaming the wrong party here. Sure, Apple is replacing normal quotes with "smart" quotes, which not everyone prefers for various reasons. By itself, however, that would be a minor issue, and at least they are following the Unicode standard. The way those smart-quotes are mangled is not Apple's fault; that's entirely due to Slashdot. Between the ongoing failure to handle Unicode properly and the persistent lack of IPv6 support, Slashdot is falling remarkably behind the times for a tech-focused
Re: (Score:2)
Apple said from day one that Swift would not remain source compatible until Apple says that Swift will remain source compatible. Apparently, everyone in the world except you got the message.
Swift is not alone (Score:5, Insightful)
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...
Re: (Score:2)
In the White House?
Re: (Score:2)
Blockchain, can anybody think of a revision system ? GIT, SVN ?
Blockchain is very different from GIT and SVN, both of these trust all users, which can't be done with financial transactions.
Students are not interested
Looks like the old people are not very interested either, what I just wrote is really the basic idea of blockchain, to be able to handle hostiles as well as friendlies (assuming that there's not too many hostiles).
Nil is a feature (Score:4, Interesting)
> 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.
Re: (Score:2)
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.
So... you read an object that has no description because field is nil, show it in a dialog and afterwards the description is "0"? Why not the empty string ""? And when doing debug messaging I usually replace it with "(null)". And you sure don't want to convert nil to zero when it comes to numbers because for a field like "number_of_kids" nil would typically be used for unknown / didn't want to answer / not relevant / not applicable. That said, I wish they'd turn it around so you'd get a nil assignment error
Re: (Score:2)
Classify the implicit optionality of objects purely as a source of bugs.
Among other issues, this remains my biggest complaint.
This is what you choose to complain about, fixing the "billion-dollar mistake" [infoq.com]? You 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. H
The next language (Score:2, Interesting)
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 compute
Swift is for Grandpa (Score:3)
CPU transitions (Score:2)
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.
Re: (Score:2)
I'm talking about a seamless transition for the programmers, not the users.
Doug Crockfield (Score:2)
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.
ObjC to Swift, 4 years in (Score:4, Interesting)
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.
Re: (Score:2)
This.
HUGE fan of Objective-C, back from the NeXT days. Been writing iOS apps since ARC was optional and I never used it, because *I* knew how to alloc and free memory. Yeah, that meant it was a pain in the ass when Apple made ARC a requirement.
I miss introspection, sure. But optionals, tuples, native unicode support, default parameters, conditional generics, and a consistent calling syntax just makes my life easier. Add to that first-class immutable structs, better functional programming support, and stron
Swift solves NIH - "Not Invented Here" Syndrome (Score:2)
Reduce bugs + Retain performance (Score:3)
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/... [techspot.com]
FYI - some infoq: 47% of apps crash more than 1% of the time: https://www.infoq.com/news/201... [infoq.com]
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... [appcoda.com]
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).
Re: (Score:2)
Again, iOS apps crashed 47% more than Android apps - That is a relatively HUGE difference in experience.
---
Android 2.3 'Gingerbread' had a crash rate of 1.7%, for example, while iOS 6 apps crashed 2.5% of the time.
(1) iOS apps crashed more than android apps. Apple would have noticed the common causes for application crashes on iOS and 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.
Go (Score:2)
Microsoft has Visual Studio (C/C++, C#, Basic, etc). Google has GO. Apple has a pissing contest, I mean, Swift.
You lost me at Cocoa (Score:2)
Re: (Score:2)
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.
Eh, I spent the 90's working on NeXTSTEP stuff and abandoned Apple for a decade or so after the merger, but my opinion is exactly the opposite - after using NeXTSTEP, I looked at MacOS and could hardly believe that that was what Mac was running in the late 90's. Simply put, they were mired down by technical constraints which were making it increasingly hard to make broad changes and were looking for a way out. They didn't just realize it when they acquired NeXT, they'd already failed to build a replacemen
Swift has never made sense to me (Score:2)
Really (Score:2)
"..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.
Re: (Score:2)
"..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.
Part of being an effective developer is choosing the right tool(s) for the job. If you choose poorly, you end up spending too much of your time fighting the mismatched tools rather than getting your program working, and you end up with a poor-performing/buggy/hard-to-maintain program that took a long time to develop and may have to be thrown out anyway.
Even a florist would know better than to use a jackhammer to trim bouquets.
It *does* look better than Objective-C ... (Score:2)
.. 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 offeri
As an older(62) developer that picked up SWIFT (Score:2)
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 Manage
As usual in these cases (Score:2)
You using it wrong, peepaw!
Re:fr0sted PI55 (Score:5, Interesting)
Please identify the (de-jure) standard for VBA. "Microsoft's current compiler" is not a -standard-.
Re: (Score:2)
That's what you get for coding with Apple's proprietary garbage language instead of a standards-compliant one like C or VBA.
You're calling VBA "Standards-Compliant"?!?
Ok, I think we're done now.
Re: (Score:3)
Given the size of Apple's bank account, shouldn't we be writing Appl€?
Re: (Score:2)
Why don't you do that and give us a summary of the results rather than handing out homework assignments to everyone?
If you have a point, make the point yourself.
Re: (Score:2)
> Now compare time and effort spent on languages and toolchains that can't run on the GPU
Hmmm, interesting point.
Re: (Score:2)
Schwifty... in here [youtube.com].
Wubba lubba dub dub.
Re: (Score:2)
And Fluttershy for MLP! Yay!
Re: (Score:2)
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.