Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by martyb on Friday December 04 2015, @06:52PM   Printer-friendly
from the Is-that-you-Jonathan? dept.

Swift Is Open Source

Swift, Apple's hot new programming language, is now open source. It is available (or will be once the web site isn't so overwhelmed!) for Mac and Linux under an Apache 2.0 license.

"Swift is now open source! We are excited by this new chapter in the story of Swift. After Apple unveiled the Swift programming language, it quickly became one of the fastest growing languages in history. Swift makes it easy to write software that is incredibly fast and safe by design. Now that Swift is open source, you can help make the best general purpose programming language available everywhere. "

Apple Open-Sources Swift and Releases Linux port, as Promised

Apple's Swift programming language may eventually replace the respected but arcane Objective C as the native language for OS X and iOS development, but if you don't have a Mac you might be forgiven for not having taken an interest so far.

However, as MacRumors now reports, Apple have now delivered on their promise to open-source Swift and release a Linux port. It doesn't sound as if the Linux port is quite ready for production use just yet, but the source is out there. Does this mean that Swift is now a contender for general purpose programming?

(Note: at the time of writing, the servers at Swift.org are failing to live up to their name.)


Original Submission #1Original Submission #2

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by danaris on Friday December 04 2015, @08:29PM

    by danaris (3853) on Friday December 04 2015, @08:29PM (#271933)

    IBM has put up a sandbox page [bluemix.net], where you can try out Swift and see its results quickly without having to install any toolchain yourself.

    Obviously, it's a good idea to at least take a look at the language docs before trying it :-)

    Dan Aris

  • (Score: 2) by takyon on Friday December 04 2015, @08:34PM

    by takyon (881) <takyonNO@SPAMsoylentnews.org> on Friday December 04 2015, @08:34PM (#271938) Journal
  • (Score: 0) by Anonymous Coward on Saturday December 05 2015, @12:12AM

    by Anonymous Coward on Saturday December 05 2015, @12:12AM (#272015)

    func fibonacci(i: Int) -> Int {
            if i <= 2 {
                    return 1
            } else {
                    return fibonacci(i - 1) + fibonacci(i - 2)
            }
    }

    No parenthesis around if-conditions? Blasphemy!

    • (Score: 2) by BasilBrush on Saturday December 05 2015, @10:40PM

      by BasilBrush (3994) on Saturday December 05 2015, @10:40PM (#272287)

      Yeah, swift tends to drop superfluous constructs. No need to use semicolons where newlines separate statements anyway. No need to declare the types of variables in or before an assignment if the type is implicit in the RHS etc. It makes for clean code.

      --
      Hurrah! Quoting works now!
      • (Score: 2) by vux984 on Monday December 07 2015, @04:49AM

        by vux984 (5045) on Monday December 07 2015, @04:49AM (#272745)

        It makes for clean code.

        It makes for brittle code. The extra structure in other languages isn't superfluous, its 'error correction code'; and it helps catch errors where they happen rather then where things finally break in the code.

        if I write

        int x = 11

        And then 12 years later someone comes along and writes int x=11.5; instant compile error. Right where the change was made. if all I wrote was:

        x=11

        and the compiler automatically assigns it as int because "its obvious that's what I want" and then 12 years later someone comes along and writes

        x=11.5 and the compiler automatically assigns it as float or double because "its obvious that's what I want", and then all sorts of bizzare errors crop up... suddenly some client/server IPC breaks somewhere because the data being exchanged is the wrong size and type.

        People underestimate the value of there being some structural redundancy. Yes too much and the language just becomes needlessly verbose -- not enough and the language trips over itself helping you, causing you more trouble than it saves.

        Python's whitespace is like this too -- it saves you some curly braces but I find it makes the code a lot more brittle (less maintainable) and much easier to botch the program structure during maintenance refactoring and editing especially if you are copy and pasting things around. Plus I admit I like being able to just make a mess of the code, drop some curly braces in, and then 'autoformat' and it sets up all the indentation and then I double check it. I much prefer that to manually re-doing all the indentation myself.

        • (Score: 2) by BasilBrush on Tuesday December 08 2015, @01:33AM

          by BasilBrush (3994) on Tuesday December 08 2015, @01:33AM (#273139)

          https://en.wikipedia.org/wiki/Don%27t_repeat_yourself [wikipedia.org]

          suddenly some client/server IPC breaks somewhere because the data being exchanged is the wrong size and type.

          No because APIs define their parameter types.

          Plus I admit I like being able to just make a mess of the code, drop some curly braces in, and then 'autoformat' and it sets up all the indentation and then I double check it.

          Human beings do not understand code block structures by the number of braces, but by the indentation. You're dropping curly braces in order to get the indentation (and therefore the block structure) right. Which is backwards. Again you are suffering from repeating yourself. Mentally converting from one thing to another, then getting the editor to fix up the first thing from that.

          With Python you just deal with the primary issue - make the indentation show the block structure you want.

          I much prefer that to manually re-doing all the indentation myself.

          All you are doing is manually editing indentation via a more convoluted method.

          --
          Hurrah! Quoting works now!
          • (Score: 2) by vux984 on Wednesday December 09 2015, @05:26AM

            by vux984 (5045) on Wednesday December 09 2015, @05:26AM (#273811)

            No because APIs define their parameter types.

            Nitpicking. If you can't think of a situation where automatic type inference failed, or created problems down the road in maintenance you aren't trying.

            You're dropping curly braces in order to get the indentation

            Essentially yes.

            Which is backwards.

            I disagree.

            Again you are suffering from repeating yourself.

            No, I only enter the braces, the editor does the indentation. The information is 'repeated' but its not extra work for me.

            With Python you just deal with the primary issue - make the indentation show the block structure you want.

            Except that whitespace is incredibly fragile; and poorly preserved by all kinds of common text editing applications and operations. And you don't really edit it, you use it to 'push' other things around.

            Mentally converting from one thing to another

            Entering whitespace is no less a mental conversion. You want the code to be 'here' so you hit 'tab' and 'space' and 'delete' to push and pull it around, because you can't just tell it ... be HERE. Proper delimiters are at least less work to enter, and can automatically reform to an indented state if the whitespace/indenting gets mangled. And if you delete one by accident, its trivially detected that they aren't balanced. Delete an indent level somehwere by accident and the code just does something different.

            • (Score: 2) by BasilBrush on Thursday December 10 2015, @03:58PM

              by BasilBrush (3994) on Thursday December 10 2015, @03:58PM (#274493)

              Nitpicking. If you can't think of a situation where automatic type inference failed, or created problems down the road in maintenance you aren't trying.

              It's ALWAYS possible to create bugs by editing code. The point is that repeating yourself makes it more likely rather than less.

              Except that whitespace is incredibly fragile; and poorly preserved by all kinds of common text editing applications and operations.

              Then don't use broken tools. We're not in the 1970s anymore.

              Entering whitespace is no less a mental conversion. You want the code to be 'here' so you hit 'tab' and 'space' and 'delete' to push and pull it around, because you can't just tell it ... be HERE.

              Again you have a tool problem. Or you need to learn it. You suggest the editor is clever enough to reformat code based on braces. But it doesn't have indent and unindent operations???

              --
              Hurrah! Quoting works now!
              • (Score: 2) by vux984 on Thursday December 10 2015, @07:23PM

                by vux984 (5045) on Thursday December 10 2015, @07:23PM (#274590)

                The point is that repeating yourself makes it more likely rather than less.

                More likely that you make a simple compile time error; but less likely that you make a program logic error. Compile time errors are trivial to fix by comparison and worst case make you re-think program logic which is a good thing.

                Then don't use broken tools. We're not in the 1970s anymore.

                Quite. But I consider it a hallmark of a good language that I can work with it in notepad / vi /vim / textedit if I have to.
                A language that can only be efficiently worked on in a special tool is broken by design. Almost as bad as languages which have proprietary non-plaintext formats for the source.

                Again you have a tool problem. Or you need to learn it. You suggest the editor is clever enough to reformat code based on braces. But it doesn't have indent and unindent operations???

                Not at all. Entering curly braces just requires typing single characters where needed, and then hitting the button to reformat. If I'm moving code around between indent levels but not changing the logical structure (e.g. I'm copying code from outside a loop to inside the loop, I can just copy/paste and reformat.

                With white space, I have to highlight the blocks that need to be indented first, that's more effort than just dropping a single curly brace. And when I'm copying code around but not changing the program structure -- if the code is being moved between indent levels I have to fix them manually.

                Plus if I copy/paste some code snippet or function to a forum or a word document or an email or chat messenger tool or IRC or skype anything else that ISN'T a "programming tool", and which is often quite hostile to whitespace I infinitely prefer to have the code retain its correctness so that the recipient can copy it back out and it just works, and they can hit a hotkey to reformat it.

                Whitespace should not used as anything more than an elementary delimiter. Whitespace as program flow semantics is idiotic.
                The improvement in "readability" by not having braces is minimal, and not worth anything to me, while the costs imposed by working with it are significant and unjustifiable.

                • (Score: 2) by BasilBrush on Friday December 11 2015, @10:09PM

                  by BasilBrush (3994) on Friday December 11 2015, @10:09PM (#275176)

                  You quoted but didn't understand my point. You take it as an assumption that there is a "format button" that knows how to auto-format code in your chosen language. But you also take it as an assumption that the editor doesn't make indenting and unindenting and copy/pasting between indent levels easy.

                  This means that you only have experience of editors that understand C but not editors that understand Python. Or that you've never actually used Python. Either way it's a lack of experience on your part.

                  --
                  Hurrah! Quoting works now!