18 ms·

My misalignment with Apple's love affair with Swift

139 points by mgrayson 8y ago

elcritch 8y ago
> It seems to have been driven by the needs of the compiler and the gaps that needed to be filled for the static analyzer. Those seem to have been super-charged instead of catering to app developer's actual needs: efficient, hassle free, productive (iOS) App development. This. Even then Swift (the last I really looked like v2) was full of special one offs and smacked of design by committee. It would’ve been much more interesting if they’d worked on making an updated Objective C language. Maybe even break C superset constraint and add in some new syntax. It’s even more sad that ObjC message passing can support distributed systems. Probably time to move back to Linux. Too bad GNUStep never took off. Or Etoile (?).
- dwaite 8y ago
  Swift has changed a lot since v2, which was before it was open sourced and honestly before they had sufficient tool quality for medium and large projects.
- saagarjha 8y ago
  > This. Even then Swift (the last I really looked like v2) was full of special one offs and smacked of design by committee. How so?
  - elcritch 8y ago
    Here's one link [1]. It's dated and so hopefully many of these have been resolved. Swift doesn't solve any problems for me so haven't really looked at it again for a long while. Mainly it seemed that instead of supporting full functional concepts, they one-offed feature that _looked_ like it was functional but weren't. Unfortunately I can't find the original article that reviewed the Swift type system. 1: https://www.quora.com/Which-features-overcomplicate-Swift-What-should-be-removed/answer/Rob-Rix https://www.quora.com/Which-features-overcomplicate-Swift-Wh...
    - saagarjha 8y ago
      A lot of those are either fixed, or being actively worked on.
- pjmlp 8y ago
  Pity that KDE is the only environment with something that approaches the Framework stacks of other desktop environments.
ardit33 8y ago
I agree with the author. "So now contrast that to Swift. First of all: Which question did it desire to answer? Think about it. There is no one clean answer." I feel that Swift is more just like a language designed to be a syntax swap of objective-c, making few things better, yet some other ones worse. Sure, it might be more welcoming to people used to java/javascript type of language syntax, but overall I think it is two step backwards on language design and functionality. To folks that are proficient with Objective-C, 1) How do you like working in Swift? 2) Are you more productive (for medium or large projects)? 3) Do you enjoy it more? In my part (if you are already very proficient with Objective-C), those answers are Nos. If you are new to iOS though, Swift is easier to get started. https://www.hackingwithswift.com/articles/27/why-many-developers-still-prefer-objective-c-to-swift https://www.hackingwithswift.com/articles/27/why-many-develo...
- seandougall 8y ago
  1) I've been doing Cocoa development for 13 years, and I absolutely love Swift. I've switched to it for all my own projects (at least the ones where I would previously have used Objective-C), and I'm never looking back. 2) For medium projects: absolutely. For large projects: I haven't had the pleasure yet, but the truth is that Swift encourages a much better approach to modularity, and if you're working in a large project as a monolith, you're probably doing something wrong. 3) Hands down, yes.
- arcticbull 8y ago
  I started developing in Objective-C back in the early 2000s on macOS (as a kid), worked at a big company on some macOS software, then worked on a million-line iOS Objective-C project at another big company for many years. After I left, I picked up Swift. I use it for all of my personal iOS projects. I don't disagree that there are flaws in the language, but they definitely aren't the ones the author pointed out. > Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature. I can't express how happy I am that an object is exactly what it tells me it is at compile time. The number of nuanced bugs that have bit me over the years, my lord. Let alone explaining this stuff to a new coworker? Dynamic dispatch / message passing / introspection are huge bug sources. If you can't rely on the compiler to tell you what something is, what can you rely on?! This alone dropped bugs an order of magnitude. > Define the convenience and elegance of nil-message passing only as a source of problems. Nil messaging is nothing but a source of problems. Can confirm. > Classify the implicit optionality of objects purely as a source of bugs. Implicit optionality was a massive design failure in C. Those days are behind us, it's time to move on. (1) I love working in Swift. It opens up all sorts of great design patterns -- lightweight view model structs, enums with associated values, easy to manage protocols. Readability is dramatically better. No more copy-paste between header and source. No more dealing with unintelligible types, first-class generics, etc. (2) Productivity boosts come from less boilerplate, less repetition, less typing, better design patterns being within reach. Static typing eliminates many classes of common bugs. No automatic nils is huge. I can't remember the last time my app crashed in something other than an Objective-C component or framework. (3) Yes, I do.
pkulak 8y ago
I think the problem it solves is developer PR with Objective C, which looks like absolute hell the first time you see it. Swift looks like a sleek scripting language.
- noecrnt34mw 8y ago
  I never understood this point of view. The first time I saw it, I was like, "Brackets. That's slightly different than I'm used to. They look like arrays or something. Oh well. It seems to work." And from then on it was a non-issue. Why do developers get so hung up on this?
  - ChrisLTD 8y ago
    All the extra symbols did make ObjC more laborious to read and write. ¯\_(ツ)_/¯
    - Apocryphon 8y ago
      Objective-C [] over the :: and <> overload of C++, imo
      - pjmlp 8y ago
        I prefer the :: and <> overload of C++, than having to type @ everywhere.
  - pkulak 8y ago
    I'd think most people would agree that infix notation is far easier to read and write than the Polish-like bracket notation.
majewsky 8y ago
> Swift code might end up being more correct in the end. It also might alert you to edge cases early on. However, the flip side is it inhibits your creativity while writing. When starting out to program, the way I enjoy working, I don't yet know how the API is best expressed. So I try out different ways to express it until I find a sweet spot. Then I go back and unify accordingly. > Swift actively distracts me in that endeavor by making me answer questions I really don't want to answer right now. Yes, stuff might be less correct in the meantime, but heck that is what I want during the design phase. Find my concept, sweet spot, iterate, pivot quickly. I have much of the same feelings with Rust.
- deltron3030 8y ago
  It might make sense to differentiate between prototyping and implementation languages. As a design first company, they don't prototype in code, they use code to implement prototypes. With Swift they're just serving their own methodology. This also fits into their "we don't need to collect data" mindset, they seem to iterate on assumptions, not direct feedback from customers. They create many prototypes and then implement the most viable one, and and this point they know exactly what they need.
  - majewsky 8y ago
    That's a fine approach when you prototype a UI or a process, but it doesn't help if, f.i., you want to try out a specific Rust library.
  - archagon 8y ago
    Would be neat to have a language with dynamic features for prototyping, but that become warnings or errors when compiling for release.
mmjaa 8y ago
I agree with the author on all points, except one: there isn't any reason not to just use Lua for everything. Yes, thats right. Lua for everything. Lua on iOS, Lua on MacOS, Lua on Linux. Lua on Windows. I absolutely love the freedom, flexibility and downright sexiness of using one language on all of the platforms. Its a beautiful, difficult, lonely place to be - but if you haven't tried it, you can't really knock it.
- lifeisstillgood 8y ago
  I am unfamiliar with mobile coding but I presume there are really good reasons to use the "blessed" language on ios / android - I would assume any scripting interfaces leave many useful (security) areas unavailable? Could you access the secure enclave for example in python or lua?
  - mmjaa 8y ago
    Yes, you sure can. Anything you can do in Objective-C or Swift, you can do in Lua.
- vbezhenar 8y ago
  Custom JIT is forbidden on iOS, how are you going to write performant code? I could see only JavaScript as a proper alternative.
