Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Show me a 'Hello, World!' in Swift
- Thread starter aaronvan
- Start date
- Sort by reaction score
The declaration and initialization was something like
var announcement = "Hello, world"
Apparantly the variable knows it's a string because a string is being assigned to it. No semi colon, no *, no @
Why does this remember me of visual basic a decade ago?
Oh right, just putting it onto the screen is the java/Arduino command println.
var announcement = "Hello, world"
Apparantly the variable knows it's a string because a string is being assigned to it. No semi colon, no *, no @
Why does this remember me of visual basic a decade ago?
Oh right, just putting it onto the screen is the java/Arduino command println.
Last edited:
println is Java and Arduino (and probably many other languages) but not C. In C you use printf. Why they couldn't just use print like Python is anyones guess.
No, if you want to see C, you should skip to the section on the numeric types. That looks like it has hardly changed since C.
From what I've seen, it looks like Swift is Rust. Someone made that comment on Wikipedia (I'd never heard of Rust prior to it) and it looks like they're right - I don't see major differences between the two.
println is a global function that prints a value, followed by a line break, to an appropriate output. If you are working in Xcode, for example, println prints its output in Xcodes console pane. (A second function, print, performs the same task without appending a line break to the end of the value to be printed.)
Excerpt From: Apple Inc. The Swift Programming Language. iBooks. https://itun.es/fi/jEUH0.l
----------
Sorry to be picky, but "Hello, world" is a string
Sorry to be picky, but "Hello, world" is a string
Not only that, but you should use "let", not "var". Goddamnit, this language was only revealed a few hours ago, and one of the first things they tell you is that you should be using constants as much as possible, and already you people are using variables where you should use constants. I've struggled mightily for the past few years trying to get people to use the "const" keyword in C/C++/Obj-C, but my efforts were in vain. I thought it was because const wasn't added until years after the first version of the language was unveiled. Now I see that it'll take more than it being there from the start for people to use it.
Maybe the syntax needs to be easier. Maybe
announcement "Hello World"
should work the way
let announcement = "Hello World"
does, so that it'll be fewer characters to type and people will somehow think it's better as a result (when really it's better for an entirely unrelated reason... and probably less readable... but at least safer).
Of course, I was just mad when writing it“println is a global function that prints a value, followed by a line break, to an appropriate output. If you are working in Xcode, for example, println prints its output in Xcode’s “console” pane. (A second function, print, performs the same task without appending a line break to the end of the value to be printed.)”
Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/fi/jEUH0.l
----------
Sorry to be picky, but "Hello, world" is a string
----------
my apologies, I didn't get to the swift book yet. I've corrected the other mistakes, I feel stupid today.
Force them to work on an embedded platform that has 16k flash and 128 bytes of ram. They will either get clever fast or declare you can't do anything useful without 4GB of ram.
It's important to specify constants because it allows the compiler to make optimizations and for the program to run more quickly.
They're making a big deal over safety in this language, too. The more tightly you control your code with stuff like constants the less likely you'll make a mistake.
xcrun swift sourcefile.swift
... assuming you have Xcode 6 set as your default via xcode-select.
Xcode 6 isn't available for free? Only who is signed up on developer program is able to access that?
XCode 6 *beta* is available for registered iOS and OS X developers. XCode in general (non beta) is available to others (hobbyist programmers for example), so you'll have to wait until the final version is released.
it's very strange, it doesn't forgive you if you don't leave spaces between the variable and equal sign and declaration, as in these examples.
var test = 12 \\ no problem
var test=12 \\ Editor shows an error and the interpreter does nothing.
Also, in some cases, it is case-sensitive.
Played around with Swift a little today. Made some type mistakes on purpose to see what kinds of messages I'd get from the compiler. Believe me, some of them are very cryptic and non-helpful. It's going to take some experimentation if you make a type mistake.
bit draconian there...
I know still new but any options to tone the rules down a bit?
I know with perl you get a few "best practices" modules that are adjustable to be not be as strict as needed.
I know good code format is fundamental but say doing a class assigment and its really late at night I know I don't follow best practices to the T all the time.
If say R (what I am learning atm online) stopped working everytime I wrote say
var<-123
not var <- 123
....we'd have some issues at around midnight.
Tell me you are kidding! I'll rip my eyes out looking for this in a couple thousand lines of code.
Heading off to disprove this right now, so that I can keep my sanity.
Well,this is still beta. I really hope the Editor will automatically fix any spacing issues. Plus, it's not hard to detect, as it points to the line and word where the error is located.
Another issue I found with Playground is that it uses a lot of resources because it's always active and analyzing everything you type in realtime, on the paranoid side. It may be better if there's a button or shortcut key we can push to manually ask it to start interpreting the code.
I'm sure it will evolve from now until release day.
You'd hope so!
I haven't seen what the list of allowed characters in a variable name are, but considering unicode characters and emoji are allowed, I really hope the equals sign isn't!
You could really mess with the heads of fellow developers if it is!
I've been tilting at the same windmill for years, with the same mostly disappointing results.
Some C-family programmers look at "const" as extra work/extra typing with no benefit. They can always claim the program "works the same without const", so "const" is unnecessary. (Even thought it isn't always true in C++, these folks usually haven't mastered C++ well enough to use those parts.) They find (or claim to find) no value in helping the compiler catch foolish mistakes, and no value in better expressing the code's intent with "const".
Sometimes they just don't know better; a subset of those can be trained to do better.
Sometimes they LIKE making their code as obscure as possible as a twisted form of job security. Avoiding "const" is just one tool in their arsenal. They are usually masters of the entire Book of Foul Code Smells.
Regardless of the cause, this kind of programmer is expensive. They make extra work (cleaning up after them). If they reach critical mass in a project, it's pretty likely to fail. This kind of programmer seems to thrive in the "anything goes" world of C. They usually HATE languages like Swift that are designed to suppress bad habits. They hate compiler warnings and ignore them when possible. They hate type checking. They will hate optionals in Swift, because they will be reminded of all the "it might not exist" bugs they've been leaving in their code for years. Etc., etc., etc.
So I say "Hurrah Swift!". Anything that makes Code Slobs uncomfortable is fine with me.
I've been tilting at the same windmill for years, with the same mostly disappointing results.
Some C-family programmers look at "const" as extra work/extra typing with no benefit. They can always claim the program "works the same without const", so "const" is unnecessary. (Even thought it isn't always true in C++, these folks usually haven't mastered C++ well enough to use those parts.) They find (or claim to find) no value in helping the compiler catch foolish mistakes, and no value in better expressing the code's intent with "const".
Sometimes they just don't know better; a subset of those can be trained to do better.
Sometimes they LIKE making their code as obscure as possible as a twisted form of job security. Avoiding "const" is just one tool in their arsenal. They are usually masters of the entire Book of Foul Code Smells.
Regardless of the cause, this kind of programmer is expensive. They make extra work (cleaning up after them). If they reach critical mass in a project, it's pretty likely to fail. This kind of programmer seems to thrive in the "anything goes" world of C. They usually HATE languages like Swift that are designed to suppress bad habits. They hate compiler warnings and ignore them when possible. They hate type checking. They will hate optionals in Swift, because they will be reminded of all the "it might not exist" bugs they've been leaving in their code for years. Etc., etc., etc.
So I say "Hurrah Swift!". Anything that makes Code Slobs uncomfortable is fine with me.
Glad to hear I'm not alone. Optionals look really great. Should end up with a lot fewer NPEs at runtime, and without having to use ugly annotations everywhere to explicitly say whether things may or may not use null.
A bigger issue, thinking about it, than people making variables of things that should be constant, is that people make macros of things that should be constants, and they try arguing that they're the exact same, or even better.
If there are macros in Swift, I haven't reached that section of the manual yet. Hopefully they're hygenic if they're present.