[valuearb]

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]

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.

[LeoNatan25]

Indeed, there is a debt to Go's simplicity:

https://dave.cheney.net/2017/06/15/simplicity-debt 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]

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]

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]

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.

[valuearb]

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]

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]

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.

[ScottBurson]

It's a quandary. Beginner-friendliness does make a language somewhat easier to learn -- someone just trying to wrap their heads around the very idea of a program as a sequence of operations isn't going to appreciate being told that an integer is fundamentally different from a numeric string for reasons they don't yet understand (just to take one example).

Yet once someone has learned a language, they tend to keep using it. Their very inexperience prevents them from understanding that they should switch to something more industrial-strength once they start to write something larger and more complex. Plus, they don't even know when they start to write a program how big it is likely to get.

I don't know what to do about this except to continue to bang on the point you're making.

[LeoNatan25]

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.

[kornish]

Agreed. Go works for Google's use case (hiring thousands of fresh grads with low average tenure - need to minimize ramp-up time) but most companies should hire to the language, not bring the language to the hires.

[LeoNatan25]

A good hire is a good hire in any language. Just focus on good hires.

[pjmlp]

In the old days we learned directly with a mix of BASIC and Z80 (or 6502) Assembly, at the age of 10.

I was already doing C++ for MS-DOS while at the technical school (15-18 years old) and learned OOP via Turbo Pascal 5.5 and 6.0 before getting into C++.

Just look at kids today doing C++ with Arduino at school with similar ages.

So I really fail to understand the whole pandering "fresh college grad" concept.

[LeoNatan25]

> fresh college grad

I think the point is to bring in as much cheap[er] labor as possible. I mean, obviously people have been managing to cope with complex languages in complex multi-hundred and multi-million lines of code for decades, but now, with the startup craze, there is a need for a vast amount of developer force, that may not be as capable as before. When people go into the business for money reasons alone, things get bleak. I think that concept is for these people. And I get it, money is important! But I think there should be at least some passion there there too, and that's not just for software development, but for most walks of life.

[gurkendoktor]

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.

[plorkyeran]

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.

[gurkendoktor]

I am a big fan of named arguments. But Swift has both argument labels and argument names, and I don't see the point, other than for ObjC compatibility. I find Kotlin's approach conceptually nicer, where parameter names and labels are the same thing.

To give an example (possibly a particularly bad one), UIView.bringSubview(toFront view: UIView) - I feel that the argument label has made it harder, not easier, to give this method a good name.

[protomyth]

> Swift's method declaration/call syntax that looks unlike anything else (except maybe Objective-C)?

Well, Smalltalk actually, and Swift did a poor job of keeping it. Why everything has to look like C or Pascal is a mystery.

Swift makes Objective-C method calls like C with extra punctuation and people add classes to JavaScript. I wish Swift had at least respected that if anything just to cut down on punctuation.

[rimliu]

Well, having 'class' method on struct or enum would look kind of weird, these are value objects, not classes.

[saghm]

So why not just static methods, then?

[salutis]

Static methods are final, class methods are not.

[saghm]

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".