iOS Starting to dig into Swift... it sucks.

[Infrared]

I'm just dabbling a little with Swift and as a beginner I'm not qualified to be critical. However, this is Apple's documentation as seen on an iPhone:

The verbose nature of the code presented means that it often won't fit onto the screen. I can reduce the font size, but then it's too small for me to read easily.

This is from Apple's online docs:

At least its wrapping around this time, but it's a bit of a mess. (That's using the default font size in Safari. I haven't increased it.)

It's not helping that they've chosen to use names like "someFunction" etc. They could have used 'f' or 'foo'.

 

[Infrared]

So I have a bit more experience now. I quite like what I've seen of Swift and would certainly prefer it to Objective-C. I think the issue I have, as of now, is less the language than the frameworks documentation. E.g.:

(Class Timer)

https://developer.apple.com/reference/foundation/timer

This is the 'Timer' class, but the document repeatedly refers to 'NSTimer'. If you make the mistake of using NSTimer, you may encounter something like this:

error: MyPlayground.playground:1:9: error: 'NSTimer' has been renamed to 'Timer'
var t = NSTimer()

(Class NSFontManager)

https://developer.apple.com/reference/appkit/nsfontmanager

In the Swift section the first example is given in Objective-C, the wrong language.

(Class CIFilter)

https://developer.apple.com/reference/coreimage/cifilter/1437894-init

The discussion code is written in Objective-C.

I would hope that this documentation is amended and brought up to date.

 

[bjet767]

Funny you mention the documentation of Swift because as a long time ObjectiveC coder I've noticed most of the new programming examples from Apple are written using Swift. Yes I can translate them fairly easily but it's clear Apple is putting its eggs into the Swift basket.

That's ok with me.

 

[SmalltalkFan]

I'm hating Swift. A lot.

I learned Pascal, C, C++, Smalltalk, Java, then Objective C. I like C. I mastered C++ as my first OO language but found it ultimately unsatisfying. Always fighting the type system. Smalltalk was a revelation. All the talk about "type safety" and "compiler verified" code turned out to be just dogma. I wrote more expressive and reliable code in Smalltalk - a highly dynamic duck typed language.

When introduced to Objective C I found it obvious after working in Smalltalk. Objective C is Smalltalk's object model and messaging syntax grafted onto C. It is a brilliant compromise. You can transition from insanely dynamic to wicked fast (raw C) or whatever in between. It has tremendous dynamic range. The main deficiency was a lack of blocks and those have since been added.

I've been doing Swift for about six months. I absolutely hate it but the clients are demanding it. It feels like having my wings clipped. Optionals are gratuitous complexity and a horrible way to handle nil. A better update would have been to bind nil to a global object to represent nil and allow the programmer to put whatever object he liked there to either raise errors or ignore them at his discretion.

Smalltalk was the inspiration for the Mac. It brought us test driven development, refactoring tools, a huge number of classic design patterns, and inspired Cocoa. Smalltalk is a tiny language. The entire syntax can be described on an index card. Adding atop C meant that the Objective C book was practically a pamphlet and I learned enough to be productive in a few hours. I mastered it in a week.

Swift's book is 1000+ pages. I've been working in it for six months, and I still struggle with it daily. It is too complicated, too rigid, lacks dynamic features that Cocoa relies on and the bridging to Objective C is awkward at best. Swift is a language only a compiler writer could love.

 

[PizzaBoxStyle]

I'm hating Swift. A lot.

I learned Pascal, C, C++, Smalltalk, Java, then Objective C. I like C. I mastered C++ as my first OO language but found it ultimately unsatisfying. Always fighting the type system. Smalltalk was a revelation. All the talk about "type safety" and "compiler verified" code turned out to be just dogma. I wrote more expressive and reliable code in Smalltalk - a highly dynamic duck typed language.

