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

[SmalltalkFan]

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.

Smalltalk solved that problem 36 years ago. They could have moved to full on real Smalltalk. No language has ever felt as expressive or powerful to me as Smalltalk. Objective C was a fair approximation (except for the square bracket madness).

Im finding that Swift forces my attention from the problem domain into the implementation domain a lot. Much attention is now paid to unwrapping optionals and making types "match". Many of the more dynamic features I like and lean on are gradually being phased out in the name of "speed" (really? I haven't had to optimize anything for speed in years) and "safety" (unwrapping a nil optional now terminates your program - why not just attach a bomb to the flaps switch in airplanes that goes off if flaps are deployed at too high an airspeed - that'll make those planes MUCH SAFER!).

I'm definitely starting to move away from Apple in all respects. I'd rather write PHP than Swift.

 

[Mascots]

I think if someone is gonna to rave about the unique conventions of Smalltalk, then it is only fair to allow room for Swift and its implementations.

 

[firewood]

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. ... But most seem to think floating point math should be the standard for speed or something else the user never sees.

What the user sees these days is often the result of an immense amount of numeric-like computation. Machine Learning DNN inferences of what they just said/typed. Game physics models and AI reacting to their last touch. DSP processing of gyro/accelerometer motion and watch heart beat sensor data. etc. etc.
[doublepost=1488657834][/doublepost]

Smalltalk solved that problem 36 years ago.

If the speed of Smalltalk is sufficient for you, then stick to Objective C methods and types. It's interoperable with Swift code. So you can mix and match.

 

[AxoNeuron]

I'm definitely starting to move away from Apple in all respects. I'd rather write PHP than Swift.

Dear god man! I know it's a bit annoying but it cannot possibly be THAT

*stopped writing post due to an improperly unwrapped optional crashing Safari

 

[SmalltalkFan]

sometime in the very near future Apple will have Swift as its main programming language

Won't happen. As it is shaping up, Swift 4 won't have ABI stability either which means still no shared frameworks in Swift for two more years.

It is entirely possible that Apple will bail on Swift or just leave it as a scripting layer atop Objective C.
[doublepost=1488829242][/doublepost]

I think if someone is gonna to rave about the unique conventions of Smalltalk, then it is only fair to allow room for Swift and its implementations.

That's fine as long as they stay away from me. However - clients are all demanding Swift lately. If I mention Swift is a bad choice given their economic means and and time table (Swift takes longer to write, compile and debug - po swiftDictionary can take as much as TEN SECONDS in the debugger vs under a second for an NSDictionary) - I don't get the gig - not because I can't do it - but because they want their bias confirmed. Its like kiss of death to say Swift isn't a good choice for a project. And there ARE projects its not good for.

CoreAudio is C++. Swift isn't great at binding to C++. Objective C++ would be a better choice. But they don't want to hear it.

Now I just say "Swift? Excellent choice, sir! You clearly know what you want. Lets get started".

I might start working on a career with Laravel.

 

[bjet767]

It is entirely possible that Apple will bail on Swift or just leave it as a scripting layer atop Objective C.

I'm ok with that because I code in OC but all the code examples from Apple these days are in Swift.

The success of Swift lies in the compiler's ability to optimize the code and with its designer now at Tesla who knows.

Thanks for the response!

 

[Mascots]

Don't let your dislike warp your vision: Swift will remain with focus, very many people like it, and it's suitable for a wide range of common uses. Maybe not CoreMIDI , but if you have a client knowledgeable enough to prevent you from pulling Objective-C into a project but not knowledgeable enough to know where it clearly would be more efficient, I think communication or the client's ego is the problem. I just have never had that happen in my many years of development on many platforms.

You should stick with the core components and just use Symfony. PHP is actually a very powerful language for what it is - I don't know why you like to snub it!

 

[SmalltalkFan]

>PHP is actually a very powerful language for what it is (and could have been) - I don't know why you like to snub it!

I don't snub it. I like it. It is an excellent dynamic language with some baggage in the standard libraries. Kind of the opposite of Swift. I do all my servers in minimalist PHP. They're usually just glue to a database, redis, or some other service anyhow.

 

[Mascots]

Fair I read it as sarcasm, looks like it wasn't!

 

[firewood]

How are you measuring the speed of execution?

Add a test mode so that the compute kernels or other inner loops run for at least a few seconds. Use Mach timers (accurate to a few microseconds), and save a set of checkpoint time stamps in a numeric array for later logging. Then run the benchmarks on a freshly booted iOS device. Chill the device while idle, and run tests again to check for possible previous CPU clock throttling.

You can also dump the compiled assembly code (both arm64 and x86), and compare Swift and C code compiled at full optimization levels.

Swift works just fine for real-time Core Audio callback blocks and DSP stuff (including real-time wavelets transforms and such), if you know what you're doing.

 