lifeisstillgood 8y ago
> Swift actively distracts me in that endeavor by making me answer questions I really don't want to answer right now. Yes, stuff might be less correct in the meantime, but heck that is what I want during the design phase. Find my concept, sweet spot, iterate, pivot quickly. This is also what annoys me about TDD - writing code is a process of refinement - if I know exactly what the API I am going to program against looks like, if I know the API I will offer and I know the internals of my code are before I write code then hell, I have done it before. Often times coding is exploring.
- vbezhenar 8y ago
  Eclipse Java compiler had a neat feature. It could compile wrong Java code into a working bytecode. Wrong instructions were replaced by throwing exceptions. So you could run incorrect program (it wasn't 100% bullet proof, of course, curly brace mismatch could render your program absolutely useless, but it worked in majority of cases). This greatly helps with development. I can stop my unfinished work in one place and test another, for example.
- duckfruit 8y ago
  Idris has a really neat feature called 'Holes' that does exactly this. I wish it could be implemented in every language on earth.
bsaul 8y ago
As a mobile & fullstack developper, my road also takes me to different languages but for very different reason. To me swift is at its core the best language by far. I love the way it lets me model pretty much every problem using combination of enum and struct, while keeping everything value-based and type safe. If you add null safety, there is no other (mainstream) language that checks all those marks. But the OP is right in that Swift aims at being a silver bullet, yet the pace at which it evolves compared to that goal is absolutely scary. Concurrency hasn't moved at all, and in the meantime server side performance is a total disaster (https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=fortune https://www.techempower.com/benchmarks/#section=data-r16&hw=...). There is also nothing for cross-platform development (real cross-platform, not just iOS and macOS). So, personally, my next experiment is going to be full stack dart.
- seandougall 8y ago
  That benchmark seems to list only Kitura. I wonder what it would look like with Perfect, Vapor, or Zewo. > Concurrency hasn't moved at all Yeah, it hasn't moved because GCD is already pretty mature, and they don't seem to have made any effort at other concurrency paradigms. I'd love to see how something more like CSP would work (Zewo has an implementation, but I haven't had a chance to work with it yet). > There is also nothing for cross-platform development (real cross-platform, not just iOS and macOS). Not yet; it doesn't quite seem like it's ready to be a practical goal. I'm curious to see if that changes when they manage ABI stability.
  - bsaul 8y ago
    GCD is a library, not a language construct. As such it is extremely raw, and i've got a strong suspicion that the fact that it wasn't built for server-side style concurrency is one of the reason kitura is dead slow in the benchmarks. Those kind benchmarks usually spawn thousands of simultaneous connexions, which is very far from what an app generally requires (but i could be wrong). It also doesn't provide more parallelism regarding i/o than os-based threading. go has light threads which makes context switching fast, and node has async i/o all over the place. Maybe Swift NIO would make a difference, but it would only make swift catch up to what the first version of node.js provided. My point was that this manifesto https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9... has been written 1 year ago and nothing has been implemented or announced at wwdc (but maybe i missed a talk...)
chadcmulligan 8y ago
Its interesting how languages divide opinion. For me I think Swift is the best language around. One of the issues not addressed in the article (I believe) is performance, Swift is faster than Objective C because of the static type checking, which is a good thing. It has the advantages of C# as a language but no garbage collection, granted the reference counting in Swift can be problematic, but it seems to be improving with each release. The functional programming aspect of swift I find useful. There are a number of features in swift that decreases the amount of code - e.g. if let/guard. The use of optional types increases program safety. The fact that you can use classes declared elsewhere without any consideration of dependency I find very powerful, and of course with great power comes great responsibility. The power of swift collections is fantastic, and the syntax compared to Objective C is so succinct. Many more...
- sheeshkebab 8y ago
  Faster than ObjC? Unless your objc code is written using nothing but id and reflection, I’m not sure how can this be the case...
  - saagarjha 8y ago
    > Unless your objc code is written using nothing but id and reflection That's how all Objective-C code is written–every method call goes through objc_msgSend.
    - sitharus 8y ago
      To be fair to objc_msgSend it's orders of magnitude faster than most reflection APIs. https://www.mikeash.com/pyblog/performance-comparisons-of-common-operations.html https://www.mikeash.com/pyblog/performance-comparisons-of-co... has some benchmarks, it's a bit old but I don't think objc_msgSend would get slower.
      - saagarjha 8y ago
        Yup, I'm not saying objc_msgSend is slow: it's just that it's not faster than a direct call, and I believe about on-par with a virtual function call.
protomyth 8y ago
I find myself in the same boat. I've programmed in Objective-C since 1995 on NeXTSTEP. I love Objective-C, but realize it has quite a lot of warts. My problem with Swift is my feeling that the people who developed it don't like Objective-C. It really feels like the Java direction Apple tried to take in the late 1990s. You can argue Nil messaging but its part of the landscape. Plus, I really find weird way they adapted message passing to the C++/Javascript like syntax. A simple obj.(selector: value selector2:value) would have made it much easier to go back and forth. This is mismatch affects things. Never mind the added punctuation that need not be there. I should be much more productive, but I'm not and that sucks.
fpoling 8y ago
A friend of mine have been working with porting to iPhone some Android and web apps. I recently asked his opinion of Swift. He said he had no idea as the essential libraries the apps use are in C or Objective-C, so there were no choice but to use Objective-C for the apps. This was surprising, as I thought that calling Objective-C from Swift should be transparent. But it turned out it was not as many small but important details make the whole thing rather messy. So I also wandered what exactly Apple wanted to get with Swift if it lacks even in Objective-C interoperability.
- seandougall 8y ago
  I'm not sure where your friend was getting that information, or what small details he was referring to. Calling Objective-C from within Swift is remarkably transparent -- where you might have called `[foo bar:baz];`, you call `foo.bar(baz)`. In some cases, wordy Objective-C names will get mapped to Swift's tidier conventions, but the public APIs are all documented in both languages, and Xcode's auto-complete is pretty good at helping you figure it out.
  - fpoling 8y ago
    The issue was with exceptions.
- dwaite 8y ago
  Swift was designed to have very good Objective-C and C compatibility, using the clang compiler to understand headers and generate any Swift binding/bridge at compile time. It will punt on trying to support some things, such as inline functions which are declared as C macros, but generally will try to expose everything. Typically a maintained Objective-C library will evaluate their ability to be used from Swift, and use attributes/macros where necessary to tweak the code import to generate a higher quality Swift interface. Examples would be declaring that a method never returns a nil value, or creating a clearer function name, or switching to the newer Objective-C enum/set styles to have the enumerations generated as Swift types rather than having their API take a raw integer constant or string. AFAIK, all of apple's frameworks are C or Objective C interfaces, and the swift interface is nearly all generated based on the code and public annotations.
seandougall 8y ago
These complaints largely seem to come down to Swift not really being what the author expected it to be. His list of speculations as to Apple's motivations, in particular: > It should scale from App/UI language down to system language. Did I miss something where Apple or the Swift team said anything about writing a kernel in Swift? They wanted to make it fast enough for performance-critical situations, yes, but there are plenty of those in userspace -- and I haven't found Obj-C's inability to perform in those situations to be an asset. > It should inter-op with existing Foundation and Cocoa, but still bring its own wide reaching standard library, adding a lot of duplication. This is missing the forest for the trees. Bringing Swift-native Foundation APIs into the standard library means they're available on non-Mac platforms, which is huge. I'm also not sure what alternative would be preferable -- should it _not_ interop with Foundation/Cocoa, and totally fragment the ecosystem? Or should _not_ reimplement them with native calls, so that it inherits the performance penalty of objc_msgSend? > It is functional, object-oriented and protocol oriented all at the same time. Apple describes Swift as protocol-oriented. It's flexible enough to support other paradigms, but I don't see how that's a liability, and I haven't seen Apple claim "Swift is an FP language". > It wants to be strongly typed, but at the same time so convenient in type inference, that it falls over its own feet while trying to grasp simple expressions, and they become too complex to manage. By design. [citation needed] This complaint is so vague as to be impossible to address, except to say that I haven't managed to come across a case of it yet. An example would really help make the case. > It is compiled and static, but emphasized the REPL and playground face that makes it want to look like a great scripting solution. Which it isn't. Again, I haven't heard any claim that "Swift is a scripting language". Sure, it's not, but neither is Objective-C, so... I'm not really sure what the complaint is here? > It seems to have been driven by the needs of the compiler and the gaps that needed to be filled for the static analyzer. Those seem to have been super-charged instead of catering to app developer's actual needs: efficient, hassle free, productive (iOS) App development. This sounds like a complaint about strong typing and static dispatch in general. Yes, you have to code more carefully, but the flipside is that a huge number of errors that crop up at runtime in Objective-C become compile-time errors in Swift. I'd much rather bang my head against the compiler for a while before I ship than have reams of undebuggable crash logs pour in. > It is meant offer progressive disclosure and be simple, to be used in playgrounds and learning. At the same time learning and reading through the Swift book and standard library is more akin to mastering C++. It is quite unforgiving, harsh, and complex. That's true, but that's also kind of a big part of why playgrounds exist. So again, what's the complaint? Is the fact that playgrounds make the language more accessible a problem somehow? Also, the only way I can view Objective-C as "simple" is by ignoring the C underpinnings and looking only at the relatively thin layer of classes and message passing on top. For somebody coming to coding with fresh eyes, both Swift and Objective-C are going to have a learning curve; the difference is that with Swift you don't have to pick up K&R first.
saagarjha 8y ago
The author seems to not be up-to-date with modern Swift: > Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature. There was a proposal recently to make this first-class, and not just limited to Objective-C. > Classify the implicit optionality of objects purely as a source of bugs. Not purely, but often optionality is a source of bugs. > At the same time it failed to attack, solve and support some of the most prominent current and future computing problems, which in my book all would be more important than most of the areas it tries to be good in: > concurrency Concurrency is being hashed out, and will probably be available in a later version of Swift. > overall API interaction complexity The Swift API is refreshingly small. Are you talking about Foundation? > debug-ability What's wrong with the debug-ability, especially with solutions like playgrounds? > actual App and UI development …this is literally the main use of Swift. > developer productivity Personally, I feel it's much improved. > 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. This is almost a non-issue these days, unless you're interacting with C APIs. > Just imagine a world where Objective‑C would have gotten the same amount of drive and attention Swift got from Apple? The ten years before Swift existed?
- blattimwind 8y ago
  > There was a proposal recently > Concurrency is being hashed out, and will probably be available in a later version of Swift. TFA: > It keeps defering the big wins to the future
- EpicEng 8y ago
  >The author seems to not be up-to-date with modern Swift: > Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature. There was a proposal recently to make this first-class, and not just limited to Objective-C. > concurrency >Concurrency is being hashed out, and will probably be available in a later version of Swift Sounds to me like "modern swift" doesn't actually have any if these things. Did you mean to say that the author wasn't familiar with some future version of swift that doesn't yet exist?
pjmlp 8y ago
> However, the flip side is it inhibits your creativity while writing. The old adage of C devs against us on the strong type side of the fence of Algol family. We all know how the freedom for creativity end up. https://www.cvedetails.com/vulnerability-list/opmemc-1/memory-corruption.html https://www.cvedetails.com/vulnerability-list/opmemc-1/memor...
- gurkendoktor 8y ago
  All we are doing with Objective-C is gluing together a few JSON APIs and buttons. The assumption that a single language needs to be fit for both security-critical low-level code and high-level UI programming is exactly the problem with Swift.
  - pjmlp 8y ago
    There is no problem with Swift, it is just another language following the good principles of safe systems languages from 60 and 70's, going on outside AT&T walls. Kudos to Apple.
- erichocean 8y ago
  > We all know how the freedom for creativity end up. You mean, it completely dominates the programming world? C is a massive success story, no other language even comes close.
  - pjmlp 8y ago
    Things given for free are always a success story. Had AT&T been allowed to charge for UNIX since the beginning and not 10 years later after being split by the government and C would have been a footnote on the history of systems programming languages. In a world where many don't want to pay for software, free trumps technical merits.
  - valuearb 8y ago
    C is garbage, a loaded shotgun with no safety. I say this as someone who spent twenty years writing object c code. The only way we survived was to build safety into a massive set of core libraries and use them religiously.
Apocryphon 8y ago
Steven Sinofsky thread here: https://twitter.com/stevesi/status/1005848814048047105 https://twitter.com/stevesi/status/1005848814048047105 Some other good ones tracked by Michael Tsai: https://mjtsai.com/blog/2018/06/10/on-my-misalignment-with-apples-love-affair-with-swift/ https://mjtsai.com/blog/2018/06/10/on-my-misalignment-with-a...
- pjmlp 8y ago
  Given the way Steven Sinofsky team contributed to the political mess of Longhorn/Vista, followed by WinRT split and the mess it brought to Windows and .NET eco-system, he is probably not the best authority to pay attention about programming languages and eco-systems.
dwaite 8y ago
> So now contrast that to Swift. First of all: Which question did it desire to answer? From Swift.org: Swift makes it easy to write software that is incredibly fast and safe by design. Our goals for Swift are ambitious: we want to make programming simple things easy, and difficult things possible. > It should scale from App/UI language down to system language. I don't see how say Go can be a system language and Swift can't. Much of Apple's investment has been around making App and Framework development more productive on their platforms, but Swift is open and other companies like IBM have been focused on things like Web frameworks. >It should inter-op with existing Foundation and Cocoa, but still bring its own wide reaching standard library, adding a lot of duplication. I assume they mean the standard Swift package as the standard library, since they listed Foundation separate. Swift is tiny, basically holding core types like Int, String, Optional, and pointers, Collections (Dictionary, Set, and Array), ranges like 1..<10, and essential common protocols like Equatable and Hashable. It isn't until you get to foundation that you get things like I/O / networking or binary data types. > It is functional, object-oriented and protocol oriented all at the same time. Several of the languages listed in the article as being above as positive (like Ruby) are also multi-paradigm. Swift is hardly a functional language, it just has functional influences - like nearly all the languages listed. > It wants to be strongly typed, but at the same time so convenient in type inference, that it falls over its own feet while trying to grasp simple expressions, and they become too complex to manage. By design. Since there wasn't an example given, all I can really say is there's nothing that requires you to use type inference. My experience from multiple languages is that usually such an expression is wrong, and the compiler cannot figure out any suggestions on how to fix it because a broken expression doesn't give any type inference hints. A dynamic language would just let it crash and burn at runtime, which (if you have a test suite capturing the issue) is such a different process for debugging from fixing type inference at compile-time that they are hard to compare. > It is compiled and static, but emphasized the REPL and playground face that makes it want to look like a great scripting solution. Which it isn't. REPL and Playgrounds are both for experimentation, not necessarily for scripting. You can do command-line swift scripts, but generally the compiler makes them a bit heavyweight for many things. > It seems to have been driven by the needs of the compiler and the gaps that needed to be filled for the static analyzer. Those seem to have been super-charged instead of catering to app developer's actual needs: efficient, hassle free, productive (iOS) App development. Can't say much here vs having a computer analyze your code is meant to be a boon, not a hinderance. My experience is that now when I write Java projects I wish I could get back the expressiveness, performance, and personal productivity I have writing Swift code. > It is meant offer progressive disclosure and be simple, to be used in playgrounds and learning. At the same time learning and reading through the Swift book and standard library is more akin to mastering C++. It is quite unforgiving, harsh, and complex. If nothing else, someone is underestimating the effort of mastering C++.
rockshassa 8y ago
IMO Swift is a language written by a compiler guy to solve compiler problems. the syntax is dense because it forces you to make a lot of decisions that could otherwise go unmade in objc. If a variable is read-only, you're forced to think about that by deciding between let/var. contrast this with objc, where all vars are writable unless you do the extra work of adding the const keyword. objc makes us do more work to get the faster (and safer) behavior. Similar with Optionals, you're now forced to decide right away if a parameter can ever be nil, whereas with objc you didn't need to declare nullability. Again, it makes the safest and fastest choice easier to make, and allowing nullability is actually more work. Generally Swift forces you to pass as much information to the compiler as possible at compile time, and it does it with a delightfully readable syntax. This theme repeats itself throughout the language. more information at compile time is always going to result in safer and more predictable behavior. full disclosure: i'm an iOS dev working in objc and swift. i love both languages, and i think swift is the obvious path forward.
- saghm 8y ago
  > IMO Swift is a language written by a compiler guy to solve compiler problems. I'm not convinced; the examples you give require _more_ work for the compiler writer, not less. In general, a stronger type systems means that the compiler has to do more.
  - mpweiher 8y ago
    > require _more_ work for the compiler writer Exactly. In Objective-C, the compiler can't do much, which is kind of a bummer if you are a compiler guy. Chris is a compiler guy. Consider Swift a kind of public works program for your local compiler team.
  - jkulubya 8y ago
    I see it in the sense that if the target for both compilers is to produce a correct program, then that target is much easier to achieve with more information (and less assumptions) passed in the source code by the programmer (ie Swift).
- 8y ago
lxcid 8y ago
I love Swift but at 4.2, its still a distance from being useable for me. Swift is suppose to be modern, only to be burden by API compatibility work, which is non trivia. This significantly slow certain important developments like ABI Stability (5.0), Full Generic (5.0), Concurrency (Maybe 6.0)? A year since 4.0 release and in the coming few months, 4.2 will be release and not 5.0. This mean the timeline for 6.0 get push even further back. While Swift is modern in area like optionality, first class immutable struct and (my favourite feature) enum with associated values, it lack many other modern features we come to expect from modern language. e.g. callback are still the way for async path control (1 of the regret of Ryan Dahl in his JSConf EU talk https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA) 1.0 to 3.0 was spent getting the API right. This is a significant positive investment in the long run, but as someone who have to maintain codes, it was not pleasant at all and I still have code stuck in 1.0/2.0 eras. I have crashes with getting conditional conformance working with generic. Some wasn't crashing on 1.0 or 2.0 but crash on 3.0. Swift clearing is a WIP. --- At the same time, TypeScript happened. TypeScript turn JavaScript into optional typed language. I see JavaScript and Objective-C in similar light. Since Objective-C start getting some syntactic sugar (generic, nullability), I wonder what if they have taken the TypeScript approach instead. TypeScript have no choice but be pragmatic (probably after seeing how Dart was not adopted by the larger community for going the Swift way). Apple basically act like a benevolent dictator, whatever direction they take is more or less the future, we have to figure out how to work around the new "world" order, which get updated every year at June. The best iOS/Mac developer thrive in this environment and get handsomely rewarded (App Store ranking, recognition from Apple), I tried and failed miserably.
khitchdee 8y ago
Call me a purist, but I find no reason to have gone beyond C Not C++, not ObjectiveC, nor anything else that followed I find C++ and ObjectiveC add a lot of complexity and the benefits of adding this complexity are very limited I think it would be better to stick with C and pursue other ways to improve developer tools
- sjwright 8y ago
  You’re not a purist, because there’s nothing inherently pure about C — it’s just another language.
  - khitchdee 8y ago
    Well there is. It's the first 'high level' language that replaced assembly programming. All the other languages have added even more high level features, yet none of them have made its existence obsolete. The basic compier translates from C, most other languages add a translational front end to a C compiler.
    - pjmlp 8y ago
      That is an urban myth from C fan club. There were quite a few system languages that replaced Assembly, some of them even 10 years before C was invented. https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/PL/8 https://en.wikipedia.org/wiki/PL/8 https://en.wikipedia.org/wiki/IBM_PL/S https://en.wikipedia.org/wiki/IBM_PL/S
      - khitchdee 8y ago
        Sorry, I meant in the microprocessor era when programming became mainstream and stepped out of academia. Before that, there were so few programmers that languages didn't need to develop.
        pjmlp 8y ago
nextstep 8y ago
This post is lacking in details. What does this mean? >> “It wants to be strongly typed, but at the same time so convenient in type inference, that it falls over its own feet while trying to grasp simple expressions, and they become too complex to manage. By design.” What is an example of an expression that is tripping over its own feet?
- mpweiher 8y ago
  This is one example: time swiftc too-complex.swift too-complex.swift:1:49: error: expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ real 1m20.639s user 1m12.459s sys 0m5.249s cat too-complex.swift let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7]
jordansmithnz 8y ago
As someone with a significant amount of experience in both ObjC and Swift (4+ full-time years in each), I don't agree with this article. Yes, Swift isn't perfect, it has its flaws. Totally agree there. It's not perfectly integrated with Cocoa either, as the author mentions. However, to say that Swift is a regression over Objective C seems very short sighted to me. Can you imagine if Apple continued with Objective-C? There would be no way to reverse decade old decisions that simply aren't the right decision anymore. Every new feature would need to be built on top of code from 1984. Swift was very future focused from the get go, and is a bid to ensure that developing for Apple devices in 2025 is not an archaic mess. Like anything new, it's not perfect at first. That is the world we live in now. However, Swift is getting incrementally better at a very good pace. There are some reasons left to prefer Objective-C right now, but I'm sure that in a few years these reasons will be far fewer. My own opinion is that I'm much more productive writing Swift, after spending a similar amount of time with each language. If you think the same is true of Objective-C, then that's great - there are certainly still some upsides to developing with Objective-C. However, to say that Swift is a mistake is something that I can't reason with, since it's one of Apple's most forward thinking decisions to date.
- dreamcompiler 8y ago
  > Every new feature would need to be built on top of code from 1984. Um, no. Macs were programmed in Pascal in 1984.
  - dwaite 8y ago
    So then 1985 (founding of NeXT) rather than 1984 (creation of Objective-C?)
- AnthonyMouse 8y ago
  > There would be no way to reverse decade old decisions that simply aren't the right decision anymore. Every new feature would need to be built on top of code from 1984. Of all the reasons to prefer a new language, this is the worst one from a platform perspective. C and POSIX allowed Unix to conquer the world. They allow code written since the 1980s to run with minimal modifications even on modern systems. The other major operating system family -- Windows -- is also strongly associated with backward compatibility. Everybody always wants to throw away the legacy code, because maintaining it is expensive. But throwing it all away and starting over from scratch can be more expensive. Especially when you're dealing with millions of lines of third party code. Which is why the only platforms that are still popular after 30+ years are the ones that didn't force everybody to do that.
bla2 8y ago
There have always been heated arguments about which language is better, but not many languages get as many "I don't like it" blog posts as Swift (maybe Go). It's probably just because people are usually free to choose a language, but are getting their arm twisted to use Swift on iOS. That's fine for people who like Swift, but leaves no option but complain to the others.
- gurkendoktor 8y ago
  I also think it's a question of community management. Before Swift was introduced, the iOS dev ecosystem was naturally composed of people who were comfortable enough with Objective-C. Then Apple suddenly released a language that reversed almost every single design choice. Of course that was going to tear the community apart.

139 points by mgrayson 8y ago

> It seems to have been driven by the needs of the compiler and the gaps that needed to be filled for the static analyzer. Those seem to have been super-charged instead of catering to app developer's actual needs: efficient, hassle free, productive (iOS) App development. This. Even then Swift (the last I really looked like v2) was full of special one offs and smacked of design by committee. It would’ve been much more interesting if they’d worked on making an updated Objective C language. Maybe even break C superset constraint and add in some new syntax. It’s even more sad that ObjC message passing can support distributed systems. Probably time to move back to Linux. Too bad GNUStep never took off. Or Etoile (?).

dwaite 8y ago
Swift has changed a lot since v2, which was before it was open sourced and honestly before they had sufficient tool quality for medium and large projects.
saagarjha 8y ago
> This. Even then Swift (the last I really looked like v2) was full of special one offs and smacked of design by committee. How so?
- elcritch 8y ago
  Here's one link [1]. It's dated and so hopefully many of these have been resolved. Swift doesn't solve any problems for me so haven't really looked at it again for a long while. Mainly it seemed that instead of supporting full functional concepts, they one-offed feature that _looked_ like it was functional but weren't. Unfortunately I can't find the original article that reviewed the Swift type system. 1: https://www.quora.com/Which-features-overcomplicate-Swift-What-should-be-removed/answer/Rob-Rix https://www.quora.com/Which-features-overcomplicate-Swift-Wh...
  - saagarjha 8y ago
    A lot of those are either fixed, or being actively worked on.
pjmlp 8y ago
Pity that KDE is the only environment with something that approaches the Framework stacks of other desktop environments.

ardit33 8y ago

I agree with the author. "So now contrast that to Swift. First of all: Which question did it desire to answer? Think about it. There is no one clean answer." I feel that Swift is more just like a language designed to be a syntax swap of objective-c, making few things better, yet some other ones worse. Sure, it might be more welcoming to people used to java/javascript type of language syntax, but overall I think it is two step backwards on language design and functionality. To folks that are proficient with Objective-C, 1) How do you like working in Swift? 2) Are you more productive (for medium or large projects)? 3) Do you enjoy it more? In my part (if you are already very proficient with Objective-C), those answers are Nos. If you are new to iOS though, Swift is easier to get started. https://www.hackingwithswift.com/articles/27/why-many-developers-still-prefer-objective-c-to-swift https://www.hackingwithswift.com/articles/27/why-many-develo...