When introduced to Objective C I found it obvious after working in Smalltalk. Objective C is Smalltalk's object model and messaging syntax grafted onto C. It is a brilliant compromise. You can transition from insanely dynamic to wicked fast (raw C) or whatever in between. It has tremendous dynamic range. The main deficiency was a lack of blocks and those have since been added.

I've been doing Swift for about six months. I absolutely hate it but the clients are demanding it. It feels like having my wings clipped. Optionals are gratuitous complexity and a horrible way to handle nil. A better update would have been to bind nil to a global object to represent nil and allow the programmer to put whatever object he liked there to either raise errors or ignore them at his discretion.

Smalltalk was the inspiration for the Mac. It brought us test driven development, refactoring tools, a huge number of classic design patterns, and inspired Cocoa. Smalltalk is a tiny language. The entire syntax can be described on an index card. Adding atop C meant that the Objective C book was practically a pamphlet and I learned enough to be productive in a few hours. I mastered it in a week.

Swift's book is 1000+ pages. I've been working in it for six months, and I still struggle with it daily. It is too complicated, too rigid, lacks dynamic features that Cocoa relies on and the bridging to Objective C is awkward at best. Swift is a language only a compiler writer could love.

The global error object is an interesting idea that I never considered before. Sounds like it could get messy in practice (initial impression), but it's a very interesting idea.

It's been years now I think since I was replying in this thread, and I still agree with most of yoir opinions in your final paragraph. Especially the Obj-C bridging... it works, mostly, but it's also pretty awful. I think this will eventually prove itself to have been a misstep.

Finally, did you have a chance to see/read this blogpost?

http://lapcatsoftware.com/articles/whither-swift.html

 

[AxoNeuron]

I love swift but Jesus Christ they have GOT TO STOP CHANGING STUFF for the hell of it! Every time we change from one swift version to another it is absolute hell trying to get all of my projects dependencies to all work together.

I like some changes in Swift 3, but most of the changes seem utterly pointless. Changing NSTimer to Timer, and so on....none of us real programmers give a damn what you call it, just don't CHANGE IT.

Even changing class names and methods would be fine if Swift's autocorrect in Xcode worked more reliably, but it doesn't. It's absolute garbage. With the latest version of Xcode I'm now at a point where Swift autocorrect is broken MORE often than it actually works. I can usually even predict when it's about to break. Every time I do a class check (object is ClassName == true) it breaks autocorrect for 10-20 seconds.

 

[bbohanna]

One thing that I'm having trouble with in swift is the increasing emphasis on pass-by-value versus pass-by-reference, especially in the area of the Collections components.

I believe that Collections (Array, Set, Dictionary) were previously implemented as classes in earlier versions of swift: at swift 3.0 they got "promoted" into a struct implementation.

All base data types and structs use pass-by-value semantics: classes use pass-by-reference. This presents a problem when trying to work with multi-dimensional arrays.

// Suppose I have an indexed array of Dictionaries...
var matrix = Array<Dictionary<Int,String>>()

// If I access one of the dictionaries in order to modify it...

// I do the modification locally...
var column = matrix[0]

// I return the column for someone else to modify... the "matrix-bracket-i-endbracket" junk on the next line
// is because this MacRumors comment editor keeps stripping the [_] off with an i as the subscript...

func getColumn(index: i) -> Dictionary<Int,String> { return matrix-bracket-i-endbracket }

I can't modify the in-situ value because I'm dealing with a copy of the Dictionary at this point
column[3] = "joe" // changes not reflected back in the base matrix

I can do this:

matrix[0][3] = 'joe"

but it doesn't allow for any error checking in the event of missing/out of range indices

I can do this by "unpacking" and "repacking" the Dictionary element within the indexed array, but it seems clunky and inefficient to me.

var column = matrix[0]
column[3] = "joe"
matrix[0] = column

I don't come from Objective-C: my main OO languages are C++ (which lets the programmer decide pass by reference or value explicitly) or Java (where everything is pass by reference). This structification of swift seems to me to be a large step away from using the language as an OO language. Across every assignment or call interface I have to be paying extra special attention whether the thing being assigned is pass by reference or pass by value, a task made doubly hard by the obscured nature of whether a thing in swift is a Class or a Struct. C-

