5 ms·

I'm not as in love with Swift as I was when it first came out after having used it for some small hobby projects. I agree that it doesn't solve any of the big

I'm not as in love with Swift as I was when it first came out after having used it for some small hobby projects. I agree that it doesn't solve any of the big problems in software development, and more just amalgamates ideas from multiple languages (bringing them into the Cocoa world which is a good thing) and makes things safer. However, a lot of Sinclair's arguments are misguided/misplaced/misdirected. Let me address each of his 4 core issues: Databases & Persistence – This is almost certainly a library issue rather than a language issue. As others have pointed out, third party libraries solve this problem quite well on other platforms and there's no reason they can't be solved just as well with Swift. In fact isn't that kind've what Realm is doing? Automated RESTful APIs - I don't think I even need to explain for the crowd here why this is a library issue and not a language issue. Triggers & Responses – Swift actually has some rudimentary support for this in the form of Property Observers (didSet, willSet). These aren't useful for all of the same scenarios as KVO, but they're a start and I see this as an area that is clearly getting renewed attention with Swift. UI Layout - How did he manage to criticize this issue so much and not mention Interface Builder? If you're primarily doing your layout in code, you're doing it wrong. I've been fighting AutoLayout a lot the last week, so I'm not in a mindset to give IB too much praise. AutoLayout in IB is still buggy and still has some ridiculous error messages, but I don't spend my days doing geometry calculations as he seems to imply. I'd like to see IB improvements, but again this is not a language issue. So, it sounds like Sinclair mostly wants better libraries and better tools. Don't we all?

rjsamson 12y ago
Agreed, DB & Persistence and automated restful APIs are library problems, and ones pretty well solved by some existing solutions. Realm is awesome, and solves both pretty well. Personally, I love Swift, and after having written a medium sized application in Swift over the course of about a month, I can say I saw significant productivity gains over objective-c.
chrisbuchholz 12y ago
I feel you misunderstood the article. To my understanding, his point is that we need database persistence, automated RESTful APIs, triggers and responses and better ways to do UI layout, but what we got was Swift which doesn't address any of these things. The things we actually need. So we end up with a new language which we have to spend time mastering, and when we are done doing that, we still need to fix those problems we had before we got Swift, so what is the point? Why do we need Swift? That's how I read the article anyways.
- deleted 12y ago
  [deleted]
- pohl 12y ago
  That makes it sound as if a modern language sans the baggage of C was not needed. It was.
  - mpweiher 12y ago
    Hmmm...to me it makes it sound like a modern language without the baggage of C was and is needed, but Swift is not that language.
    - pohl 12y ago
      [language] does not solve [problems not solved by languages]. Film at 11.
      - mpweiher 12y ago
        Welcome to Tautology Club! If Tautology Club is the sort of thing you like, you will like Tautology Club. Alternatively, you will find that you like Tautology Club if that is the sort of thing you like. In other news, you might have checked some of the other posts here that explain why some of these problems are, or at the very least can be language problems, before letting loose the snark. For example https://news.ycombinator.com/item?id=8377860 https://news.ycombinator.com/item?id=8377860
        pohl 12y ago
        "My smartphone didn't palliate my hemmoroids" is no tautology.
        mpweiher 12y ago
        But "[language does not solve] [problems not solved by languages]" is.
cwp 12y ago
Yes, but... Often better libraries and tools can only be built on a better language. That's easy to say and very, very difficult to pull off, but when it happens the result is like magic. I recently encountered this when I was getting into the nix package manager. At first I thought it was ridiculous that they had invented a whole new language just to describe packages. It was a lazy functional language at that, obviously an exercise in academic preening. Boy was I wrong. Because it's lazy you can have a program that describes a whole Linux distribution, and only run the parts that are necessary for the task at hand: installing nginx or whatever. Outside core they use all sorts of non-trendy languages, but the core is written in a new language with carefully-designed characteristics. The result is amazing, as much of an advance as going from manual to automatic memory management. It seems to me that the OP's complaint is that Swift wasn't designed to make better libraries and tools possible, but rather to work well with the ones we already have.
- mpweiher 12y ago
  >Often better libraries and tools can only be built on a better language. Precisely. For example, a lot of Cocoa these days relies on dictionaries and/or stringly-typed identifiers: KVC, KVO, Bindings, Archiving, CoreImage attributes, CoreData's interface to the database etc, etc. Autolayout also uses a separate string-based language. There are a lot of problems with this approach, not the least of which are performance, code bloat and lack of any kind of compile-time checking. Polymorphic Identifiers[1] in Objective-Smalltalk[2] are an attempt at addressing these issues (and others). The paper shows why you actually need a small amount of language support to successfully build libraries that address these issues. I wish I could complain about how Swift's approach to these issues is so much inferior to mine (grin), but there just isn't anything at all. If anything, support for solving these sorts of problems is thinner than in Objective-C. Yikes! Another issue is the large-scale structure of applications...their architecture: target/action, delegates, bindings (again), notifications, view-controller segues etc. are all architectural connectors, and a large part of what makes Cocoa so powerful. However, these types of connections (-> configurations) can only be described in ad-hoc ways in code, or in a different ad-hoc way in IB. Various inspectors of a GUI builder are not really the proper place to describe the overall architecture of your program. There have been many systems/languages for describing such high-level architectures, for example ArchJava or ACME. In Swift? Crickets. When direct language support for a feature is not present, dynamic messaging has been a great way of making library features available as if they were built-in language features. Swift makes this harder or downright impossible. > Swift wasn't designed to make better libraries and tools possible Yep. In fact, it's arguably a step back even compared to Objective-C. Which is sad. > but rather to work well with the ones we already have. Except that it doesn't really work all that well with existing ones either. Objective-C interop seems to clearly be marked "legacy", with the default apparently non-interoperability. [1] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media... [2] http://objective.st/ http://objective.st/