seandougall 8y ago
1) I've been doing Cocoa development for 13 years, and I absolutely love Swift. I've switched to it for all my own projects (at least the ones where I would previously have used Objective-C), and I'm never looking back. 2) For medium projects: absolutely. For large projects: I haven't had the pleasure yet, but the truth is that Swift encourages a much better approach to modularity, and if you're working in a large project as a monolith, you're probably doing something wrong. 3) Hands down, yes.
arcticbull 8y ago
I started developing in Objective-C back in the early 2000s on macOS (as a kid), worked at a big company on some macOS software, then worked on a million-line iOS Objective-C project at another big company for many years. After I left, I picked up Swift. I use it for all of my personal iOS projects. I don't disagree that there are flaws in the language, but they definitely aren't the ones the author pointed out. > Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature. I can't express how happy I am that an object is exactly what it tells me it is at compile time. The number of nuanced bugs that have bit me over the years, my lord. Let alone explaining this stuff to a new coworker? Dynamic dispatch / message passing / introspection are huge bug sources. If you can't rely on the compiler to tell you what something is, what can you rely on?! This alone dropped bugs an order of magnitude. > Define the convenience and elegance of nil-message passing only as a source of problems. Nil messaging is nothing but a source of problems. Can confirm. > Classify the implicit optionality of objects purely as a source of bugs. Implicit optionality was a massive design failure in C. Those days are behind us, it's time to move on. (1) I love working in Swift. It opens up all sorts of great design patterns -- lightweight view model structs, enums with associated values, easy to manage protocols. Readability is dramatically better. No more copy-paste between header and source. No more dealing with unintelligible types, first-class generics, etc. (2) Productivity boosts come from less boilerplate, less repetition, less typing, better design patterns being within reach. Static typing eliminates many classes of common bugs. No automatic nils is huge. I can't remember the last time my app crashed in something other than an Objective-C component or framework. (3) Yes, I do.