I attempted a workaround by wrapping the Dictionary in a delegation class

class DictDelegator
{
var column: Dictionary<Int,String>()
}

which I could get at with pass-by-reference from the Array

var matrix: Array<DictDelegator>

But this quickly foundered for iteration across the Array, because my DictDelegator didn't implement the Sequence protocol. I tried to remedy this but got wrapped around the axle trying to implement the various Sequence APIs, with errors that made no sense...

 

[PhoneyDeveloper]

Collections have always been structs in swift. I believe that the reason for this is to make certain classes of bugs impossible or unlikely since you're always working with copies. Certain kinds of threading bugs are impossible since each thread will always have its own copy of the struct.

The simple(r) way to do the kind of thing you're talking about is to use the Objective C classes directly, like NSMutableDictionary, which is imported into swift as a class.

 

[AxoNeuron]

Collections have always been structs in swift. I believe that the reason for this is to make certain classes of bugs impossible or unlikely since you're always working with copies. Certain kinds of threading bugs are impossible since each thread will always have its own copy of the struct.

The simple(r) way to do the kind of thing you're talking about is to use the Objective C classes directly, like NSMutableDictionary, which is imported into swift as a class.

I wish Swift had a way to choose pass-by-ref or pass-by-copy worked with collections.

Pass-by-reference is simply easier in my opinion to work with. In my opinion, the threading bugs can be easily avoided, pass-by-copy forces you to do some really ugly things just in order to avoid some rare bugs.

 

[bbohanna]

Thanks for your feedback. My intent was to avoid Objective C, partly to preserve the options to move the code to linux using the open sourced swift compiler.

 

[firewood]

For modifying structs and other complex value types, I believe one way to deal with this in Swift is to use the functional programming concept with immutable data types. e.g. instead of modifying portions your array of dictionaries in place (underneath other classes which may or may not know that their data was mucked with), that your function return a new array of new dictionaries (in a tuple if necessary) that includes all your modified elements. Copy on write should do this.

Then the calling function has the choice to use the changed return value, or not.

 

[SmalltalkFan]

For modifying structs and other complex value types, I believe one way to deal with this in Swift is to use the functional programming concept with immutable data types.

That's pretty dang inconvenient when you are trying to do 2D matrix manipulations.

 

[hiddenmarkov]

I love swift but Jesus Christ they have GOT TO STOP CHANGING STUFF for the hell of it! Every time we change from one swift version to another it is absolute hell trying to get all of my projects dependencies to all work together.

I like some changes in Swift 3, but most of the changes seem utterly pointless. Changing NSTimer to Timer, and so on....none of us real programmers give a damn what you call it, just don't CHANGE IT.

.

This is fun for people learning it too.

We just did a series of classes for mobile development, swift covered ofc for iOS. Issue...class material written heavily in 2.x on xcode 7. the swift 3 and xcode 8 class changes are in development/testing/final edits for release soon by who we used but not out.

Now good thing was our instructor went off script, in a good way, and sometimes and said "now...let me show you how this will work in 3". Did the best he could but only some much time to go off the rails there. source relied on ye old calls of NSxxxx, it worked, run with it.



So you get the fun of deprecation when your home system (and not the providers class setup) is latest and greatest xcode and swift.

Some deprecation notices and/or please choose this correction option in xcode 8 are there but for not fulltime coders they can be cryptic. At least are for me. And its expanded to beyond the class stuff. I ask the all knowing google, to give me ideas. And I go crap....NS here, NS there....

Starting out in this realm I have enough fun without playing version translator. I will make the sad but true joke I am more than capable of making code throw up tons of warnings/error notifications....I don't need the added stuff from deprecation hints to add to this. Really...I don't lol.

 

[firewood]

That's pretty dang inconvenient when you are trying to do 2D matrix manipulations.

