Slashdot Mirror
The Swift Programming Language's Most Commonly Rejected Changes (github.com)
An anonymous reader writes: When Apple made its Swift programming language open source in early December, it opened the floodgates for suggestions and requests from developers. But the project's maintainers have their own ideas about how the language should evolve, so some suggestions are rejected. Now a list has been compiled of some commonly rejected proposals — it's an interesting window into the development of a language. Swift's developers don't want to replace Brace Syntax with Python-style indentation. They don't want to change boolean operators from && and || to 'and' and 'or'. They don't want to rewrite the Swift compiler in Swift. They don't want to change certain keywords like 'continue' from their C precedents. And they have no interest in removing semicolons.
Swift's developers don't want to replace Brace Syntax with Python-style indentation.
I am appalled that enough people like the idea of significant whitespace in Python to actually ask for it as a feature.
People want to change a language they know little/nothing about, to be similar to one they know very well. Who are these people that are too busy for semicolons, brackets, and the differences between "default:" and "case _:"? Take a lesson from the C# guys and do what's best for the entire community, not a bunch of neckbeards that are too good for a semicolon.
The people who have their own ideas about how it should evolved are called architects, and they have their own opinion so that the language has some sort of coherency and isn't a complete and utter mess, which is what results when you do design committee.
Nice inflammatory summary though, no bias.
Swift's developers don't want to replace Brace Syntax with Python-style indentation.
No shit, they aren't retarded. Have you people not learned how stupid that is yet, how many retarded bugs do you have to have from the wrong spacing before you get it through your heads that it was a stupid fucking idea?
They don't want to change boolean operators from && and || to 'and' and 'or'.
No shit, they aren't idiots.
They don't want to rewrite the Swift compiler in Swift.
No shit, they aren't retarded. Other than proving something, WHY WOULD YOU? NO ONE DOES THIS unless they are just trying to swing their dick around. You write your languages in C with ASM for the places it makes sense. Unless you just like to make yourself need two compilers, one to compile your language so you can build your compiler in your language. Again, retarded.
They don't want to change certain keywords like 'continue' from their C precedents.
No shit, they aren't idiots.
And they have no interest in removing semicolons.
No shit, they aren't idiots.
If you had half a clue, or simply had read the second sentence under most of those things I wouldn't be the one pointing out that you're not qualified to be talking about language enhancements. Hell, as stated, almost all of these things are changes for someones personal pet preference, not because its useful for anything.
Swift IS INTENTIONALLY C like, intentionally. ALL of those requests are utterly stupid when your talking about a language that is intentionally like C/C++. If you want python ... USE PYTHON.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Swift's developers don't want to replace Brace Syntax with Python-style indentation.
Good, it seems Swift's developers aren't idiots.
Better known as 318230.
[Rust] is the successor to Swift, and is an improvement in every way.
By definition, how can Rust be a successor to Swift, when Swift wasn't even announced until 2 years after Rust's first release?
I don't have a horse in this race, but statements like that one I quoted make it fairly evident that your comments carry a heavy slant. Moreover, given the pedigree of both Rust and Swift, it seems like a pretty bold claim to suggest that either one could be "an improvement in every way" over the other. That's made even more true by the fact that both are in active development with lots of changes happening and that both of them are borrowing the best ideas from the other.
Choose the language that suits your task and platform best, whether that's Rust, Swift, Go, C++, Python, ASM, or something else entirely. Don't lock yourself down to one view for how all programming is supposed to work, since that's a quick path to obsolescence.
Because a single grapheme cluster in Unicode does not fit into a single UTF-32 code unit. If you don't understand the importance of grapheme clusters, try searching this essay for the word "cluster".
To have the Character type represent a full grapheme cluster is... odd.
99% of apps do nothing more than concatenate strings before passing them to some other API. These apps do not need to care about encoding or higher concepts like grapheme clusters. Asking every app to care about them is a major violation of the 80/20 rule.
Indentation is how you communicate block structure to a human reader. You're going to indent your code anyway
No, I am not. That's why I have a computer, to do tedious things for me - like correctly indenting code... pretty much every function I write I can write loosely and then simply tell the editor to re-indent my code correctly.
And that is why Python and Fortran are really the only languages I dislike, because they are the only ones (that I have used anyway) where the code CANNOT BE FORMATTED, because you have to know what code does in order to format it. In Fortran a character being present at a certain indent level meant that line was really a comment - oops!
But in Python you are far worse off, because the wrong indent changes execution, changes what you meant the program to do. There's no way for a formatter to guess how the code SHOULD be structured, so it cannot be - ensuring a life of tedium and very probable mistakes for coders that follow after the first one.
Python is the Wolverine of coding languages, the ultimate loner language.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
That inability to choose how to sculpt the visual aspect of code in Python is a monstrous shortcoming
No, I think it's perfectly in-keeping with the rest of the zen of Python. Namely, there should be one (and preferably only one) obvious way to do something.
There's no bickering about bracing style, or special snowflake developers applying their own misguided style on everything. It discourages people from writing deeply nested, difficult-to-follow logic in favour of simple, flat code.
And when everybody sticks to the same conventions, it magically becomes a lot easier to read, understand, share, work on, learn from and contribute to everyone else's code.