TheOtherHobbes 12y ago
>This is almost certainly a library issue rather than a language issue. Is Cocoa a language or a library? IMO the criticisms really apply to Cocoa, not Swift. Or rather - they're complaints about the fact that Swift could have been designed to simplify common Cocoa boilerplate, but instead it seems to be Yet Another Blub (c) 2014. What's going to have more of an influence on developer productivity - a novel type inference scheme, or an OS API that works so well you don't need to keep writing the same boilerplate over and over, or go looking for 3rd party libraries to fix its deficiencies?

rjsamson 12y ago

Agreed, DB & Persistence and automated restful APIs are library problems, and ones pretty well solved by some existing solutions. Realm is awesome, and solves both pretty well. Personally, I love Swift, and after having written a medium sized application in Swift over the course of about a month, I can say I saw significant productivity gains over objective-c.

chrisbuchholz 12y ago

I feel you misunderstood the article. To my understanding, his point is that we need database persistence, automated RESTful APIs, triggers and responses and better ways to do UI layout, but what we got was Swift which doesn't address any of these things. The things we actually need. So we end up with a new language which we have to spend time mastering, and when we are done doing that, we still need to fix those problems we had before we got Swift, so what is the point? Why do we need Swift? That's how I read the article anyways.

deleted 12y ago
[deleted]
pohl 12y ago
That makes it sound as if a modern language sans the baggage of C was not needed. It was.
- mpweiher 12y ago
  Hmmm...to me it makes it sound like a modern language without the baggage of C was and is needed, but Swift is not that language.
  - pohl 12y ago
    [language] does not solve [problems not solved by languages]. Film at 11.
    - mpweiher 12y ago
      Welcome to Tautology Club! If Tautology Club is the sort of thing you like, you will like Tautology Club. Alternatively, you will find that you like Tautology Club if that is the sort of thing you like. In other news, you might have checked some of the other posts here that explain why some of these problems are, or at the very least can be language problems, before letting loose the snark. For example https://news.ycombinator.com/item?id=8377860 https://news.ycombinator.com/item?id=8377860
      - pohl 12y ago
        "My smartphone didn't palliate my hemmoroids" is no tautology.
        mpweiher 12y ago
        But "[language does not solve] [problems not solved by languages]" is.

cwp 12y ago

Yes, but... Often better libraries and tools can only be built on a better language. That's easy to say and very, very difficult to pull off, but when it happens the result is like magic. I recently encountered this when I was getting into the nix package manager. At first I thought it was ridiculous that they had invented a whole new language just to describe packages. It was a lazy functional language at that, obviously an exercise in academic preening. Boy was I wrong. Because it's lazy you can have a program that describes a whole Linux distribution, and only run the parts that are necessary for the task at hand: installing nginx or whatever. Outside core they use all sorts of non-trendy languages, but the core is written in a new language with carefully-designed characteristics. The result is amazing, as much of an advance as going from manual to automatic memory management. It seems to me that the OP's complaint is that Swift wasn't designed to make better libraries and tools possible, but rather to work well with the ones we already have.

mpweiher 12y ago
>Often better libraries and tools can only be built on a better language. Precisely. For example, a lot of Cocoa these days relies on dictionaries and/or stringly-typed identifiers: KVC, KVO, Bindings, Archiving, CoreImage attributes, CoreData's interface to the database etc, etc. Autolayout also uses a separate string-based language. There are a lot of problems with this approach, not the least of which are performance, code bloat and lack of any kind of compile-time checking. Polymorphic Identifiers[1] in Objective-Smalltalk[2] are an attempt at addressing these issues (and others). The paper shows why you actually need a small amount of language support to successfully build libraries that address these issues. I wish I could complain about how Swift's approach to these issues is so much inferior to mine (grin), but there just isn't anything at all. If anything, support for solving these sorts of problems is thinner than in Objective-C. Yikes! Another issue is the large-scale structure of applications...their architecture: target/action, delegates, bindings (again), notifications, view-controller segues etc. are all architectural connectors, and a large part of what makes Cocoa so powerful. However, these types of connections (-> configurations) can only be described in ad-hoc ways in code, or in a different ad-hoc way in IB. Various inspectors of a GUI builder are not really the proper place to describe the overall architecture of your program. There have been many systems/languages for describing such high-level architectures, for example ArchJava or ACME. In Swift? Crickets. When direct language support for a feature is not present, dynamic messaging has been a great way of making library features available as if they were built-in language features. Swift makes this harder or downright impossible. > Swift wasn't designed to make better libraries and tools possible Yep. In fact, it's arguably a step back even compared to Objective-C. Which is sad. > but rather to work well with the ones we already have. Except that it doesn't really work all that well with existing ones either. Objective-C interop seems to clearly be marked "legacy", with the default apparently non-interoperability. [1] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media... [2] http://objective.st/ http://objective.st/

TheOtherHobbes 12y ago

>This is almost certainly a library issue rather than a language issue. Is Cocoa a language or a library? IMO the criticisms really apply to Cocoa, not Swift. Or rather - they're complaints about the fact that Swift could have been designed to simplify common Cocoa boilerplate, but instead it seems to be Yet Another Blub (c) 2014. What's going to have more of an influence on developer productivity - a novel type inference scheme, or an OS API that works so well you don't need to keep writing the same boilerplate over and over, or go looking for 3rd party libraries to fix its deficiencies?