[AxoNeuron]

Don't let your dislike warp your vision: Swift will remain with focus, very many people like it, and it's suitable for a wide range of common uses. Maybe not CoreMIDI , but if you have a client knowledgeable enough to prevent you from pulling Objective-C into a project but not knowledgeable enough to know where it clearly would be more efficient, I think communication or the client's ego is the problem. I just have never had that happen in my many years of development on many platforms.

You should stick with the core components and just use Symfony. PHP is actually a very powerful language for what it is - I don't know why you like to snub it!

Ewwwwww!!!!!

Node.js > everything else > monkeys hammering on a keyboard > PHP.

 

[nextuser]

It is entirely possible that Apple will bail on Swift or just leave it as a scripting layer atop Objective C.

Funny how Objective-C would actually be a better scripting language than Swift. It's trivial to write a thin scripting language on top of Objective-C if you know how the runtime works. It's also trivial to bridge it with JavaScriptCore and use that as your scripting language.

 

[SmalltalkFan]

Funny how Objective-C would actually be a better scripting language than Swift. It's trivial to write a thin scripting language on top of Objective-C if you know how the runtime works. It's also trivial to bridge it with JavaScriptCore and use that as your scripting language.

Yep - FScript has been around for awhile and Objective Smalltalk is a lot closer to what I want as a successor. http://objective.st

 

[firewood]

Objective Smalltalk is a lot closer to what I want as a successor.

Then why don't you use it, if it meets your needs? But, unlike Swift (which has huge 3rd party support, even server-side), Objective Smalltalk hasn't seen much development over the past couple years.

 

[SmalltalkFan]

Then why don't you use it, if it meets your needs? But, unlike Swift (which has huge 3rd party support, even server-side), Objective Smalltalk hasn't seen much development over the past couple years.

Because its just one guy and he has a regular job and it only work interpreted right now. Needs a back end compiler. Regardless, it is a lot close to what one might wish for in a successor to Objective C than Swift (which seems to cost more and take longer than Objective C).

 

[bjet767]

Because its just one guy and he has a regular job and it only work interpreted right now. Needs a back end compiler. Regardless,

So let me get this straight what you are writing is that you want a product which really isn't used in any major API platform.

Keep it, smalltalk, as a hobby and learn a language which will make you some money and these days Swift seems to be the way to go.

Good luck and enjoy!

 

[firewood]

and it only work interpreted right now.

Note that Apple recently has been sending out warning letters regarding iOS apps that are capable of running interpreted code on top of the Objective C run-time. Seems there's some sort of security risk doing that. Yet another reason to use statically-analyzed fully-compiled programming languages, e.g. Swift.

 

[SmalltalkFan]

Note that Apple recently has been sending out warning letters regarding iOS apps that are capable of running interpreted code on top of the Objective C run-time. Seems there's some sort of security risk doing that. Yet another reason to use statically-analyzed fully-compiled programming languages, e.g. Swift.

Except Cocoa is built with a dynamic language in mind and it doesn't work without one. Swift is leaning pretty heavily on the Objective C runtime right now.

Swift's tooling still sucks. In the debugger it takes something like 8 seconds to print a Swift variable. Under a second for Objective C - even if its a large dictionary. Objective C builds in 1/3 the time. Device loads....take forever with Swift because you have to copy the runtime.

Objective C is just the more productive language. I make my name by shipping apps - fast. Swift appears to be pretty ironically named.

As to learning languages that make money - I know several others. Some are fun to work in. Swift is the opposite of fun to work in. I tend to seek work in fun languages...so not Swift. (I have shipped three Swift apps now - every one a colossal PITA).

 

[firewood]

Except Cocoa is built with a dynamic language in mind and it doesn't work without one.

Cocoa and Cocoa Touch work just fine without ever having to touch the Objective C run-time. Most app programmers don't even know that the run-time even exists (or is a nice optimization, dispatching Cocoa methods directly from pure C code without any method signature look-ups). Swift methods marked "final" can do that auto-magically without dropping to low-level C.

 

[SmalltalkFan]

Cocoa and Cocoa Touch work just fine without ever having to touch the Objective C run-time. Most app programmers don't even know that the run-time even exists (or is a nice optimization, dispatching Cocoa methods directly from pure C code without any method signature look-ups). Swift methods marked "final" can do that auto-magically without dropping to low-level C.

The responder chain uses dynamic features to dispatch events. KVO, KVC, storyboards - none of this stuff is possible in pure swift. I've been watching Swift Evolution. Its like the C++ standardization committee all over again. A slow motion train wreck. It repeats and rediscovers all the problems with rigid type systems.

Now they've added Codable - a code generation feature in the compiler. You could also do it with reflection, but when you're a compiler team, you keep crufting stuff onto the compiler. Any time you find code generation looking like the solution - you really need a more dynamic language.

