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.
You're right, designing a language the fucks up based on different text editor default preferences makes the users that are complaining about that design decision wrong ...
Please explain the advantage of white space sensitivity without sounding like a moron, go:
The advantage of white space sensitivity is that it reduces the visual noise when producing and reading source code, and it helps build in a consistent look and feel for the language. For instance with F#, the designers are using white space sensitivity to remove a large amount of boiler plate syntax, which makes for a much more concise language. Conciseness is very important because you can fit complex data manipulations into small blocks of very readable code, which is the core of the design team's tenant of "Do more with less code".
If you want to avoid, indentation errors you use the begin ... end blocks, but for most functions and types they are quite unnecessary. If you want to compress multiple assignments on a single line, use the let ... in ... syntax. F# also makes \t illegal when white space sensitive code is in use. With proper language design, white space sensitivity is a productivity advantage, and it does not sacrifice program readability.
Does this mean that white space sensitivity is outright superior to visual token semantic block delimiters? No of course not, it does mean that there is a trade-off space for the feature within the language's design so some languages are designed better than others.
There is also a trade-off space for using text editors instead of IDEs for programming. Sure you can stick to your favorite text editor, but you lose a large amount of useful information and features that IDEs that understand your programming language will give you, and since text editors are text editors and not program editors, they are completely correct when they display whitespace in semantically incorrect representations of the programming language.
Some whitespace sensitive languages like Python have warts when you use a language unaware text editor because Python's design considerations did not standardize and enforce in the interpreter how to use whitespace from different text editors. However, if you are using a text editor for programming, you are in a sense "doing it wrong" for many programming languages. Maybe you are fine with your current language, but if you are going to try a different language you should use the appropriate tools for that language. Use the right tools for the job. You wouldn't try to cut a 2 by 4 plank with a jeweler's saw would you? If not, do not use a text editor that is Python agnostic to edit Python code. It is really that simple. If you are collaboratively creating Python programs with others, adopt PEP-8.