The Swift Programming Language's Most Commonly Rejected Changes (github.com) 339
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.
People actually *like* Python whitespace? (Score:5, Insightful)
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.
Re:People actually *like* Python whitespace? (Score:5, Insightful)
Yeah, it's crazy. "Let's make some invisible character with a variable width significant."
Re: (Score:2)
Why do you hate Makefiles?
Re: (Score:2)
Re: (Score:2)
Like Makefiles do?
Re:People actually *like* Python whitespace? (Score:4, Insightful)
Why do you think people didn't hate that aspect of Makefiles the same reason. Especially bad there as it used to be the case it HAD to be a tab, not a space, and if your editor had been configured to convert tabs to spaces BOOM, dead Makefile.
Re: (Score:3)
Why do you think people didn't hate that aspect of Makefiles the same reason. Especially bad there as it used to be the case it HAD to be a tab, not a space, and if your editor had been configured to convert tabs to spaces BOOM, dead Makefile.
Or cut/copy and paste in X Windows where tabs get converted into spaces.
Re: (Score:3)
Or cut/copy and paste in X Windows where tabs get converted into spaces.
No they don't. This is very simply not true. If you like, I could go into an arbitrarily detailed explanation of how the copy/paste system works in X11 (and DnD---they're the same mechanism and they also follow a reasonably sensible design). I can happily copy/paste text between my browser and editors all day without tabs and spaces getting mixed up.
To repeat: There is absolutely *no* replacement of tabs with spaces in X11 itself. If
Re: People actually *like* Python whitespace? (Score:5, Insightful)
If you're using variable-width fonts for coding, you're doing it wrong.
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.
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:
Re: People actually *like* Python whitespace? (Score:5, Insightful)
because when i'm moving blocks around, whitespace changes turn my original program into a ..umm.wait...
perfectly valid other program which has nothing to do with my original intent
Re: People actually *like* Python whitespace? (Score:5, Informative)
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.
Re: People actually *like* Python whitespace? (Score:5, Informative)
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.
Re: People actually *like* Python whitespace? (Score:5, Funny)
if (flag)
if (other_flag) do_this();
else
do_that();
Re: (Score:2, Insightful)
If you accidentally get whitespace stripped out for some reason, a language which doesnt rely on whitespace would still function as expected.
Re: (Score:2, Insightful)
If any part of your workflow unexpectedly strips out whitespace "for some reason", you've got bigger problems.
Re: (Score:2, Interesting)
It has happened when you use --ignore-whitespaces when merging with git.
Most of the code in the repository isn't Python and the Python code was part of something that wasn't run often, so we didn't notice the bad indentation from ignoreing the whitespace during the merge.
Re: People actually *like* Python whitespace? (Score:5, Insightful)
100% this!
twice in the first few months of my learning python, I saw someone post code on a web forum that was impossible to know what the intent was; because the spacing was messed up (web forums do this all the time) and this, alone, proved to me how stupid this braceless style of space-sensitive indenting was.
there are 2 things and they should NOT be combined! one is for the compiler to define what a block is. the other is documentation for humans, so we know what the block is.
and yes, they do act differently. I can use white space to tell a HUMAN things but white space is quite a stupid way to talk to a computer.
there's a lot I like about python, but guido is just plain wrong, here, and its frustrating that he won't admit it.
Re: (Score:3)
The problem is that we can point and yell 'stupid' at whatever we want, but reality is that whitespace is mangled by a lot of things, so use of a language very sensitive to whitespace as a 'learning' language has some challenges. If I made a language that required vowels in the keywords to have umlauts, I could run around and say it's stupid that a lot of keyboards don't have keys for that built in, or I could admit that I made a choice that ignores that reality.
That said, I've seen a lot of C/Java/etc cod
Re: (Score:3)
Re: People actually *like* Python whitespace? (Score:4, Informative)
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.
Re: People actually *like* Python whitespace? (Score:5, Interesting)
also, 100% this.
I could care less what human-A did for his indenting, at least on C code. if the code works and compiles, I can FIX his indentation and not ruin a thing; only make it more readable.
there is no concept of a re-indent or auto-indent (such as found in emacs, for example) for python. you can't do it. because as I posted before about this: there are 2 things and they should never be mixed. one is a cue to the compiler what a block is, and the other is a cue to the HUMAN what a block is. and combining them is what guido fucked up, on.
in C, I can do whatever wild indenting I want and a re-indent can fix it so I can read it again. I got very used to that. code was ROBUST in this way, and humans can mess with the look of it without doing harm. if I move a block from some inline code to a nested routine, it always ALWAYS works. not so in python. in fact, I'm not even sure HOW to move a block from one level of indent to another with perfect safety. its just STUPID!!!! stupid beyond belief to those of us who have been writing code for decades (I'm mid 50's and have been doing software eng work since my teens).
part of me wants to add a feature to the language so I can add braces back again, then preproc the source to remove it as a phase before running the code. I know it won't be accepted by anyone in my company but it would restore sanity to my own python projects, at least.
imagine a source code control system where check-out gets you those braces, you do your edits and each time you save the file to local git or svn (etc) it removes the bad chars and makes it 'real python' again so you can run it. that way you kind of have it both ways and editing, at least, is now more safe.
Wrong, I don't (Score:5, Insightful)
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.
Re: (Score:3)
If you are not going to bother to write code that is easy for humans to read, then I don't want to be one of the people who has to maintain it. I'll take easy to read code over clever any day of the week, because at some point in the future - be it days, weeks, months or years later - someone will have to go back through that code and try to understand what it does.
Over the years, I've seen too much code where nobody understands how it works and won't touch it. Nine times out of ten, it was because of "ob
Re: (Score:2)
I kind of figured that had been fixed, it was Fortran77 I used - I have to admit that was a small quibble really, compensated very well by using Emacs as an editor.
At least I wasn't doing punch cards straight up.
That's the whole problem (Score:2)
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.
Re:That's the whole problem (Score:4, Insightful)
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.
Python is the real "Special Snowflake" here (Score:2)
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 [wikipedia.org] 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
Re: (Score:3)
It applies if you want to be able to understand other people's code more easily.
I don't follow: wanting other people to understand your code is all fine and good, but that doesn't make one of two equally obvious ways more obvious. If you had to learn it from the community then it wasn't obvious in the first place.
Doesn't mean you shouldn't follow the community, but the so-called zen of Python is massively oversold.
The style guide written by the author of the language says "Use 4 spaces per indentation level
Re: (Score:3)
FWIW, the same argument about editor would apply to the 'tedium' of braces. Many editors when contending with languages you hit '{' and enter and poof, proper indentation and close brace inserted.
Re: People actually *like* Python whitespace? (Score:4, Interesting)
[...] 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.
This is why Swift explicitly does not allow for one line statements without curly braces.
more generally speaking, the language tries to avoid things that lead to dumb mistakes, no default fall through on switch case statements, explicitly requiring every case in a switch to be accounted for, etc. Anytime you imply meaning you introduce the potential for had to find bugs - especially later in the code development cycle when someone adds seemingly innocent changes.
Re: (Score:3)
Yeah, because whitespace never gets changed by stuff inadvertently.
Channels that apply line.strip() for line in msg (Score:5, Interesting)
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.
Re: People actually *like* Python whitespace? (Score:5, Interesting)
Re: People actually *like* Python whitespace? (Score:5, Informative)
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.
Re: People actually *like* Python whitespace? (Score:2)
It's cleaner until you get to a sufficiently complex program and that makes indentation so much harder to read because you're exceeding the width of your terminal.
I've worked with Python in an unstructured contributor paradigm. I started having bad dreams about the compiler complaining and failing to run because my indentation was not uniform across the entire code base and I had to go fix it (you can use spaces or tabs but not both and no different ways on the number of spaces either even though they appea
Re: People actually *like* Python whitespace? (Score:2)
You know that coffescript gets compiled to JavaScript, right? Like, you didn't think that browsers executed coffeescript natively, I'm sure you wouldn't have commented if you were that clueless.
Re: (Score:2)
I don't know. This, along with returning -tuples, are the two features of Python I like. Intellectually, it's the exact same as how I otherwise write code, just without the extra keystrokes. It still looks strange to me, but... I get the efficiency.
Re: (Score:2, Interesting)
I do most work in python know, though for most of my life I used C and C++. Python and Emacs just lets me complete some quick and dirty tasks.
If I had to do actual work in Python, it would be annoying. There have been many times when the indention protocol created errors that were difficult to fix. The brackets in C, the operators, make a lot of sense for professional code.
Re: (Score:2)
The moral of the story is.... (Score:2, Insightful)
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.
They're called architects (Score:5, Insightful)
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.
Re:They're called architects (Score:5, Insightful)
Thank you.
If I _had_ to write python, for some reason, I'd probably write a little pre-compiler to take something maintainable that I'd write and output whitespace-tokenized python.
I don't see why the people who want Swift to be Python don't just write one of these of their own. They'd learn why nobody wants to use whitespace as a token separator but after that presumably they'd be happy in their mad little world writing code the way they want and finally compiling it with the Apple compiler.
In the perl community we never told somebody they were crazy if they wanted to code perl in some insane, dead, or fictional, language -- just write a module for it and don't bother us with your dysfunction. What manager at Apple decided it would be a good idea to take feedback from the peanut gallery?
Re: (Score:3)
If I _had_ to write python, for some reason, I'd probably write a little pre-compiler to take something maintainable that I'd write and output whitespace-tokenized python.
Been there, done that. In perl ;-)
Re: (Score:3, Informative)
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.
Re:They're called architects (Score:5, Interesting)
The problem with this attitude is that compilers really should be written in a language that's good for writing compilers. This leaves you two choices:
Re: (Score:3)
Re: (Score:2)
I can't remember which open source project it was that I once tried to compile, but discovered that the README was correct when it said that it wouldn't compile with make. Instead I was instructed to use a make tool by the same author as the project I wanted to compile. So I downloaded the source for that make tool, and discovered that to compile it I needed a compiled version of the make tool. The bootstrap issue is not a problem for closed source projects where you'll always have the previous iteration's
Re: (Score:3)
Re: (Score:2)
You write your languages in C with ASM for the places it makes sense.
The GCC developers aren't using only C any more [gnu.org], and LLVM is written in C++ [llvm.org], as is clang.
The low-level parts of language runtimes might be written in a mix of C and assembler, but that's another matter.
Re: (Score:3)
If you want python ... USE PYTHON.
What should I use if I want all of Python except its slowness, GIL, and inability to detect typos until runtime when a NameError occurs?
Re: (Score:2)
> 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 C/C++ is truly the ultimate programming language, why change it in any way?
Re: (Score:2)
Actually there are loads of reasons to do this, and loads of languages do, including (from Wikipedia) compilers for BASIC, ALGOL, C, D, Pascal, PL/I, Factor, Haskell, Modula-2, Oberon, OCaml, Common Lisp, Scheme, Go, Java, Rust, Python, Sc
Re: (Score:3)
"I've never had a bug caused by indentation changing the logic. Python code is usually succinct enough with small enough methods that things like that are immediately obvious."
How would you know if you've never had one?
It's sad when you contradict yourself in consecutive sentences. LOL
Re: (Score:3)
Unit tests.
Re:They're called architects (Score:5, Insightful)
As a python programmer for 15 years, I've never had a bug caused by indentation changing the logic.
"It's never been a problem for me" is not an argument in favor of anyone using it except you.
"My plan/software/language has a zillion failure modes and hidden quirks, but I have them all memorized and they don't cause me problems. Let's roll this out to the general public."
Re:Rust has made Swift obsolete already. (Score:5, Insightful)
[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.
Re: Rust has made Swift obsolete already. (Score:2)
You know that's a troll, right? They post in like every programming language thread.
Eminently Practical (Score:5, Interesting)
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.
Python (Score:4, Insightful)
Swift's developers don't want to replace Brace Syntax with Python-style indentation.
Good, it seems Swift's developers aren't idiots.
Re:Python (Score:5, Interesting)
In 1976, Stuart Feldman, the author of make(3) at Bell Labs, realized too late that using tab as a significant character (to distinguish recipes from rules) in makefiles was a Bad Idea. In an interview, he admitted, "And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn’t want to screw up my embedded base. The rest, sadly, is history."
Re:Python (Score:5, Insightful)
It's called copy and pasting code. I don't want to have to worry about going over every line ensuring the indentation carried over and either adding or removing it to every line. If the language is brace-based, I can hit Format Document and it adjusts it. Without a delimiter like that, you can't "Format Document".
Re: Python (Score:2)
Yes, sometimes I copy and paste stuffs in my code especially while debugging. Python also bitches if you don't stay consistent with your indentation. Sometimes it just makes more sense to indent differently, especially when you're not soloing the project. Python is like PHP that way, good enough to script or make a not so complex program because a library warrants it but when you need others to do stuff with you, it becomes a gluttonous mess. And yes, a good project would have code style in agreement but th
All the time (Score:2)
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.
Re: (Score:2)
So, you have a shitty editor that doesn't indent code as you go?
My suggestion (Score:2)
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 on
UTF-32 does not hold a grapheme cluster (Score:2)
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 [utf8everywhere.org] for the word "cluster".
Re:UTF-32 does not hold a grapheme cluster (Score:4, Insightful)
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.
Concatenating != indexing (Score:2)
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.
Re: (Score:2)
Let those who few people who care about grapheme clusters use the existing clumsy API. That doesn't mean that the UnicodeScalarView shouldn't be indexable the way it's done in most every other language.
Re: (Score:2)
What can be done, programmatically, with a single code point? Or how is it useful to, say, take a substring that includes the accent (without the letter) of its first character and the letter (without the accent) of its last character?
Re: (Score:2)
What can be done, programmatically, with a single code point?
Plenty. There are many uses of strings that have nothing to do with human language, and a programming language should not make those uses either hard to use or inefficient. In particular, you shouldn't define the character primitive to be functionally equivalent to a substring of unbounded length. That's both hard to use and inefficient.
Re: (Score:3)
"Because Unicode" is used to justify all manner of things.
And it's always wrong.
Re: (Score:2)
Let's say you want to exclude all arguments of the form "Because Unicode". In that case, I'm curious as to how you define a "character".
Yet 'optionals' somehow made it through (Score:3)
Re: (Score:3)
What?.Were?.They?.Thinking
That dereferencing a null pointer is a very common programming mistake? You only need the optional syntax if your objects can be null, if your objects can be null you better make handle that situation. But in many cases people rely on some other business logic to always make it not null, which works great until somebody changes something and the code goes boom. This isn't so much a feature for writing code as it is for maintaining code.
Optional is one of the best aspects of Swift (Score:2, Informative)
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
Re: (Score:3)
I think the Hindley-Milner languages beat it. Haskell had Maybe types standard in the mid-90s (and non-standard several years before that). ML probably had them before Haskell did.
Re: (Score:2)
Why on earth would optionals be considered a bad thing? Not only having the compiler check that you don't ever make a null pointer dereference (probably the single most common type of bug that exists); but also extending that checking to any value that may or may not exist. What possible justification is there to not do that?
Re: (Score:2)
Re: (Score:2)
You realise that swift optimises them away into use of a sentinel in pretty much all cases, right? (usually, actually a null pointer).
Re: (Score:2)
Uhhh, rust's way of dealing with pointers that might be null is optionals...
https://doc.rust-lang.org/std/... [rust-lang.org]
Changing the License to GPLv3 (Score:2)
Re: (Score:2)
So, fuck readability, user opinions, human factors (Score:2)
They're sounding suspiciously like a software company that distributes a desktop OS and starts with the letter "M."
Re: (Score:2)
They actually care about those (Score:2)
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
Top of the list (Score:2)
Make it more like Java.
Make it less like Java.
No real surprises (Score:2)
Re:Duh (Score:5, Interesting)
Don't like it? Fork it!
Or don't use it. It is not as if we were short of programming languages.
Perhaps you guys are not aware that Swift is a language to program Apple DuH-vices. iPhones, iPads etcetera. There are NOT a lot of choices of languages when it comes to that.
But I am glad Apple is not buying the Script Kiddies Crap and 'dumbing' down the language. Python is the last language on Earth anyone should be modeling a professional language on. The Last.
Re: (Score:2)
Ever since Apple was forced to drop the "apps must be originally written in ObjC" from the app store terms, you can write in whatever language you want.
Re:Duh (Score:4, Informative)
Object Pascal [embarcadero.com] and C++ [doc.qt.io] and C# [xamarin.com] and JavaScript [apache.org] to name a few. You can program for iOS using any language which provides you with a toolchain to target iOS.
Re: (Score:3)
Re: (Score:3)
Ahahahaha....C++ and C# are toy languages, and you're going to call HIM a kiddo? Listen sonny, back in my day we had punch cards.
Re: (Score:2)
Re: French programming (Score:3)
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 t
Re: (Score:2)
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/... [wikipedia.org]
My very first programming job (while still finishing uni part time) was with this.
Re: French programming (Score:3)
That'd be 4th Dimension. It was great. I built many a complex website back in the 1990s using 4D.
Re: (Score:3)
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".
New Wave (Score:2)
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 [google.com], Slashdot doesn't support Unicode well.
Re: (Score:2)
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,