pkulak 8y ago

I think the problem it solves is developer PR with Objective C, which looks like absolute hell the first time you see it. Swift looks like a sleek scripting language.

noecrnt34mw 8y ago
I never understood this point of view. The first time I saw it, I was like, "Brackets. That's slightly different than I'm used to. They look like arrays or something. Oh well. It seems to work." And from then on it was a non-issue. Why do developers get so hung up on this?
- ChrisLTD 8y ago
  All the extra symbols did make ObjC more laborious to read and write. ¯\_(ツ)_/¯
  - Apocryphon 8y ago
    Objective-C [] over the :: and <> overload of C++, imo
    - pjmlp 8y ago
      I prefer the :: and <> overload of C++, than having to type @ everywhere.
- pkulak 8y ago
  I'd think most people would agree that infix notation is far easier to read and write than the Polish-like bracket notation.

majewsky 8y ago

> Swift code might end up being more correct in the end. It also might alert you to edge cases early on. However, the flip side is it inhibits your creativity while writing. When starting out to program, the way I enjoy working, I don't yet know how the API is best expressed. So I try out different ways to express it until I find a sweet spot. Then I go back and unify accordingly. > Swift actively distracts me in that endeavor by making me answer questions I really don't want to answer right now. Yes, stuff might be less correct in the meantime, but heck that is what I want during the design phase. Find my concept, sweet spot, iterate, pivot quickly. I have much of the same feelings with Rust.

