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.
Object Pascal and C++ and C# and JavaScript to name a few. You can program for iOS using any language which provides you with a toolchain to target iOS.
For this reason, your editor should have a setting that visually displays tabs. Put the following line in your ~/.vimrc if you use that. It also shows trailing spaces.
set listchars=tab:.\ ,trail:-
Just posting to add this tip. I totally agree with you, that the above situation should be an error condition.
8 of 13 people found this answer helpful. Did you?
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.
Replace all punctuation in written English by varying white space demarcations. You know, like replace a comma by two spaces, a period by three, and exclamation point by four, etc. Would that improve the language, or make it painful to read, format, etc.
Or how about something a little more relevant. Math has all kinds of logical demarcations. How about just replacing the parentheses with white space? Does that make it concise and easier to read?
The number one source of errors I (and many others I have worked with) have come across in my years of dealing with Python have come from white space errors. Using white space as a significant demarcation instead of just a visual cue in a language (or just to make it pretty/readable) is beyond stupid, as literally every person and every editor have different preferences and ways of handling white space. Even changing fonts can screw it up.
I can cut and paste C, C++, Java, etc. code from anywhere to anywhere and have it be interpreted in exactly same way as it was intended. You CAN'T do this with Python because you have no idea what white space characters you're actually grabbing, nor do you know how your particular editor/OS/etc. will attempt to format it.
This should be obvious. Don't use an invisible and variable set of characters as logical delimiters.
~X~