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 write your languages in C with ASM...
I can easily remember when any language that couldn't compile its own compiler was considered a toy language. Clearly, times have changed, possibly for the better, possibly not.
Good, inexpensive web hosting
Indentation is how you communicate block structure to a human reader. You're going to indent your code anyway, and eliminating the extra delimiters prevents the structure humans see from getting out of sync with the structure the language implementation sees. There's a perennial C logic bug where you take an if statement with a one-line body and add a second line without adding braces to denote a block; that never happens in Python.
That said, I'm happy with either syntax.
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.
Unless you've used them for a while, you probably wouldn't know. But Optionals are the best idea to come along in some time. There have been things a bit like them, but not constantly used in languages - the great thing about Swift is support for anything being an optional.
Optionals eliminate so many classes of bugs, from ints where some magic value indicates "not set " to knowing if any variable has a "real" value. Just look at the Facebook 48 years of friendship bug, all because of a default of 0 which would have been .None in swift.
Databases can have null values after all, why shouldn't programing languages?
As for the "?", in swift it both makes it clear you are calling something that may not exist, while at the same time ACKNOWLEDGING that you know it may not exist. I really liked how in ObjC you could call null functions with no result, but there was a very real possibility that missing a call led to some other issue. As in so many other things, Swift lets you do something possibly dangerous if you like, but you have to agree you know what you are doing.
In real life 'myLabel?.text = "blah"' is so close to 'myLable.text = "blah"' it hardly matters, and the work you do to work with optionals is enough motivation to make other things non-optional when possible, a driver for good design because you have a clean data path in some portions of the code.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
In a language that uses braces (whether { ... } or begin ... end), a tool such as GNU indent restores readability to code whose leading space has been mangled by (say) your discussion software. This is not true of Python.
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~