Apple introduces a new programming language named “Swift”.
It appears that Swift is intended to more or less replace Objective-C, although it can be mixed with C and Objective-C in the same project.
ArsTechnica writes: “Swift seems to get rid of Objective C’s reliance on defined pointers; instead, the compiler infers the variable type, just as many scripting languages do. At the same time, it provides modern features similar to those found in C++ and Java, like well-defined namespaces, generics, and operator overloading. From the few fragments of code shown during the demo, Swift appears to rely heavily on the dot-notation that Apple introduced in an earlier iteration of Objective C.”
Swift also uses ARC instead of garbage collection.
https://developer.apple.com/swift/
https://itunes.apple.com/us/book/the-swift-programming-language/id881256329?mt=11
http://arstechnica.com/apple/2014/06/apple-shows-off-swift-its-new-programming-language/
So if someone has to learn Swift for future iOS development, shouldn’t they learn Object Pascal instead — so they are also covered for Android?
Jesus, what an ugly language. E.g.: What’s the difference between:
for index in 1…5 {
println(“(index) times 5 is (index * 5)”)
}
and
for index in 1..5 {
println(“(index) times 5 is (index * 5)”)
}
?
I bet you can’t see any difference. Just like most developers won’t. But count the range operator dots (.. vs …). Now guess what their meaning is?
The PDF is here: The Swift Programming Language pdf and e-book
Markus Joos Yeah, that’s pretty fugly. Easy to make mistakes, and hard to find them with that syntax.
Ok, here is another Swift “gem”:
if myClassInstance1 === myClassInstance2 {
println(“Holy Christ, what does that mean?.”)
vs.
if myClassInstance1 == myClassInstance2 {
println(“Holy Christ, and what does that mean?.”)
Well, I really like the verbosity of Delphi in which the above would read:
if myClassInstance1.Equals(myClassInstance2) then writeln(‘ This is pretty clear, or not?’);
vs.
if
myClassInstance1 = myClassInstance2 then writeln(‘ This is pretty clear, if you know that class instances are ref types in Delphi’);
Marco Cantù
I agree 100%. And from a rational point of view I think anybody should come to that conclusion (or a similar one like using Xamarin etc). But I fear that still a lot of developers will jump to Swift instead of Delphi just because Apple has a thousand times the marketing capacity of EMB. Or maybe on the other hand EMB should take this as a chance to catch quite a few jumping from the objective-C boat?
The above mentioned quirks are not really bad, as any range errors usually rear their head quite fast. 0..count instead of 0..count-1 makes for good readability, and for list and arrays you use the for var in list syntax.
Since the == operator can be overloaded, an identical operator is needed.
Having browsed the ebook, I have to say that Swift looks like a very nice language.
A lot of thought to detail, such as
Nestable block comments /* /* */ */
Discardable loop variable with _
let base = 3
let power = 10
var answer = 1
for _ in 1…power {
answer *= base
}
println(“(base) to the power of (power) is (answer)”)
// prints “3 to the power of 10 is 59049”
No fall-through in switch statements, instead it behaves like Delphi case statements, unless you explicitly declare fallthrough at the end of a case statement
External parameter names that force the caller to name each parameter should reduce the risk of mis-parametrization.
func join(string s1: String, toString s2: String, withJoiner joiner: String)
-> String {
return s1 + joiner + s2
}
calls as
join(string: “hello”, toString: “world”, withJoiner: “, “)
Lars Fosdal
except that you can omit the first parameter name – why ?
Sorry, I can’t stop:
/* this one is quite nice */
let myconst = 123_456_789
/* but this one presumably also compiles */
let my const = 12_1_23456_5_1
Lars Fosdal
About Identity and Equality operators:
While 7 ==8 is unambigious (or can I overload operators for simple types in Swift ?)
myisnt1 == myInst2 is completely up to the implementation of the Equality operator.
Therefore I agree, that it is necessary to have a different operator for identitiy. But to choose almost the same operator symbol (=== vs ==) cries for errors:
The compiler will happily compile both of those:
if myInst == myInst2
if myInst === myIsnt2
but the underlying comparison can be very distinct, or not depending on the implementation of the equality operator for classes. I believe this can lead to very hard to find errors.
Markus Joos – you can’t omit the first param name. It is actually named string.
Any underscores in numerical constants are ignored. “let my const = 123” will not compile though.
I don’t think those equality mistakes will be hard to find. If you use the ===, it will either always fail, or be true once. If you use ==, it will return true once, if comparing with self, or multiple times if the comparator find the value to be equal.
Lars Fosdal
I am pretty sure I read in the Language Guide that you can omit the parameter name for the first parameter. While we can discuss whether this level of verbosity is useful or not, but if I am right and you can omit the first param name then this is quite inconsistent.
And why should “let MyConst = 123” not compile?
I haven’t spotted anything about “omit first named param” in the language guide.
Markus Joos Your second declaration in your comment from 12:32 has a space between my and const, which won’t compile.
Lars Fosdal
Here you go: “Methods on classes have one important difference from functions. Parameter names in
functions are used only within the function, but parameters names in methods are also
used when you call the method (except for the first parameter). By default, a method has
the same name for its parameters when you call it and within the method itself. You can
specify a second name, which is used inside the method.”
Didn’t see that one. Appears to apply only to the class method example though, as an external param name is not declared for amount.
class Counter {
var count: Int = 0
func incrementBy(amount: Int, numberOfTimes times: Int) {
count += amount * times
}
}
var counter = Counter()
counter.incrementBy(2, numberOfTimes: 7)
.. but you can program with emoticons!!
http://www.globalnerdy.com/2014/06/03/swift-fun-fact-1-you-can-use-emoji-characters-in-variable-constant-function-and-class-names/
Lars Fosdal
As I read it, external param names are optional, which makes this even messier IMO.
Vin Colgin
Yes, another great “gem”, ins’t it ? 😉
Markus Joos
External parameters are indeed optional, and a tool for those that design complex and parameter rich code – which when used, will help avoid misparameterization. The fact that is optional, cannot be construed as a mess, IMO.
Vin Colgin
You can use Unicode in Delphi sourcecode as well.
program Project1;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils;
procedure ☺(const ☺☺: string);
begin
writeln(☺☺);
end;
function ∑(const ∞ : array of Integer):Integer;
var
∆: Integer;
begin
Result := 0;
for ∆ in ∞
do Result := Result + ∆;
end;
begin
try
try
☺(‘☺’);
Writeln(∑([1,2,5,8,9]));
finally
write(‘Press Enter ‘);
Readln;
end;
except
on E: Exception do
Writeln(E.ClassName, ‘: ‘, E.Message);
end;
end.
yeah. They lost me the second I saw the keyword “LET” and the “=” vs “==” vs “===”.
I’m all for scripting languages, when it’s about convenience of changes. But, I’m not all that thrilled with lower-entry levels for programming. It’s nice that it’s so quick for newbies, but IMHO, that’s what makes being a “expert” in PHP so hard to define. Bro-gramming!
Sounds a little elitist, but 1 million apps doesn’t impress me. Locking a million developers into a platform specific language, now that’s impressive.
Lars Fosdal
Please enlighten me: What should external param names be good for ? Shouldn’t the parameter not just be as expressive both from within the method as it is for the caller?
Obviously if some implementor of a method prefers to work with a,b and c as parameter names then having at least the possibility to have meaningful names to the caller of the method makes sense.
The point of external named parameters, are that it makes the purpose of the parameter quite a bit more accessible when reading the code where it is called, and also a lot harder to screw up by passing parameters in the wrong order.
Lars Fosdal
Well, I think a good IDE would help me out with this.
What I don’t get is, that a lot of people are complaining about Delphi beeing overly verbose and that typing begin and end is too much of an effort. I wonder what those same people say about being forced to write out the parameter names for every method call.
I think their verbosity complaint is about begin/end vs curly brackets, and I agree – it’s a bit silly.
Although named parameters makes the code more verbose, I think that this particular verbosity can be good for readability, when appropriately applied, and although most good IDEs willingly present argument names with a little cursor and keyboard trickery – that is not as efficient for reading code as the text being in your face in the first place.
Named parameters would be nice in Delphi too.
MyObject.Process(Data, True, False, 500);
MyObject.Process(Data, Normalized: True, Smoothed: False, Iterations: 500);
It feels like in 2001 when C# was in beta. The language should now be fun to work with, Swift book is good, but the frameworks, the Swift book should have another 1000 pages for the frameworks. Need to know them for work in Delphi too.
Gustav Schubert – Yeah, it’s definitively in the “Oh, Shiny!” phase. It will be interesting to see it in action.
Lars Fosdal
Ok Lars, point taken. I agree that it might be good to have parameter names. But then, why oh why is it allowed to omit the first one? I get the feeling that many things are half baked in Swift and this although the language has been in development for4 years.
You can omit external names on any param, as far as I can tell. External names are probably best used where the type values are not self descriptive, such as char, string, boolean, integer, or double, where as enumerated values can be self-describing.
To me it seems natural to omit the first param in many cases, as it usually is the parameter that the method operates on, and other parameters are conditions and modifiers.
Inc(Value, 1, Max:500);
Personally, I think Swift looks quite well thought out – but – it has been created in a bubble, and the real world is about to pop that bubble. For a first iteration, it looks pretty good.
Delphi has changed a lot over the years, as have Java, C# and C++, so it’s not like they only get one shot at making it a good tool?
Another thing with external named params, which in theory is possible – I have not checked the docs for this, so this is speculation:
Named params can have default values. This means, in theory, that you can chose to pass a non-sequential subset of parameters, unlike in Delphi, where you only can drop default value params from the end and forwards.
Also, I am not sure if parameter ordering is optional with named params.
Lars Fosdal C# does this: “If you do not remember the order of the parameters but you do know their names, you can send the arguments in either order, weight first or height first.” since 2010 http://msdn.microsoft.com/en-us/library/dd264739.aspx
Jeroen Wiert Pluimers good find. I had no idea a compiler did that now a days. It begs the question of how one remembers argument names (without IDE tools) and not the order (which IDE tool supplies). But it’s pretty cool. I kind of like the idea of being able to do that in my code.