6 ms·

> My goal for Swift has always been and still is total world domination I hope that this is never happen. Swift is great, it's universal and it saves you a lot

> My goal for Swift has always been and still is total world domination I hope that this is never happen. Swift is great, it's universal and it saves you a lot of time during coding, BUT It also has very large syntax and high number of features - documentation is huge! The most of swift programmers probably don't know complete syntax and all features which is problem in a world where we code in teams and work with open source(both cases mean that you work with code you didn't write). We just need new simple way how billions of people can explain computers what to do and backwards understand what computer was told to do and I'm sure that it's not Swift, Java or C++.

valuearb 9y ago
That feature size is why Swift is so scalable. Writing useful programs is easy to do for beginners with a very limited subset of the language. But as you expand your knowledge Swift is rich with features that make complex apps much easier to write for professionals.
- kornish 9y ago
  I don't think the problem with a large syntax is for writing - it's for reading. What happens when those same beginners are thrust into a professional production codebase and struggle to figure out what's going on? It's interesting to note that Google has taken the deliberately opposite approach with Go: small syntax, learn 90% of the language's ins-and-outs in a few weeks, so that the average fresh college grad Googler (average tenure being less than 2 years, IIRC) spends as little time as possible ramping up and has relatively predictable output.
  - valuearb 9y ago
    There is some truth to what you are saying. I'm not a beginner so I probably can't appreciate how hard it is to learn new syntactical features. My experience is I've found it pretty easy to learn new ones from my peer's code, but I struggle with actually forcing myself to teach myself new and more complex language features when the existing ones work so well for me. I'd say Swift is probably harder to learn than it could be because of how much syntax for common features has changed over major releases.
    - LeoNatan25 9y ago
      I have to wonder if pandering to "fresh college grad" only is the way forward with new languages. We were once beginners - did you see challenges when you were studying the languages you are now fluent in? I have a feeling like the computer world is being torn between two extremes - either go all-out complex or "think of the children" simple approach. Not just in programming languages, but in software development in general. If forced to pick out of those two, my personal preference would be the complex, but I would like to see a middle ground of "moderate" technologies.
      - mikeash 9y ago
        I realize this is probably unpopular, but I personally think we shouldn't aim for beginner-friendliness in our production languages. If we can do it then fine, but it shouldn't come at the cost of anything else. People are only beginners for a (hopefully) short time, then they're not. Making things better for them in the post-beginner period is far more advantageous, since that's when the vast majority of productive work occurs. There is certainly a place for beginner-friendly languages. People need to learn to program at some point, and something which is aimed at helping them do that is really useful. But there's no reason that it should be the same language used by professionals to do real work. Imagine changing the design of a 747 to make it easier to fly for new pilots. We wouldn't dream of doing such a thing. The cockpit of a 747 is for experienced professionals. If you're learning to fly then you belong in the cockpit of something like a Cessna 152. Note that I'm not advocating for difficulty just for the sake of difficulty, and I don't want to keep people out. And if a language can accommodate beginners without making things worse for professionals then let's go for it. But it shouldn't be a major goal of most languages.
        LeoNatan25 9y ago
        The cynic in me sees these approaches as a corporate-friendly way to be able to hire more "juniors" to save money. Entire frameworks and languages seemingly exist to enable low barrier entry to junior developers without any effort of the corporate to invest in these junior developers. There needs to be a balance between the need for junior developers to be productive and restricting technology just so as many as possible junior developers can be productive at low cost for the corporate. With stuff like React Native and Electron, I feel the former takes the lead at the expense of technology. Agree that simplistic languages could work well in academia, as the first language that students see. I studied C as my first language, and I am not sure that is optimal. Nor do I think Java is that language, as many study that first, these days.
  - LeoNatan25 9y ago
    Indeed, there is a debt to Go's simplicity: https://dave.cheney.net/2017/06/15/simplicity-debt https://dave.cheney.net/2017/06/15/simplicity-debt https://dave.cheney.net/2017/06/18/simplicity-debt-redux https://dave.cheney.net/2017/06/18/simplicity-debt-redux And slowly, the language is expanding in very obvious conclusions. Personally, I think there needs to be a balance in a language, where it should not be too restrictive in its syntax, but on the other hand, it should not be overly complex and has too much syntax. I am on the fence with Swift, but it does seem to come on the complex side.
    - kornish 9y ago
      Don't get me wrong, Go's simplicity comes with considerable tradeoffs and I'm not sure I'd use it in most cases again (started a greenfield codebase with it 3 years ago which is now around 200kloc). Just pointing out that syntactic edge cases can make writing easy, but most of programming (beyond one-off scripts) isn't writing. See: Scala and C++. Companies using these languages in production frequently disallow entire subsets of syntax or language features because they're hard to maintain. Balance certainly is key.
      - LeoNatan25 9y ago
        As I said in another comment, there seems to be a battle between extremes. On one end, the "complex" C++, Scala and others. On the other, simplistic stuff, such as JavaScript, Go, etc. It's probably gross injustice to put Go and JS in the same category, so I apologize, but for this argument, let's over look it. I think Swift and Rust are a good middle ground here. With your large project, in hindsight would you prefer Go or C++? At least with C++, you can go as complex as you want, or stop and set some "rules" that should not be passed. But I err on the side of having the option rather than being restricted.
        kornish 9y ago
        I think I lean the same way as you: the option for complexity, and counting on static analysis/linters/discipline to bound that complexity. That said, for all its theoretical flaws, Go is certainly a productive language (and has grown a pretty handy ecosystem over the years). In the end, the project was deemed a success and choice of language probably played a minimal role compared to hiring good people and prioritizing the right features.
- gurkendoktor 9y ago
  Many features only exist because Swift needs to work inside an ecosystem built on Objective-C. Otherwise, would we really have both "static" and "class" methods? Or Swift's method declaration/call syntax that looks unlike anything else (except maybe Objective-C)? I love Objective-C, but I don't want to inherit its baggage (via Swift) when I write backend code.
  - rimliu 9y ago
    Well, having 'class' method on struct or enum would look kind of weird, these are value objects, not classes.
    - saghm 9y ago
      So why not just static methods, then?
      - salutis 9y ago
        Static methods are final, class methods are not.
        saghm 9y ago
        I was responding specifically to the argument that you can't have only class methods because not everything is a class, in which case you could just call them something else other than "class method".
  - plorkyeran 9y ago
    While Swift's use of argument labels would probably never have existed without the Objective-C legacy, they're pretty much the last thing I'd point to as "baggage". The Swift 1.x version of them was kinda weird, but now that the rough edges have been fixed I'd consider the optional named parameters one of the strengths of the languages. I really can't think of anything in Swift 4 that exists in the subset of the language supported on Linux which is there for obj-c reasons that I would consider an actual problem.
santaclaus 9y ago
> BUT It also has very large syntax and high number of features What realistic alternative playing in the same space doesn't have this problem?

valuearb 9y ago

That feature size is why Swift is so scalable. Writing useful programs is easy to do for beginners with a very limited subset of the language. But as you expand your knowledge Swift is rich with features that make complex apps much easier to write for professionals.

kornish 9y ago
I don't think the problem with a large syntax is for writing - it's for reading. What happens when those same beginners are thrust into a professional production codebase and struggle to figure out what's going on? It's interesting to note that Google has taken the deliberately opposite approach with Go: small syntax, learn 90% of the language's ins-and-outs in a few weeks, so that the average fresh college grad Googler (average tenure being less than 2 years, IIRC) spends as little time as possible ramping up and has relatively predictable output.
- valuearb 9y ago
  There is some truth to what you are saying. I'm not a beginner so I probably can't appreciate how hard it is to learn new syntactical features. My experience is I've found it pretty easy to learn new ones from my peer's code, but I struggle with actually forcing myself to teach myself new and more complex language features when the existing ones work so well for me. I'd say Swift is probably harder to learn than it could be because of how much syntax for common features has changed over major releases.
  - LeoNatan25 9y ago
    I have to wonder if pandering to "fresh college grad" only is the way forward with new languages. We were once beginners - did you see challenges when you were studying the languages you are now fluent in? I have a feeling like the computer world is being torn between two extremes - either go all-out complex or "think of the children" simple approach. Not just in programming languages, but in software development in general. If forced to pick out of those two, my personal preference would be the complex, but I would like to see a middle ground of "moderate" technologies.
    - mikeash 9y ago
      I realize this is probably unpopular, but I personally think we shouldn't aim for beginner-friendliness in our production languages. If we can do it then fine, but it shouldn't come at the cost of anything else. People are only beginners for a (hopefully) short time, then they're not. Making things better for them in the post-beginner period is far more advantageous, since that's when the vast majority of productive work occurs. There is certainly a place for beginner-friendly languages. People need to learn to program at some point, and something which is aimed at helping them do that is really useful. But there's no reason that it should be the same language used by professionals to do real work. Imagine changing the design of a 747 to make it easier to fly for new pilots. We wouldn't dream of doing such a thing. The cockpit of a 747 is for experienced professionals. If you're learning to fly then you belong in the cockpit of something like a Cessna 152. Note that I'm not advocating for difficulty just for the sake of difficulty, and I don't want to keep people out. And if a language can accommodate beginners without making things worse for professionals then let's go for it. But it shouldn't be a major goal of most languages.
      - LeoNatan25 9y ago
        The cynic in me sees these approaches as a corporate-friendly way to be able to hire more "juniors" to save money. Entire frameworks and languages seemingly exist to enable low barrier entry to junior developers without any effort of the corporate to invest in these junior developers. There needs to be a balance between the need for junior developers to be productive and restricting technology just so as many as possible junior developers can be productive at low cost for the corporate. With stuff like React Native and Electron, I feel the former takes the lead at the expense of technology. Agree that simplistic languages could work well in academia, as the first language that students see. I studied C as my first language, and I am not sure that is optimal. Nor do I think Java is that language, as many study that first, these days.
- LeoNatan25 9y ago
  Indeed, there is a debt to Go's simplicity: https://dave.cheney.net/2017/06/15/simplicity-debt https://dave.cheney.net/2017/06/15/simplicity-debt https://dave.cheney.net/2017/06/18/simplicity-debt-redux https://dave.cheney.net/2017/06/18/simplicity-debt-redux And slowly, the language is expanding in very obvious conclusions. Personally, I think there needs to be a balance in a language, where it should not be too restrictive in its syntax, but on the other hand, it should not be overly complex and has too much syntax. I am on the fence with Swift, but it does seem to come on the complex side.
  - kornish 9y ago
    Don't get me wrong, Go's simplicity comes with considerable tradeoffs and I'm not sure I'd use it in most cases again (started a greenfield codebase with it 3 years ago which is now around 200kloc). Just pointing out that syntactic edge cases can make writing easy, but most of programming (beyond one-off scripts) isn't writing. See: Scala and C++. Companies using these languages in production frequently disallow entire subsets of syntax or language features because they're hard to maintain. Balance certainly is key.
    - LeoNatan25 9y ago
      As I said in another comment, there seems to be a battle between extremes. On one end, the "complex" C++, Scala and others. On the other, simplistic stuff, such as JavaScript, Go, etc. It's probably gross injustice to put Go and JS in the same category, so I apologize, but for this argument, let's over look it. I think Swift and Rust are a good middle ground here. With your large project, in hindsight would you prefer Go or C++? At least with C++, you can go as complex as you want, or stop and set some "rules" that should not be passed. But I err on the side of having the option rather than being restricted.
      - kornish 9y ago
        I think I lean the same way as you: the option for complexity, and counting on static analysis/linters/discipline to bound that complexity. That said, for all its theoretical flaws, Go is certainly a productive language (and has grown a pretty handy ecosystem over the years). In the end, the project was deemed a success and choice of language probably played a minimal role compared to hiring good people and prioritizing the right features.
gurkendoktor 9y ago
Many features only exist because Swift needs to work inside an ecosystem built on Objective-C. Otherwise, would we really have both "static" and "class" methods? Or Swift's method declaration/call syntax that looks unlike anything else (except maybe Objective-C)? I love Objective-C, but I don't want to inherit its baggage (via Swift) when I write backend code.
- rimliu 9y ago
  Well, having 'class' method on struct or enum would look kind of weird, these are value objects, not classes.
  - saghm 9y ago
    So why not just static methods, then?
    - salutis 9y ago
      Static methods are final, class methods are not.
      - saghm 9y ago
        I was responding specifically to the argument that you can't have only class methods because not everything is a class, in which case you could just call them something else other than "class method".
- plorkyeran 9y ago
  While Swift's use of argument labels would probably never have existed without the Objective-C legacy, they're pretty much the last thing I'd point to as "baggage". The Swift 1.x version of them was kinda weird, but now that the rough edges have been fixed I'd consider the optional named parameters one of the strengths of the languages. I really can't think of anything in Swift 4 that exists in the subset of the language supported on Linux which is there for obj-c reasons that I would consider an actual problem.

santaclaus 9y ago

> BUT It also has very large syntax and high number of features What realistic alternative playing in the same space doesn't have this problem?