If you want convenience, then hide all the 2D structure access complexities inside some struct accessor functions. Then anything that has to work with those arrays won't even have to know that they are arrays of dictionaries (or complex object tree, sparse matrix, unsafe pointer to allocated bytes, notifications to an array API server, or whatever).

 

[nextuser]

If you want convenience, then hide all the 2D structure access complexities inside some struct accessor functions. Then anything that has to work with those arrays won't even have to know that they are arrays of dictionaries (or complex object tree, sparse matrix, unsafe pointer to allocated bytes, notifications to an array API server, or whatever).

Or just use a language that doesn't get in the way of what you want to do.

 

[firewood]

Or just use a language that doesn't get in the way of what you want to do.

You could always code in assembly language (maybe even absolute hex/octal machine code), 100% won't get in the way of anything your current CPU can possibly do. It's a trade-off. Are the various features of the language and its ecosystem (built-in functions, runtime, libraries, frameworks, etc.) worth not being able to do what you could in ASM? And vice versa.

AFAIK, if what you want to do is get hired for certain iOS jobs, being able to jump through hoops to make stuff work in Swift 3 has a decent likelihood of being advantageous, rather than being in your way.

 

[nextuser]

You could always code in assembly language (maybe even absolute hex/octal machine code), 100% won't get in the way of anything your current CPU can possibly do. It's a trade-off. Are the various features of the language and its ecosystem (built-in functions, runtime, libraries, frameworks, etc.) worth not being able to do what you could in ASM? And vice versa.

AFAIK, if what you want to do is get hired for certain iOS jobs, being able to jump through hoops to make stuff work in Swift 3 has a decent likelihood of being advantageous, rather than being in your way.

Swift basically falls into the same family of languages as Java and C#, so in that sense, the various "features" of Swift are not an improvement over Objective-C and in many ways are a downgrade especially for the experienced programmer.

I used to love the iOS platform. With the introduction of Swift, I have moved away from it, so I definitely would not want to get a job as a Swift programmer.

 

[firewood]

Swift 3 is an improvement for me. It has huge advantages over Java and C# in terms of predictable latencies and memory footprint (since it doesn't require garbage collection). The static versus dynamic message dispatch also allows some performance advantages over Objective C for certain types of code. So it allows me to code in one programming language, instead of two languages (Smalltalk and C) stuffed into one code editor.

 

[bjet767]

The static versus dynamic message dispatch also allows some performance advantages over Objective C for certain types of code.

I did some basic google research and it seems the main advantage in speed to Swift is the static nature of its data arrays and anything similar to that. Basically, the compiler, because it knows upfront what the code is doing, can optimize better than with OC.

What I have found is Xcode does a terrible job of mixing OC and Swift code, especially when one tries to add Swift files to an OC written program. I did a lot of experimenting with adding various Swift files to a very simple OC program and found the Swift code has to be very disciplined in how they write the code or else Xcode's integration features just don't recogize the objects and methonds. Essentially the Swift code seems to have to be written in a manner similar to and with OC in mind for oit to work well.

The real issue with Swift is this, sometime in the very near future Apple will have Swift as its main programming language and only provide OC support because of the huge base of code.

PS if you all really want "speed" write a lot of the base code in good old C.

 

[grandM]

One thing that I'm having trouble with in swift is the increasing emphasis on pass-by-value versus pass-by-reference, especially in the area of the Collections components.

I believe that Collections (Array, Set, Dictionary) were previously implemented as classes in earlier versions of swift: at swift 3.0 they got "promoted" into a struct implementation.

All base data types and structs use pass-by-value semantics: classes use pass-by-reference. This presents a problem when trying to work with multi-dimensional arrays.

// Suppose I have an indexed array of Dictionaries...
var matrix = Array<Dictionary<Int,String>>()

// If I access one of the dictionaries in order to modify it...

// I do the modification locally...
var column = matrix[0]

// I return the column for someone else to modify... the "matrix-bracket-i-endbracket" junk on the next line
// is because this MacRumors comment editor keeps stripping the [_] off with an i as the subscript...

