4 ms·

Honesty, if you use Swift as just a 'Better Objective-C', then it isn't that much better. However, if you abandon the Java/Objective-C style of one file per cl

by gress 12y ago

Honesty, if you use Swift as just a 'Better Objective-C', then it isn't that much better. However, if you abandon the Java/Objective-C style of one file per class, traditional OO, and instead program as if it were lisp, using a file per 'topic' to build up solutions out of func and structs and iteratively develop protocols and classes as needed to integrate with the UI, you will find that it is a much superior language to Obj-C. The OP is certainly doing it wrong with his air coding approach - which makes sense in objective-c, where the building blocks are so heavy, but with Swift you can just get something simple working, and then iteratively refactor, with the type system acting as your support for correctness. If there is a problem with Swift it is that knowledge of Objective-C doesn't provide any real clue as to how to use Swift effectively. For me that knowledge came from having also built shipping products using Clojure, Scala, and Ruby. Tldr; If you program Swift as if it were obj-c, you will be disappointed. It takes a different style to get any real leverage from it.

Roboprog 12y ago
I like it! Free your mind (from OO tyranny). Sometimes, data is just stupid, and doesn't deserve anything more than an associative array between plucking it from the DB and casting it off as some JSON. Writing a bunch of do-nothing classes and then bitching about deserializing and reserializing them seems like folly to me. Classes make sense when you use polymorphism and have a set of behaviors clumped together and multiple implementations. If it's just one call with multiple strategies, use a function call with a defined signature (func pointer type, delegate, whatever). If the "class" is nothing but magic bean "[sg]et-foo; [sg]et-bar; [sg]et-blah; ..." (with no validations, calculations or any other kind of value added), why are you writing it? (and why do I have to read it?) Use a struct/record/tuple if there is a lot of code that might typo the property names, or just an associative array if the usage is an automated pass-through with little to no looking inside. Some parts of an app benefit much more from functional composition than a big bunch of make-work objects that make a loud clunk when you whack 'em with a stick.
- gress 12y ago
  Exactly. And the swift designers realize this which is why they added these language features.

by gress 12y ago

Roboprog 12y ago

I like it! Free your mind (from OO tyranny). Sometimes, data is just stupid, and doesn't deserve anything more than an associative array between plucking it from the DB and casting it off as some JSON. Writing a bunch of do-nothing classes and then bitching about deserializing and reserializing them seems like folly to me. Classes make sense when you use polymorphism and have a set of behaviors clumped together and multiple implementations. If it's just one call with multiple strategies, use a function call with a defined signature (func pointer type, delegate, whatever). If the "class" is nothing but magic bean "[sg]et-foo; [sg]et-bar; [sg]et-blah; ..." (with no validations, calculations or any other kind of value added), why are you writing it? (and why do I have to read it?) Use a struct/record/tuple if there is a lot of code that might typo the property names, or just an associative array if the usage is an automated pass-through with little to no looking inside. Some parts of an app benefit much more from functional composition than a big bunch of make-work objects that make a loud clunk when you whack 'em with a stick.

gress 12y ago
Exactly. And the swift designers realize this which is why they added these language features.