deltron3030 8y ago
It might make sense to differentiate between prototyping and implementation languages. As a design first company, they don't prototype in code, they use code to implement prototypes. With Swift they're just serving their own methodology. This also fits into their "we don't need to collect data" mindset, they seem to iterate on assumptions, not direct feedback from customers. They create many prototypes and then implement the most viable one, and and this point they know exactly what they need.
- majewsky 8y ago
  That's a fine approach when you prototype a UI or a process, but it doesn't help if, f.i., you want to try out a specific Rust library.
- archagon 8y ago
  Would be neat to have a language with dynamic features for prototyping, but that become warnings or errors when compiling for release.

mmjaa 8y ago

I agree with the author on all points, except one: there isn't any reason not to just use Lua for everything. Yes, thats right. Lua for everything. Lua on iOS, Lua on MacOS, Lua on Linux. Lua on Windows. I absolutely love the freedom, flexibility and downright sexiness of using one language on all of the platforms. Its a beautiful, difficult, lonely place to be - but if you haven't tried it, you can't really knock it.

lifeisstillgood 8y ago
I am unfamiliar with mobile coding but I presume there are really good reasons to use the "blessed" language on ios / android - I would assume any scripting interfaces leave many useful (security) areas unavailable? Could you access the secure enclave for example in python or lua?
- mmjaa 8y ago
  Yes, you sure can. Anything you can do in Objective-C or Swift, you can do in Lua.
vbezhenar 8y ago
Custom JIT is forbidden on iOS, how are you going to write performant code? I could see only JavaScript as a proper alternative.

lifeisstillgood 8y ago