func getColumn(index: i) -> Dictionary<Int,String> { return matrix-bracket-i-endbracket }

I can't modify the in-situ value because I'm dealing with a copy of the Dictionary at this point
column[3] = "joe" // changes not reflected back in the base matrix

I can do this:

matrix[0][3] = 'joe"

but it doesn't allow for any error checking in the event of missing/out of range indices

I can do this by "unpacking" and "repacking" the Dictionary element within the indexed array, but it seems clunky and inefficient to me.

var column = matrix[0]
column[3] = "joe"
matrix[0] = column

I don't come from Objective-C: my main OO languages are C++ (which lets the programmer decide pass by reference or value explicitly) or Java (where everything is pass by reference). This structification of swift seems to me to be a large step away from using the language as an OO language. Across every assignment or call interface I have to be paying extra special attention whether the thing being assigned is pass by reference or pass by value, a task made doubly hard by the obscured nature of whether a thing in swift is a Class or a Struct. C-

I attempted a workaround by wrapping the Dictionary in a delegation class

class DictDelegator
{
var column: Dictionary<Int,String>()
}

which I could get at with pass-by-reference from the Array

var matrix: Array<DictDelegator>

But this quickly foundered for iteration across the Array, because my DictDelegator didn't implement the Sequence protocol. I tried to remedy this but got wrapped around the axle trying to implement the various Sequence APIs, with errors that made no sense...

I'm pretty sure apple decided to move onto structures for safety reasons. The cells in a Dictionary were still pointers. This created pretty hazardous situations when copying them. I myself find it a good move to make them structures.

 

[dotnet]

You could always code in assembly language (maybe even absolute hex/octal machine code)

I believe from here on the conversation is supposed to go like this:

Next poster: "Hex? Pfft! We had to enter everything in binary, with toggle switches. Just ones and zeros."
Poster after that: "Ones? You had ones? We only had zeros!"
...
(later): "Electrons? Oh, the luxury! ..."

That said, I believe that compiled languages are necessary, but the pursuit of deranged minds. There is no greater joy than in using interpreted languages. In that vein I reckon that it is a waste of time to learn any language other than Perl.

 

[nextuser]

That said, I believe that compiled languages are necessary, but the pursuit of deranged minds. There is no greater joy than in using interpreted languages. In that vein I reckon that it is a waste of time to learn any language other than Perl.

Perl 5 or Perl 6?

 

[firewood]

PS if you all really want "speed" write a lot of the base code in good old C.

I've been porting some "need-for-speed" base code and computational kernels to Swift 3. Turns out the result compiled from Swift runs just as fast as from C code. (only Neon ASM is faster in some cases.)

 

[dotnet]

Perl 5 or Perl 6?

5

 

[bjet767]

How are you measuring the speed of execution?

Turns out the result compiled from Swift runs just as fast as from C code. (only Neon ASM is faster in some cases.)

Since it seems the need for speed of execution often comes from repetitive tasks I've seen the test of "fast for" loops in OC code compared to the normal counter versions and the "fast" version really was faster accomplishing the very same loop. The reasoning is the compiler and since the whole heart of Swift came from a man whose specialty was compilers, it makes sense these kind of things are optimized in Swift.

If you or I could set a standard for speed what would it be? I would always start with anything the user sees visually. Absolutely minimize wait time when the enter key is pressed or a request is made. My screen IO would be a must and my array search algorithms next. In the good old days of DOS we'd use ASM for writing directly to the screen because C wasn't fast enough. But most seem to think floating point math should be the standard for speed or something else the user never sees.

Oh well rambling on. Swift will eventually rule OS X and iOS for at least 15 years.

The code itself is just that, code and a syntax to do something, but the compiler is where the magic happens. Just think if they had applied they same effort to "optimize" OC. But then the new generation of programmers wouldn't have a process to call their own. It'd be like driving a Buick, "your father's car when all you really want are wheels to call your own.