Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Programming Open Source Apple

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.
This discussion has been archived. No new comments can be posted.

The Swift Programming Language's Most Commonly Rejected Changes

Comments Filter:
  • by Anonymous Coward on Friday January 01, 2016 @04:59PM (#51223145)

    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.

    • by mveloso ( 325617 ) on Friday January 01, 2016 @05:04PM (#51223171)

      Yeah, it's crazy. "Let's make some invisible character with a variable width significant."

      • Why do you hate Makefiles?

      • I find that Python is attractive, and works extremely well, for people well-suited to information-dense representation of ideas. This includes physicists, mathematicians and other folks who are used to that property of the hard sciences literature. For software architects and developers, its attractiveness is more if a mixed bag, where many of those folks are more comfortable and productive with a greater amount of structure.
      • Yeah, it's crazy. "Let's make some invisible character with a variable width significant."

        Like Makefiles do?

        • by SuperKendall ( 25149 ) on Friday January 01, 2016 @09:43PM (#51224627)

          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.

          • 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.

            • 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

    • 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)

      by Anonymous Coward

      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.

    • Yea, I'm always amazed when I read/hear people who actually like Python's use of whitespace. It's by far my biggest complaint about the language and a big reason why I don't use it. I can't count the number of times somebody messed up whitespace, mixed tabs/spaces, etc in other code and those changes would have broken python code.
  • by Anonymous Coward

    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.

  • by BitZtream ( 692029 ) on Friday January 01, 2016 @05:02PM (#51223161)

    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.

    • by bill_mcgonigle ( 4333 ) * on Friday January 01, 2016 @05:16PM (#51223257) Homepage Journal

      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?

      • 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)

      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.
      • by TheRaven64 ( 641858 ) on Friday January 01, 2016 @06:09PM (#51223539) Journal

        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:

        • Write your compiler in an inappropriate language.
        • Make your language good for writing compilers, at the expense of its intended uses.
      • Which language was able to do it on the first pass?
      • by pjt33 ( 739471 )

        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

      • by jcr ( 53032 )

        I can easily remember when any language that couldn't compile its own compiler was considered a toy language.

        I remember that too, but it turns out that self-compilation is a parlor trick. We all have more important things to do than rewrite a compiler when one already exists that does the job.

        -jcr

    • 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.

    • by tepples ( 727027 )

      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?

    • > 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?

    • by srijon ( 1091345 )

      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.

      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

  • Eminently Practical (Score:5, Interesting)

    by SuperKendall ( 25149 ) on Friday January 01, 2016 @05:07PM (#51223193)

    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)

    by Dan East ( 318230 ) on Friday January 01, 2016 @05:13PM (#51223241) Homepage Journal

    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)

      by JazzHarper ( 745403 ) on Friday January 01, 2016 @06:36PM (#51223699) Journal

      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."

  • 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

    • 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".

      • by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Friday January 01, 2016 @06:30PM (#51223663) Homepage

        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.

        • 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.

      • 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.

        • by tepples ( 727027 )

          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?

          • 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.

      • "Because Unicode" is used to justify all manner of things.

        And it's always wrong.

        • by tepples ( 727027 )

          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".

  • by JoeyRox ( 2711699 ) on Friday January 01, 2016 @05:25PM (#51223321)
    What?.Were?.They?.Thinking
    • by Kjella ( 173770 )

      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.

    • 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

    • 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?

  • 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.
  • They're sounding suspiciously like a software company that distributes a desktop OS and starts with the letter "M."

    • by Luthair ( 847766 )
      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.
    • 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

  • Make it more like Java.

    Make it less like Java.

  • It looks like most of the list is just an effort by people to make Swift look like whatever language they're using currently.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (8) I'm on the committee and I *still* don't know what the hell #pragma is for.

Working...