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.
Don't like it? Fork it!
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
Having read only the summary, I'm still happy to have an opinion: Swift maintainers, so far you show excellent judgement!
The list and the explanations of why things were rejected really does a great job of illustrating why I like Swift - because the people behind the design have a great amount of practicality tempering the desire to include every modern language feature. It makes Swift nicer to work in, and in the long run will make it a LOT nicer to maintain.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
I downloaded the new open-source swift release and played with it a bit. Overall, I think the core language definition is one of the nicest I've seen, with a good balance of features, performance and usability. The learning curve seems reasonable as well. The standard libraries need a huge amount of work (they lean too heavily on "bridging" in verbose cruft from old NextStep Objective-C code or using glibc C APIs with a bunch of unsafe pointer casts). However, I'm sure all that can be fixed over time.
The one thing I find to be a glaring shortcoming in the core language is that strings are not indexable by integers. That really throws a wrench into the works, and burdens developers with a bunch of clumsy iterator handling for a large number of usage cases. I know they did that because they use UTF8 inside, but that's an implementation detail that should be hidden from the programmer. They already do magic copy-on-write for strings, so how hard could it be to switch to UTF32 under the hood if they detect the program is doing too many random accesses on a particular string?
Yeah, the only problem with that is at the first error in your code the French Compiler would crash, erase itself completely and then send an email about how victorious it was. THen you'd have to reinstall it (9 hour process) to find out what really happened. Oui! Oui!
What?.Were?.They?.Thinking
Also, in Python you indent the same way you should be doing anyway, just without the braces. Unless, of course, you're also doing indentation wrong.
Several channels through which people discuss program code strip leading and trailing whitespace on each line. This transforms all programs passed through them into programs that are "doing indentation wrong." Yes, in theory, these channels are defective. Yet people work around these defects using tools such as GNU indent because a defective channel gets work done better than no channel at all.
...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'.
etc.
Why did they think Swift would be any different?
They already do magic copy-on-write for strings, so how hard could it be to switch to UTF32 under the hood if they detect the program is doing too many random accesses on a particular string?
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".
[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.
You are kidding, but I remember actually programming in French.
Well, I don't really remember much. But in the 80ies, there was a French database for Mac called 4..? (I only remember there was a 4 in it's short name). The programming was in French. At the time, I was quite new to computers and very young, and there was no Internet.
I would hate a non-English programming language now, but at the time, I guess it was OK. Especially since the choice was that DB or Oracle.
I'm glad it let me bypass Oracle at the time. And I'm furious I have to deal a bit with Oracle now, for an application created before PostgreSQL was available. Installing and configuring Oracle on Debian now feels like going back to DOS 2.11... No apt-get install, no SQL history, horrible formatting of output, ... but I digress...
Yes, I'd (almost) rather program in French than deal with Oracle...
There was a lively comment thread on Swift.org which was shut down under the organization's code of conduct regarding a pull request replacing the Apache license with GPLv3. Hilarious.
But in the 80ies, there was a French database for Mac called 4..? (I only remember there was a 4 in it's short name).
That would be 4th Dimension.
https://en.wikipedia.org/wiki/...
My very first programming job (while still finishing uni part time) was with this.
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
I often write code where, on the fly, the indentation is not correct. Sometimes I decide I don't want some code in a block and move it elsewhere... sometimes I write a whole if statement on one line because it's cleaner.
In the end it doesn't matter because after I write a bit of code, I have the editor re-indent the code. Which I can do because white space does not control meaning of execution.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
They're sounding suspiciously like a software company that distributes a desktop OS and starts with the letter "M."
Please do not read this sig. Thank you.
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
That'd be 4th Dimension. It was great. I built many a complex website back in the 1990s using 4D.
I used to have a better sig than this, but I got tired of it
You know that's a troll, right? They post in like every programming language thread.
Virtually every developer in the past 40-years knows the C-syntax, deviating from it (e.g. python, typescript, etc) is what causes readability problems.
Uhhh, rust's way of dealing with pointers that might be null is optionals...
https://doc.rust-lang.org/std/...
No, no, no. We old fogies need that "default" keyword because it makes much more sense and easier to read than '-'.
If you really want to replace "default" with something that makes more sense for the modern age and is instantly understanding able, I have the correct solution:
case -\_(``/)_- -:
Apologies for the crude representation of this, Slashdot doesn't support Unicode well.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Or you can just write it properly in the first place
I did, the compiler thought so, and so did I.
There was absolutely nothing wrong with the code before and after indenting, just how it was sculpted on screen.
That inability to choose how to sculpt the visual aspect of code in Python is a monstrous shortcoming, which overshadows all of the other great things about Python.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Make it more like Java.
Make it less like Java.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
To have the Character type represent a full grapheme cluster is... odd.
I'll admit that human users' mental model does appear "odd" to someone who has been indoctrinated with the "character == code point" philosophy.
99% of apps do nothing more than concatenate strings before passing them to some other API.
And if you're just concatenating, you don't need to index.
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.
It sure does; that's why Python is the Soviet Block House of programming languages. You talk about "misguided style", but then take the worst possible style and say it's best that everyone has to use it regardless of actual clarity.
When you cannot make the code visually beautiful, I cannot see how you can possibly keep up architectural beauty also.
It's not about "special snowflakes", it's about inflexibility inherently leading to less clear code - both conceptually and visually.
That was borne out in the Python I had to go in and try to repair.
Swift is like a Python you can actually construct something robust in.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
To the contrary; it seems like the Swift team cares about all of the things you mentioned far more than the architecture astronauts that guide the design of just about any other language...
The Python guys are all up in arms because you can't get rid of a few curly braces, while ignoring that Swift lets you omit whole massive chunks of syntax when possible (like omitting return type when nil, or type information when it's possible to derive it, or easy closure passing into functions). Swift does a great job of letting you chose the level of syntax that provides the best comprehension for code you are writing.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It looks like most of the list is just an effort by people to make Swift look like whatever language they're using currently.
As queer as Tim Cook.
Why not go back to Hypertalk and HyperCard!
Ha ha
I'm assuming you're trolling, but HyperTalk was actually pretty awesome for its intended usage. AppleScript is still a great high-level language for describing what would otherwise be completely UI-driven macro integration. Most of the really painful re-engineering of code to deal with Apple Events was done back in the 90s, and Cocoa-only writers were able to leverage that going forward. That being said, it's not a general purpose language... it's a scripting language. HyperCard had some nifty UI built-ins, but it was still a scripting language.
Use the right tool for the right job. For sysadmins, someone who wants to write everything in Shell is probably as bad as the person who doesn't want anything in Shell. (cough*systemd*cough)
Hire a Linux system administrator, systems engineer,
The short answer is "it depends". Lex and YACC are not too bad for prototyping or internal tools, but I'd never ship a production compiler that used them. OK, maybe Lex, but definitely not YACC.
Lex and YACC are extremely C-specific. You have to write glue code if your compiler is written in something else such as C++, which it probably is if you're using LLVM. There are more modern YACC-alikes which overcome these problems, but still. Also, you have to jump through hoops if you want more than one lexer/parser linked into the binary. Many modern production compilers effectively have more than one "input language" (e.g. multiple revisions of a standard, C/C++/Obj-C/CPP), and there's just no nice way to do this in YACC.
But more importantly, YACC (and, indeed, pretty much any parser generator) tends to produce terrible syntax error messages. Diagnostics about errors in the program is, in a sense, the only part of the compiler's output that a programmer will read. Those syntax and type error messages are, in a deep sense, the most important part of the "user interface" of a compiler. If the error messages are less helpful than they could be, the compiler fails at ergonomics. Just look at all the people who complain about STL type errors.
Getting YACC to produce high-quality error messages, and convincing it to recover gracefully from a syntax error so that it can proceed, is more work than hand-writing a parser in the first place. You might as well just do that.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Typescript doesn't really deviate much from C/C++, does it?
this joke only works in the US. the rest of the world has history and geography of the world (!= USA) in school. also it helps when history books don't have chapters beginning with "on the 8th day, Abe Lincoln rode his dinosaur to Philadelphia".
Even for prototyping, I wouldn't use them. The separation of tokeniser and parser is an artificial distinction driven by slow computers with small amounts of RAM (as is the C preprocessor). You still need extremely efficient parsers for C-family languages, because #include means that the C compiler often sees several MBs of text. For more modern languages that encourage modularity, you'll only be parsing a small amount and a PEG-based parser will consume a tiny fraction of the total compilation time and be a lot easier to debug.
I am TheRaven on Soylent News
Replace Logical Operators (&&, ||, etc) with words like "and" and "or":
Bless your c-styled bitwise- and logical operators. For example, Pascal uses 'and' and 'or' as suggested. They happen to be bitwise and and or. For true logical operations you have to jump some hoops. So, before you know your code is full of `if ((b=0) and (c<>0))` etc. That's `if ((b==0) & (c!=0))` for the C readers.
You could solve it by indicating logical or bitwise operators. Band (bitwise and) and land (logical and)? bor and lor? That would surely make code more readable.
I love the c-style logical operators. It's obvious what they do. They are very readable as they are not letters, making it much easier to parse for the brains.
To end with a quote: `I would use pascal more frequent if only it had the syntax of C`
A glitch a day keeps the bugs away.
But there is no technical reason for those channels to be defective
But there is a non-technical reason: deterring page-widening posts that break the layout for other readers.
The complaints should be bug reports against the web sites and/or the forum software they use.
Unless the administrators of sites have a history of resolving these things WONTFIX, often citing past abuses by vandals. Incidentally, "past abuses" like that are why Slashdot supports very few code points outside ISO 8859-1: because people were using bidirectional control characters to spoof moderation and using other characters for obscene glyph art.
Swift shouldn't do away with braces nor should python add them. Once a language has made a choice, they need to stick with it. A language that would change such fundamentals once in productive use would be idiotic.
XML is like violence. If it doesn't solve the problem, use more.
Wow, that's some genius level comedy there, that is.
The parts that borrow from Javascript, but what they've added is usually weird.
Yes, it was "4th Dimension", aka 4D. I should have kept some floppies from then. Would have been fun to look at that code now...
Even for prototyping, I wouldn't use them.
I was thinking about prototyping a new language rather than prototyping a new compiler for an existing language. In that situation, YACC would give you a faster turn-around time during the exploratory phase.
The separation of tokeniser and parser is an artificial distinction driven by slow computers with small amounts of RAM (as is the C preprocessor).
The distinction is usually made by the language definition itself. Also, lexical analysers tend to be where you hide all of the ambiguity so that the syntax analyser doesn't have to deal with it (e.g. an "identifier" is anything which looks like an identifier but isn't a keyword). Having said that, I tend to agree with you; it's just as artificial as the two-level "recursive descent parser for statements, operator precedence parser for expressions" that they did back in the bad old days. Or van Wijngaarden grammars, which are probably best forgotten.
Incidentally, the C committee was smart about this, by defining the C preprocessor so that it operates on C tokens rather than text. That means you can either share the lexer between the preprocessor and the compiler, or do it in a single pass like Clang does (the conceptual phase ordering being lexer -> preprocessor -> parser).
Which brings up another point: Lex (in particular) also comes from a time in history where it was prohibitively expensive to hold the program text in memory. Today we just memory map it all and work on memory buffers. It's much easier to hand-write a lexer if it doesn't have to deal with interleaved I/O!
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
And Javascript got it from C: if/while/for (...), braces around blocks, the break/continue, return. It's all very C-like. I don't find typescript's extensions that weird. It would be more C-like to write
function int f(int x)
but I like the ts syntax better.
This is an incredibly useless response. You're asking everybody in the world to make sure their software is Python-safe, even the software that was written before Python was popular and is no longer maintained. Seriously, if your solution to a problem is to make everybody else conform to your particular taste, you don't have a solution.
If I can push a C program through some communication path and re-indent, and I can't do that with Python, then that's an advantage of C. I can't always choose communication paths.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Microsoft does a lot wrong, but I'll give them kudos where due. Their Common Language Runtime has allowed one to code in either VB style or C style using mostly the same constructs and language processor engine.
If you design a new language, allow it to have 3 syntax styles:
1. C style
2. VB-ish style (x...end x, with underscore for continuation, type-name after variable.)
3. Python/Ruby style with white-space block nesting
At least one of these styles should make a given coder sufficiently happy (except maybe Lisp fans).
Make a translator that can convert between each style so that if a person or shop gets the style they don't want, they can convert, and/or allow them to mix their code with the code in the other style. (There may be edge cases where direct conversion may require human intervention.)
Thus, one module could be written in C-style, but work with a module in the VB style.
I was thinking of a compiler/interpreter that would look at function declarations to determine the style of that function. If it starts with "def", then assume the rest of the function has the Python/Ruby style. If the function body starts with "{", then assume C-style, otherwise it's VB-style.
Table-ized A.I.
My current job is helping a team to replace a 3rd party billing provider which still uses 4D databases.
You can imagine why we are firing them.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.