Constancy in the Face of Evolution

Evolution Pitches
1

Overview
Swift should consider a tiered system of language features that are restricted at compile time, and organized by increasing complexity.

Background
Swift has a dynamic, engaged community that is rapidly evolving the language. This can be great for simplifying specific programming tasks, but unfortunately has the effect of introducing a serious complexity problem. Consider that the 3.1 language doc has 1100+ pages and even a pocket reference guide from a couple years ago has 220+ pages. The language is getting too difficult for the average person to understand and requires elaborate tooling (ie. Xcode) for even most experts to remain productive.

To be clear, I fully realize this is an issue for many rapidly evolving languages. C++ initially comes to mind, but you could say the same of Java, Python and others. However, addressing this issue in Swift could position it as a leader in engineering, not just language and allow developers like myself to be using it successfully for years to come.

For over thirty years, the one constant in my development background is C. While I frequently write in other languages, the beautiful simplicity of K&R C never ceases to amaze me. By comparison, that language reference (2nd ed) is 272 pages and much of the modern world is built on it.

Not every software problem requires every advance in language theory, and to present all of it as a singular concept does a disservice to many people who would benefit from it.

Consider kids learning programming today, who are hopefully the next generation of software developers. Where is their Commodore 64 BASIC or Logo? While Swift Playgrounds is a nice attempt to encourage them, if they look for even the shortest Swift book online or in a bookstore, they'll quickly be reading about class diagrams, closures, optional chaining and automatic reference counting. It is no wonder many of them would rather play video games than build them.

Pitch
This problem can be addressed through strict filtering of the solution space. Imagine a different world where just like D&D has a 'Starters Set', Swift has an Initiate Tier for its language that only includes the barest features necessary to write some functions and control flow. Maybe you can't even create classes with it, only use them. All of this is enforced as a strict compile time option, completely omitting any higher level tiers' features. As people get more experienced they can move to Journeyman, Expert or Master tiers when they gain confidence with the more advanced features in each.

With that kind of pacing, that same kid (or even an adult wanting to learn coding) could find an Initiate Tier Swift book with only 50 pages (like Lua's reference manual, btw) and immediately get involved and productive. More critically though, it would allow someone in a small IT department to script standardized solutions for twenty years without being gradually phased out of their job.

Swift has changed significantly in recent years for the better, but unfortunately treats all software as equally complex, when it clearly isn't. Now that its vision is starting to materialize, it would be great to give it a digestible organization.

2 Likes
2

+1 This is a brilliant idea now that Swift is well past settled on the basic syntax and contracts of the language.

Also, another giant +1 for the D&D reference. That's just all kinds of nerd cool.

3

There is strong resistance against language dialects, and imho the only reason strong enough to split Swift would be a low-level variant like Metal.
I agree that Swift is too complex, but adding language levels would only increase this problem.
Instead, I'd prefer to not add as many special cases and shortcuts as in the past, or even replace some of those with more universal features.

It's still possible to create hierarchical documentation without changing Swift itself, though.

5 Likes
4

Swift is designed with progressive disclosure in mind, which means you should only need more advanced features when you need to do more advanced things. If for some reason the learning material provided by others is somehow being forced to introduce people to topics at the wrong time then there might be a couple reasons for this. One, the language design isn't up to scratch in a certain area, in which case there's an open evolution forum available for people to come and discuss a solution to try and make it better. Or the other reason might be that the learning resource is not well put together or not targetted at beginners.

There's also the concern of added compiler complexity and language fragmentation, which these tiers will certainly add to Swift. Any changes to Swift that involve increasing both of these must have some seriously good justification IMO. Especially language fragmentation which Swift currently has none of (If you exclude different versions of itself).

3 Likes
5

There is strong resistance against language dialects, and imho the only reason strong enough to split Swift would be a low-level variant like Metal.

In my mind these aren't regional dialects, but all part of the same unified release. Each tier would include the last, so it is just a rigorous application of what could be an informal method. There's plenty of examples of when this can be useful, such as running C++ in an embedded or kernel space where exceptions or templates might not be appropriate.

6

There's also the concern of added compiler complexity and language fragmentation, which these tiers will certainly add to Swift.

I don't disagree with the complexity concern, however if you compare the features of Swift to the C compiler I mentioned, it is easily orders of magnitude more capable and was developed in four short years instead of forty. Adding a strict functional taxonomy could be an achievable goal, given how much it has already accomplished.