Type safety is overrated and ultimately obstructive when taken too far.

 

[Mascots]

Type safety is overrated and ultimately obstructive when taken too far.

Damn, if Apple only used Smalltalk!

At this point 6 mo later, you're more or less beating a dead horse. Betamax.

 

[SmalltalkFan]

Damn, if Apple only used Smalltalk!

At this point 6 mo later, you're more or less beating a dead horse. Betamax.

Or just put in the effort they've put into lame Swift to make Objective C more smalltalk-like, like - oh that Objective Smalltalk thing http://objective.st

I'm sitting here watching the discussions on Swift Evolution mailing list and its C++'s design errors all over again.

 

[Hagrid]

* Incredibly verbose

Your mixing language vs Framework. UIViewController is not part of the swift language, but part of the Cocoatouch framework, the methods are so long because the API is also shared by ObjC - of which the cocoa and cocoa touch APIs took their style from ( long verbose method names that can be easily understood - the code documents itself ).

The Swift language is actually quite compact, less verbose than Java and definitely ObjectiveC. More similar to say, Python or Ruby.

Personally, I like named parameters - help create more readable code.

--

Structs / Enums / Classes have their own needs - and are very distinct - its a matter of understanding each. Structs are more lightweight than Classes and can be used as a substitute - at the right time. Enums - Apple have made these too flexible IMO - allowing methods. Java allows methods its enums but many frown upon this. Enums are very different from Structs and classes, if your using enums to store data, define behaviour then this is a misuse.

The Structs / Enums / Classes thing is one of the things I hate most about Swift, a close second is optionals - I mean is it really easier to code: if...let, and all the intermediate dot sequences with interspersed optionals e.g. what.the?.hell.does?.this.mean!, then if x== nil .... ?

The Struct/Enum/Class choice seems more error prone that having Classes as the lone way to implement methods. I also don't really understand the bit about more compact and easier to read. Maybe for someone that has come from a scripting background, but for me, mostly a hardware guy, I just don't see it. I "grok" Objective C...don't know that I'll ever "grok" Swift. I'll learn and use it, I just like Objective C more...personal opinion...ymmv

Oh, and what's the deal with removing the ++, --, etc. operators... is it more compact to code index += 1 or index++? It seems to me that the swift camp seems to think that they know what's best for us....

And don't get me started on do...try....catch....ugh

 

[nextuser]

The Structs / Enums / Classes thing is one of the things I hate most about Swift, a close second is optionals - I mean is it really easier to code: if...let, and all the intermediate dot sequences with interspersed optionals e.g. what.the?.hell.does?.this.mean!, then if x== nil .... ?

The Struct/Enum/Class choice seems more error prone that having Classes as the lone way to implement methods. I also don't really understand the bit about more compact and easier to read. Maybe for someone that has come from a scripting background, but for me, mostly a hardware guy, I just don't see it. I "grok" Objective C...don't know that I'll ever "grok" Swift. I'll learn and use it, I just like Objective C more...personal opinion...ymmv

Oh, and what's the deal with removing the ++, --, etc. operators... is it more compact to code index += 1 or index++? It seems to me that the swift camp seems to think that they know what's best for us....

And don't get me started on do...try....catch....ugh

I agree with everything you said.

The thing I hate most about Swift is how people will say that the syntax is clean, you don't need to type semicolons, and there are no weird brackets. Whenever I have to refer to the Cocoa API documentation, I find the Swift syntax to be completely unreadable (especially the underscore for the first parameter)

As an example:

func runAction(_ action : SKAction!)

vs Objective-C:

- (void)runAction: (SKAction *) action

I tend to think that Swift does appeal more to the programmers coming from a scripting background or a managed environment like Java/C# who are not able to program in C effectively (perhaps they would be able to complete a class assignment but they wouldn't be able to write anything complex), whereas Objective-C is more for the low-level types who understand the whole stack.

 

[firewood]

I tend to think that Swift does appeal more to the programmers coming from a scripting background or a managed environment like Java/C# who are not able to program in C effectively (perhaps they would be able to complete a class assignment but they wouldn't be able to write anything complex), whereas Objective-C is more for the low-level types who understand the whole stack.

I think that was one of Apple's design goals, to make Swift more accessible to more wannabe developers, as well as safer for them.

Objective C is a pure superset of C. And C is pretty close to a macro-assembly language for DEC PDP minicomputers and newer processors with RISC architectures. Clearly the lowest level possible without resorting to hand-coding assembler. Thus not easy to learn to a competent level, which would limit Apple's potential audience of new app devs.

I'm currently coding apps in both Swift 3 and Objective C. As far as syntax is concerned, I find Swift to be just slightly cleaner, except when trying to access memory (unsafe raw this and that). Both languages abuse punctuation and formatting, but in different obtuse ways.