> Swift actively distracts me in that endeavor by making me answer questions I really don't want to answer right now. Yes, stuff might be less correct in the meantime, but heck that is what I want during the design phase. Find my concept, sweet spot, iterate, pivot quickly. This is also what annoys me about TDD - writing code is a process of refinement - if I know exactly what the API I am going to program against looks like, if I know the API I will offer and I know the internals of my code are before I write code then hell, I have done it before. Often times coding is exploring.

vbezhenar 8y ago
Eclipse Java compiler had a neat feature. It could compile wrong Java code into a working bytecode. Wrong instructions were replaced by throwing exceptions. So you could run incorrect program (it wasn't 100% bullet proof, of course, curly brace mismatch could render your program absolutely useless, but it worked in majority of cases). This greatly helps with development. I can stop my unfinished work in one place and test another, for example.
duckfruit 8y ago
Idris has a really neat feature called 'Holes' that does exactly this. I wish it could be implemented in every language on earth.

bsaul 8y ago

As a mobile & fullstack developper, my road also takes me to different languages but for very different reason. To me swift is at its core the best language by far. I love the way it lets me model pretty much every problem using combination of enum and struct, while keeping everything value-based and type safe. If you add null safety, there is no other (mainstream) language that checks all those marks. But the OP is right in that Swift aims at being a silver bullet, yet the pace at which it evolves compared to that goal is absolutely scary. Concurrency hasn't moved at all, and in the meantime server side performance is a total disaster (https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=fortune https://www.techempower.com/benchmarks/#section=data-r16&hw=...). There is also nothing for cross-platform development (real cross-platform, not just iOS and macOS). So, personally, my next experiment is going to be full stack dart.

seandougall 8y ago
That benchmark seems to list only Kitura. I wonder what it would look like with Perfect, Vapor, or Zewo. > Concurrency hasn't moved at all Yeah, it hasn't moved because GCD is already pretty mature, and they don't seem to have made any effort at other concurrency paradigms. I'd love to see how something more like CSP would work (Zewo has an implementation, but I haven't had a chance to work with it yet). > There is also nothing for cross-platform development (real cross-platform, not just iOS and macOS). Not yet; it doesn't quite seem like it's ready to be a practical goal. I'm curious to see if that changes when they manage ABI stability.
- bsaul 8y ago
  GCD is a library, not a language construct. As such it is extremely raw, and i've got a strong suspicion that the fact that it wasn't built for server-side style concurrency is one of the reason kitura is dead slow in the benchmarks. Those kind benchmarks usually spawn thousands of simultaneous connexions, which is very far from what an app generally requires (but i could be wrong). It also doesn't provide more parallelism regarding i/o than os-based threading. go has light threads which makes context switching fast, and node has async i/o all over the place. Maybe Swift NIO would make a difference, but it would only make swift catch up to what the first version of node.js provided. My point was that this manifesto https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9... has been written 1 year ago and nothing has been implemented or announced at wwdc (but maybe i missed a talk...)

chadcmulligan 8y ago

Its interesting how languages divide opinion. For me I think Swift is the best language around. One of the issues not addressed in the article (I believe) is performance, Swift is faster than Objective C because of the static type checking, which is a good thing. It has the advantages of C# as a language but no garbage collection, granted the reference counting in Swift can be problematic, but it seems to be improving with each release. The functional programming aspect of swift I find useful. There are a number of features in swift that decreases the amount of code - e.g. if let/guard. The use of optional types increases program safety. The fact that you can use classes declared elsewhere without any consideration of dependency I find very powerful, and of course with great power comes great responsibility. The power of swift collections is fantastic, and the syntax compared to Objective C is so succinct. Many more...

sheeshkebab 8y ago
Faster than ObjC? Unless your objc code is written using nothing but id and reflection, I’m not sure how can this be the case...
- saagarjha 8y ago
  > Unless your objc code is written using nothing but id and reflection That's how all Objective-C code is written–every method call goes through objc_msgSend.
  - sitharus 8y ago
    To be fair to objc_msgSend it's orders of magnitude faster than most reflection APIs. https://www.mikeash.com/pyblog/performance-comparisons-of-common-operations.html https://www.mikeash.com/pyblog/performance-comparisons-of-co... has some benchmarks, it's a bit old but I don't think objc_msgSend would get slower.
    - saagarjha 8y ago
      Yup, I'm not saying objc_msgSend is slow: it's just that it's not faster than a direct call, and I believe about on-par with a virtual function call.

protomyth 8y ago

I find myself in the same boat. I've programmed in Objective-C since 1995 on NeXTSTEP. I love Objective-C, but realize it has quite a lot of warts. My problem with Swift is my feeling that the people who developed it don't like Objective-C. It really feels like the Java direction Apple tried to take in the late 1990s. You can argue Nil messaging but its part of the landscape. Plus, I really find weird way they adapted message passing to the C++/Javascript like syntax. A simple obj.(selector: value selector2:value) would have made it much easier to go back and forth. This is mismatch affects things. Never mind the added punctuation that need not be there. I should be much more productive, but I'm not and that sucks.

fpoling 8y ago

A friend of mine have been working with porting to iPhone some Android and web apps. I recently asked his opinion of Swift. He said he had no idea as the essential libraries the apps use are in C or Objective-C, so there were no choice but to use Objective-C for the apps. This was surprising, as I thought that calling Objective-C from Swift should be transparent. But it turned out it was not as many small but important details make the whole thing rather messy. So I also wandered what exactly Apple wanted to get with Swift if it lacks even in Objective-C interoperability.

seandougall 8y ago
I'm not sure where your friend was getting that information, or what small details he was referring to. Calling Objective-C from within Swift is remarkably transparent -- where you might have called `[foo bar:baz];`, you call `foo.bar(baz)`. In some cases, wordy Objective-C names will get mapped to Swift's tidier conventions, but the public APIs are all documented in both languages, and Xcode's auto-complete is pretty good at helping you figure it out.
- fpoling 8y ago
  The issue was with exceptions.
dwaite 8y ago
Swift was designed to have very good Objective-C and C compatibility, using the clang compiler to understand headers and generate any Swift binding/bridge at compile time. It will punt on trying to support some things, such as inline functions which are declared as C macros, but generally will try to expose everything. Typically a maintained Objective-C library will evaluate their ability to be used from Swift, and use attributes/macros where necessary to tweak the code import to generate a higher quality Swift interface. Examples would be declaring that a method never returns a nil value, or creating a clearer function name, or switching to the newer Objective-C enum/set styles to have the enumerations generated as Swift types rather than having their API take a raw integer constant or string. AFAIK, all of apple's frameworks are C or Objective C interfaces, and the swift interface is nearly all generated based on the code and public annotations.

seandougall 8y ago

These complaints largely seem to come down to Swift not really being what the author expected it to be. His list of speculations as to Apple's motivations, in particular: > It should scale from App/UI language down to system language. Did I miss something where Apple or the Swift team said anything about writing a kernel in Swift? They wanted to make it fast enough for performance-critical situations, yes, but there are plenty of those in userspace -- and I haven't found Obj-C's inability to perform in those situations to be an asset. > It should inter-op with existing Foundation and Cocoa, but still bring its own wide reaching standard library, adding a lot of duplication. This is missing the forest for the trees. Bringing Swift-native Foundation APIs into the standard library means they're available on non-Mac platforms, which is huge. I'm also not sure what alternative would be preferable -- should it _not_ interop with Foundation/Cocoa, and totally fragment the ecosystem? Or should _not_ reimplement them with native calls, so that it inherits the performance penalty of objc_msgSend? > It is functional, object-oriented and protocol oriented all at the same time. Apple describes Swift as protocol-oriented. It's flexible enough to support other paradigms, but I don't see how that's a liability, and I haven't seen Apple claim "Swift is an FP language". > It wants to be strongly typed, but at the same time so convenient in type inference, that it falls over its own feet while trying to grasp simple expressions, and they become too complex to manage. By design. [citation needed] This complaint is so vague as to be impossible to address, except to say that I haven't managed to come across a case of it yet. An example would really help make the case. > It is compiled and static, but emphasized the REPL and playground face that makes it want to look like a great scripting solution. Which it isn't. Again, I haven't heard any claim that "Swift is a scripting language". Sure, it's not, but neither is Objective-C, so... I'm not really sure what the complaint is here? > It seems to have been driven by the needs of the compiler and the gaps that needed to be filled for the static analyzer. Those seem to have been super-charged instead of catering to app developer's actual needs: efficient, hassle free, productive (iOS) App development. This sounds like a complaint about strong typing and static dispatch in general. Yes, you have to code more carefully, but the flipside is that a huge number of errors that crop up at runtime in Objective-C become compile-time errors in Swift. I'd much rather bang my head against the compiler for a while before I ship than have reams of undebuggable crash logs pour in. > It is meant offer progressive disclosure and be simple, to be used in playgrounds and learning. At the same time learning and reading through the Swift book and standard library is more akin to mastering C++. It is quite unforgiving, harsh, and complex. That's true, but that's also kind of a big part of why playgrounds exist. So again, what's the complaint? Is the fact that playgrounds make the language more accessible a problem somehow? Also, the only way I can view Objective-C as "simple" is by ignoring the C underpinnings and looking only at the relatively thin layer of classes and message passing on top. For somebody coming to coding with fresh eyes, both Swift and Objective-C are going to have a learning curve; the difference is that with Swift you don't have to pick up K&R first.

saagarjha 8y ago

The author seems to not be up-to-date with modern Swift: > Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature. There was a proposal recently to make this first-class, and not just limited to Objective-C. > Classify the implicit optionality of objects purely as a source of bugs. Not purely, but often optionality is a source of bugs. > At the same time it failed to attack, solve and support some of the most prominent current and future computing problems, which in my book all would be more important than most of the areas it tries to be good in: > concurrency Concurrency is being hashed out, and will probably be available in a later version of Swift. > overall API interaction complexity The Swift API is refreshingly small. Are you talking about Foundation? > debug-ability What's wrong with the debug-ability, especially with solutions like playgrounds? > actual App and UI development …this is literally the main use of Swift. > developer productivity Personally, I feel it's much improved. > 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. This is almost a non-issue these days, unless you're interacting with C APIs. > Just imagine a world where Objective‑C would have gotten the same amount of drive and attention Swift got from Apple? The ten years before Swift existed?

blattimwind 8y ago
> There was a proposal recently > Concurrency is being hashed out, and will probably be available in a later version of Swift. TFA: > It keeps defering the big wins to the future
EpicEng 8y ago
>The author seems to not be up-to-date with modern Swift: > Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature. There was a proposal recently to make this first-class, and not just limited to Objective-C. > concurrency >Concurrency is being hashed out, and will probably be available in a later version of Swift Sounds to me like "modern swift" doesn't actually have any if these things. Did you mean to say that the author wasn't familiar with some future version of swift that doesn't yet exist?

pjmlp 8y ago

> However, the flip side is it inhibits your creativity while writing. The old adage of C devs against us on the strong type side of the fence of Algol family. We all know how the freedom for creativity end up. https://www.cvedetails.com/vulnerability-list/opmemc-1/memory-corruption.html https://www.cvedetails.com/vulnerability-list/opmemc-1/memor...

gurkendoktor 8y ago
All we are doing with Objective-C is gluing together a few JSON APIs and buttons. The assumption that a single language needs to be fit for both security-critical low-level code and high-level UI programming is exactly the problem with Swift.
- pjmlp 8y ago
  There is no problem with Swift, it is just another language following the good principles of safe systems languages from 60 and 70's, going on outside AT&T walls. Kudos to Apple.
erichocean 8y ago
> We all know how the freedom for creativity end up. You mean, it completely dominates the programming world? C is a massive success story, no other language even comes close.
- pjmlp 8y ago
  Things given for free are always a success story. Had AT&T been allowed to charge for UNIX since the beginning and not 10 years later after being split by the government and C would have been a footnote on the history of systems programming languages. In a world where many don't want to pay for software, free trumps technical merits.
- valuearb 8y ago
  C is garbage, a loaded shotgun with no safety. I say this as someone who spent twenty years writing object c code. The only way we survived was to build safety into a massive set of core libraries and use them religiously.

Apocryphon 8y ago

Steven Sinofsky thread here: https://twitter.com/stevesi/status/1005848814048047105 https://twitter.com/stevesi/status/1005848814048047105 Some other good ones tracked by Michael Tsai: https://mjtsai.com/blog/2018/06/10/on-my-misalignment-with-apples-love-affair-with-swift/ https://mjtsai.com/blog/2018/06/10/on-my-misalignment-with-a...

pjmlp 8y ago
Given the way Steven Sinofsky team contributed to the political mess of Longhorn/Vista, followed by WinRT split and the mess it brought to Windows and .NET eco-system, he is probably not the best authority to pay attention about programming languages and eco-systems.

dwaite 8y ago

> So now contrast that to Swift. First of all: Which question did it desire to answer? From Swift.org: Swift makes it easy to write software that is incredibly fast and safe by design. Our goals for Swift are ambitious: we want to make programming simple things easy, and difficult things possible. > It should scale from App/UI language down to system language. I don't see how say Go can be a system language and Swift can't. Much of Apple's investment has been around making App and Framework development more productive on their platforms, but Swift is open and other companies like IBM have been focused on things like Web frameworks. >It should inter-op with existing Foundation and Cocoa, but still bring its own wide reaching standard library, adding a lot of duplication. I assume they mean the standard Swift package as the standard library, since they listed Foundation separate. Swift is tiny, basically holding core types like Int, String, Optional, and pointers, Collections (Dictionary, Set, and Array), ranges like 1..<10, and essential common protocols like Equatable and Hashable. It isn't until you get to foundation that you get things like I/O / networking or binary data types. > It is functional, object-oriented and protocol oriented all at the same time. Several of the languages listed in the article as being above as positive (like Ruby) are also multi-paradigm. Swift is hardly a functional language, it just has functional influences - like nearly all the languages listed. > It wants to be strongly typed, but at the same time so convenient in type inference, that it falls over its own feet while trying to grasp simple expressions, and they become too complex to manage. By design. Since there wasn't an example given, all I can really say is there's nothing that requires you to use type inference. My experience from multiple languages is that usually such an expression is wrong, and the compiler cannot figure out any suggestions on how to fix it because a broken expression doesn't give any type inference hints. A dynamic language would just let it crash and burn at runtime, which (if you have a test suite capturing the issue) is such a different process for debugging from fixing type inference at compile-time that they are hard to compare. > It is compiled and static, but emphasized the REPL and playground face that makes it want to look like a great scripting solution. Which it isn't. REPL and Playgrounds are both for experimentation, not necessarily for scripting. You can do command-line swift scripts, but generally the compiler makes them a bit heavyweight for many things. > It seems to have been driven by the needs of the compiler and the gaps that needed to be filled for the static analyzer. Those seem to have been super-charged instead of catering to app developer's actual needs: efficient, hassle free, productive (iOS) App development. Can't say much here vs having a computer analyze your code is meant to be a boon, not a hinderance. My experience is that now when I write Java projects I wish I could get back the expressiveness, performance, and personal productivity I have writing Swift code. > It is meant offer progressive disclosure and be simple, to be used in playgrounds and learning. At the same time learning and reading through the Swift book and standard library is more akin to mastering C++. It is quite unforgiving, harsh, and complex. If nothing else, someone is underestimating the effort of mastering C++.

rockshassa 8y ago

IMO Swift is a language written by a compiler guy to solve compiler problems. the syntax is dense because it forces you to make a lot of decisions that could otherwise go unmade in objc. If a variable is read-only, you're forced to think about that by deciding between let/var. contrast this with objc, where all vars are writable unless you do the extra work of adding the const keyword. objc makes us do more work to get the faster (and safer) behavior. Similar with Optionals, you're now forced to decide right away if a parameter can ever be nil, whereas with objc you didn't need to declare nullability. Again, it makes the safest and fastest choice easier to make, and allowing nullability is actually more work. Generally Swift forces you to pass as much information to the compiler as possible at compile time, and it does it with a delightfully readable syntax. This theme repeats itself throughout the language. more information at compile time is always going to result in safer and more predictable behavior. full disclosure: i'm an iOS dev working in objc and swift. i love both languages, and i think swift is the obvious path forward.

saghm 8y ago
> IMO Swift is a language written by a compiler guy to solve compiler problems. I'm not convinced; the examples you give require _more_ work for the compiler writer, not less. In general, a stronger type systems means that the compiler has to do more.
- mpweiher 8y ago
  > require _more_ work for the compiler writer Exactly. In Objective-C, the compiler can't do much, which is kind of a bummer if you are a compiler guy. Chris is a compiler guy. Consider Swift a kind of public works program for your local compiler team.
- jkulubya 8y ago
  I see it in the sense that if the target for both compilers is to produce a correct program, then that target is much easier to achieve with more information (and less assumptions) passed in the source code by the programmer (ie Swift).
8y ago

lxcid 8y ago

I love Swift but at 4.2, its still a distance from being useable for me. Swift is suppose to be modern, only to be burden by API compatibility work, which is non trivia. This significantly slow certain important developments like ABI Stability (5.0), Full Generic (5.0), Concurrency (Maybe 6.0)? A year since 4.0 release and in the coming few months, 4.2 will be release and not 5.0. This mean the timeline for 6.0 get push even further back. While Swift is modern in area like optionality, first class immutable struct and (my favourite feature) enum with associated values, it lack many other modern features we come to expect from modern language. e.g. callback are still the way for async path control (1 of the regret of Ryan Dahl in his JSConf EU talk https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA) 1.0 to 3.0 was spent getting the API right. This is a significant positive investment in the long run, but as someone who have to maintain codes, it was not pleasant at all and I still have code stuck in 1.0/2.0 eras. I have crashes with getting conditional conformance working with generic. Some wasn't crashing on 1.0 or 2.0 but crash on 3.0. Swift clearing is a WIP. --- At the same time, TypeScript happened. TypeScript turn JavaScript into optional typed language. I see JavaScript and Objective-C in similar light. Since Objective-C start getting some syntactic sugar (generic, nullability), I wonder what if they have taken the TypeScript approach instead. TypeScript have no choice but be pragmatic (probably after seeing how Dart was not adopted by the larger community for going the Swift way). Apple basically act like a benevolent dictator, whatever direction they take is more or less the future, we have to figure out how to work around the new "world" order, which get updated every year at June. The best iOS/Mac developer thrive in this environment and get handsomely rewarded (App Store ranking, recognition from Apple), I tried and failed miserably.

khitchdee 8y ago

Call me a purist, but I find no reason to have gone beyond C Not C++, not ObjectiveC, nor anything else that followed I find C++ and ObjectiveC add a lot of complexity and the benefits of adding this complexity are very limited I think it would be better to stick with C and pursue other ways to improve developer tools

sjwright 8y ago
You’re not a purist, because there’s nothing inherently pure about C — it’s just another language.
- khitchdee 8y ago
  Well there is. It's the first 'high level' language that replaced assembly programming. All the other languages have added even more high level features, yet none of them have made its existence obsolete. The basic compier translates from C, most other languages add a translational front end to a C compiler.
  - pjmlp 8y ago
    That is an urban myth from C fan club. There were quite a few system languages that replaced Assembly, some of them even 10 years before C was invented. https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/PL/8 https://en.wikipedia.org/wiki/PL/8 https://en.wikipedia.org/wiki/IBM_PL/S https://en.wikipedia.org/wiki/IBM_PL/S
    - khitchdee 8y ago
      Sorry, I meant in the microprocessor era when programming became mainstream and stepped out of academia. Before that, there were so few programmers that languages didn't need to develop.
      - pjmlp 8y ago

nextstep 8y ago

This post is lacking in details. What does this mean? >> “It wants to be strongly typed, but at the same time so convenient in type inference, that it falls over its own feet while trying to grasp simple expressions, and they become too complex to manage. By design.” What is an example of an expression that is tripping over its own feet?

mpweiher 8y ago
This is one example: time swiftc too-complex.swift too-complex.swift:1:49: error: expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ real 1m20.639s user 1m12.459s sys 0m5.249s cat too-complex.swift let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7]

jordansmithnz 8y ago

As someone with a significant amount of experience in both ObjC and Swift (4+ full-time years in each), I don't agree with this article. Yes, Swift isn't perfect, it has its flaws. Totally agree there. It's not perfectly integrated with Cocoa either, as the author mentions. However, to say that Swift is a regression over Objective C seems very short sighted to me. Can you imagine if Apple continued with Objective-C? There would be no way to reverse decade old decisions that simply aren't the right decision anymore. Every new feature would need to be built on top of code from 1984. Swift was very future focused from the get go, and is a bid to ensure that developing for Apple devices in 2025 is not an archaic mess. Like anything new, it's not perfect at first. That is the world we live in now. However, Swift is getting incrementally better at a very good pace. There are some reasons left to prefer Objective-C right now, but I'm sure that in a few years these reasons will be far fewer. My own opinion is that I'm much more productive writing Swift, after spending a similar amount of time with each language. If you think the same is true of Objective-C, then that's great - there are certainly still some upsides to developing with Objective-C. However, to say that Swift is a mistake is something that I can't reason with, since it's one of Apple's most forward thinking decisions to date.

dreamcompiler 8y ago
> Every new feature would need to be built on top of code from 1984. Um, no. Macs were programmed in Pascal in 1984.
- dwaite 8y ago
  So then 1985 (founding of NeXT) rather than 1984 (creation of Objective-C?)
AnthonyMouse 8y ago
> There would be no way to reverse decade old decisions that simply aren't the right decision anymore. Every new feature would need to be built on top of code from 1984. Of all the reasons to prefer a new language, this is the worst one from a platform perspective. C and POSIX allowed Unix to conquer the world. They allow code written since the 1980s to run with minimal modifications even on modern systems. The other major operating system family -- Windows -- is also strongly associated with backward compatibility. Everybody always wants to throw away the legacy code, because maintaining it is expensive. But throwing it all away and starting over from scratch can be more expensive. Especially when you're dealing with millions of lines of third party code. Which is why the only platforms that are still popular after 30+ years are the ones that didn't force everybody to do that.

bla2 8y ago

There have always been heated arguments about which language is better, but not many languages get as many "I don't like it" blog posts as Swift (maybe Go). It's probably just because people are usually free to choose a language, but are getting their arm twisted to use Swift on iOS. That's fine for people who like Swift, but leaves no option but complain to the others.

gurkendoktor 8y ago
I also think it's a question of community management. Before Swift was introduced, the iOS dev ecosystem was naturally composed of people who were comfortable enough with Objective-C. Then Apple suddenly released a language that reversed almost every single design choice. Of course that was going to tear the community apart.