Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

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

KarlJay said:
Think about a company that had a very complex routine written in C vs Swift if they wanted to port that to something else, Swift would require a rewrite whereas the C might not because of a standard in the language.
Click to expand...

The case for every language, when porting code, especially for a business application, such as web applications. 3rd party libraries for a language may not be available for the language being ported to. Lets say, moving from Java that uses Spring to Python - where Spring is not available, nor is the app server.. So it's not just relating to ANSI standards - a whole host of other issues.

KarlJay said:
In fact, a huge part of my game plan is to write as many core routines as I can. I did this many years ago and was able to develop custom business software faster than anyone else I've ever known. The system I developed for American Express was done from ground zero to complete working system in 1 day and worked without flaw.
Click to expand...

Personally, I'd rather use 3rd party libraries where applicable ( IoC containers, REST frameworks, database framework etc ) and not re-write the wheel myself - as the example above with Spring etc.

Businesses don't switch between languages on a whim so being dependent on a certain library - assuming you've done your research and picked the 'best' to suit the needs is a moot point. Writing such libraries when available 'off the shelf' and often open source ( Free ), yourself is probably not the best direction.. it will be a time sink / very inefficient.

KarlJay said:
Some may only look at themselves and how easy/hard it is for them to read code, but I look at the business of software development and what the customer wants.
Click to expand...

Given the needs of the business comes first - There's a fine balance for producing code quality of code that can be maintained and extended in the future

A good software company will allow time to refactor / improve code when code quality has to be sacrificed for tight deadlines : if this time isn't allotted... future development and maintenance - will take a lot longer... a false economy. saved time in the short term, but it the long term not so much.

KarlJay said:
It's hard to see Swift being a good target to make a core foundation of business routines that I can use across whatever platform the customer has. It's hard to see me saying "drop all your devices and buy new ones" to make my product work.
Click to expand...

At present, the value of Swift is aimed at writing OSX and iOS applications. If your not interested in this, then learn another language and avoid swift until it gains traction outside of the Apple world.

Getting a Swift compiler out there for other operating systems is only the beginning: the developer community needs to get behind the language and create a healthy eco system of 3rd party frameworks and libraries, like what exists for Java, C#, Python et al.
 
Last edited:
  • Like
Reactions: Mascots and xStep
Given that Apple understand the importance of mobile enterprise as a market and that they've worked a deal with IBM in order to offer more mobile enterprise solutions, it would seem that they would have considered that in the making of the new language.

I wonder how much legacy enterprise code IBM has that's written in Swift. I'd imagine most of the legacy enterprise routines have been written in C/C++ and Java. Back in the old days, there was a push towards putting business rules on servers. I forget what they called it, but code reuse was a big issue and business logic being written in a language that could be moved to other platforms was a big advantage.

I remember when I worked on the Electronic Art project. They had data that had to be imported from their systems into our system. It was a slow batch type process and had to be done because the code wouldn't run on the shipping system.

I worked for a medical device maker that went with Pascal and had many years into a system that never worked. I was hired to write a new system from scratch because their code wouldn't run on the new platform.

Having business source code written in a language that can be moved from one platform to another is big advantage. Dumping current code written in one language, learning a new language and starting all over just doesn't seem like a good idea.

Maybe it help new people to understand that a parameter is by ref or by val, but I don't see that as an advantage over making something work with established code bases.

Maybe Swift can do things that ObjC or C++ can't, I don't know yet, but so far I can't see where ObjC or C++ couldn't get the job done and keep the advantage of using a known language, legacy code, or tons of good programmers.
 
  • Like
Reactions: Stella
PhoneyDeveloper said:
Just FYI, AFAICT IBM has jumped on swift in a big way. As a few data points

a search for 'swift' on the IBM DeveloperWorks site yields 12,200 results
https://www.ibm.com/search/csass/search/?q=swift&sn=dw&lang=en&cc=US&en=utf&hpp=20&dws=dw

Sample code on github
https://github.com/IBM-Bluemix/hear-the-buzz/tree/master/client/hear-the-buzz

http://ibm.github.io
http://www.ibm.com/developerworks/library/mo-bluemix-swift-app/index.html

I think IBM likes swift.
Click to expand...

I took a quick look, it's good that and old school company like IBM is seeing mobile as a viable platform. Without digging too deep, it looked like a storage and interface routines to their system which is good for them, we need all the choices we can get in this newer market in order to keep prices low and selection high.

I actually hope some large companies offer more APIs that allow for more advanced mobile enterprise solutions.
 
Digging deeper, it does look like they've greatly improved string handling. So maybe the good will outweigh the bad.
 
Here's my issue with Swift.

Just... Why? At its core, it's just NeXTStep anyway, so why even design it? To attract more people to Apple development? We have a ton of developers already.

All this did was divide up all the information online. Want to use some new iOS 9 map feature at work? Half the people writing tutorials use "Swift" because it's the new hipster language and at your work, your one year developed project is written in Objective-C.

We didn't really need a new language. Just give us more in the currently available toolkit. And type casting was an issue for ****** developers in Objective-C just as much as it is in Swift. Having optionals doesn't really change the fact that you should know what your server is giving you. If I know I'm supposed to get an unsigned integer or long or strings, I should be able to know that before I deploy.

Now, what we have is some horribly detached and separated gulf of new projects written in Swift, companies hiring employees to work in Objective-C, pretentious armchair engineers claiming "it doesn't matter, if you know how to code you will be able to use both" (which is totally true but not relevant for full-time developers considering the time to learn gets factored into your billable hours) and not a lot of public information about the features as they were implemented in Objective-C where almost the entire industry is still deploying their projects.

Objective-C will be around for at least 2~3 years from now, so all we did with Swift was just make everyone's lives more difficult. And for what? A pretty "looking" language apparently.
 
Essenar said:
Here's my issue with Swift.

Just... Why? At its core, it's just NeXTStep anyway, so why even design it? To attract more people to Apple development? We have a ton of developers already.

All this did was divide up all the information online. Want to use some new iOS 9 map feature at work? Half the people writing tutorials use "Swift" because it's the new hipster language and at your work, your one year developed project is written in Objective-C.

We didn't really need a new language. Just give us more in the currently available toolkit. And type casting was an issue for ****** developers in Objective-C just as much as it is in Swift. Having optionals doesn't really change the fact that you should know what your server is giving you. If I know I'm supposed to get an unsigned integer or long or strings, I should be able to know that before I deploy.

Now, what we have is some horribly detached and separated gulf of new projects written in Swift, companies hiring employees to work in Objective-C, pretentious armchair engineers claiming "it doesn't matter, if you know how to code you will be able to use both" (which is totally true but not relevant for full-time developers considering the time to learn gets factored into your billable hours) and not a lot of public information about the features as they were implemented in Objective-C where almost the entire industry is still deploying their projects.

Objective-C will be around for at least 2~3 years from now, so all we did with Swift was just make everyone's lives more difficult. And for what? A pretty "looking" language apparently.
Click to expand...
+1. I'm concerned about Apple dropping upgrades for ObjC. I notices a few of them just by watching some of the WWDC2015. This is the part that going to suck. I like the playground, module optimizing, etc. The size of the Swift app is supposed to be 3X that of the ObjC app. This is a big issue considering limited and expensive storage as well as download time.

At this point, I'm still going thru the tutorials, but some things look good, some don't.
 
xStep said:
What specifically did you notice? Apple has been upgrading ObjC since introducing Swift.
Click to expand...
I haven't gone thru the whole thing yet, but Swift can tell which routines are compatible with a given OS at compile time. Playground, module optimizing, new string syntax, app download slicing, just to name a few. Not to mention that the examples seem to be mostly in Swift.

I'm still going thru all the documents, but it's looking clear that Apple wants ObjC to die off.
 
As for me, of course I have a few hiccups with Swift, but overall, this is light-years ahead of the crappy Objective-C. It's meant to be quick, lightweight, yet infinitely versatile.

Stella said:
Some features of Swift or good, but others I'm wondering - why? Such as optionality / unpacking - ? and !
Click to expand...

Optionality is basically a visual helper for you to detect quickly and easily whether the variable can be nil or not.
Thus, you can detect easily if the use of a variable can crash your app.

If you just use :
if variable != nil {
// code
}

You'll miss a lot of crash opportunities, because writing such code is human-based. Swift reminds you robotically everywhere in your code, so no chance to forget.
 
KarlJay said:
I haven't gone thru the whole thing yet, but Swift can tell which routines are compatible with a given OS at compile time. Playground, module optimizing, new string syntax, app download slicing, just to name a few. Not to mention that the examples seem to be mostly in Swift.

I'm still going thru all the documents, but it's looking clear that Apple wants ObjC to die off.
Click to expand...

Sure, compile time error notification via if #available() is handy, but Objective-C already has acceptable runtime checks. The single #available check is nicer compared to the several options in ObjC.

RE: Module Optimization
I wonder how that compares to Objective-C’s “Fastest/Aggressive Optimizations”?

I couldn’t find any mention that Objective-C projects are excluded from app thinning and slicing. I did a quick search in the WWDC 404 session transcript. Other searches did not find such a distinction.

A third party has made: Playgrounds for Objective C

Sure new sample code is in Swift. Apple is promoting the new language. I'm not sure that Apple wants ObjC to die off as much as they want better run time results. It's irrelevant anyway. I think Apple will be forced to support ObjC due to their heavy internal use and the large library of external code of third party developers. It will be some time until ObjC sees its end of days.
 
PsykX said:
As for me, of course I have a few hiccups with Swift, but overall, this is light-years ahead of the crappy Objective-C. It's meant to be quick, lightweight, yet infinitely versatile.



Optionality is basically a visual helper for you to detect quickly and easily whether the variable can be nil or not.
Thus, you can detect easily if the use of a variable can crash your app.

If you just use :
if variable != nil {
// code
}

You'll miss a lot of crash opportunities, because writing such code is human-based. Swift reminds you robotically everywhere in your code, so no chance to forget.
Click to expand...
We do that all the time in Objective-C.

if (self.string) {
// code
}

Or even
if (self.string != nil) {

}
 
Essenar said:
We do that all the time in Objective-C.

if (self.string) {
// code
}

Or even
if (self.string != nil) {

}
Click to expand...

This is useful only if nil is an invalid pointer.. But in embedded systems without an MMU (and even Macs before System 7), this may or may not be true. There may be functional memory or a memory mapped IO register at address zero. That could be why Swift does not confuse a nil pointer with an invalid pointer.
 
It looks like I haven't gotten to that point in Swift yet, but I'd say that Apple could have added that functionality to ObjC. That's one of the points that concern me is that many of the better things in Swift could have been added to ObjC.

Look at ObjC over the last few years. Strings, Arrays, ARC, etc... Is Apple going to stop advancing ObjC?
 
KarlJay said:
It looks like I haven't gotten to that point in Swift yet, but I'd say that Apple could have added that functionality to ObjC. That's one of the points that concern me is that many of the better things in Swift could have been added to ObjC.

Look at ObjC over the last few years. Strings, Arrays, ARC, etc... Is Apple going to stop advancing ObjC?
Click to expand...
One of the constraints when adding things to Objective-C lies in remaining a strict superset of C. If that disappears, for either syntactic or semantic reasons, then there's no way to tell how much code would break. And breaking existing code is a big no-no.
 
chown33 said:
One of the constraints when adding things to Objective-C lies in remaining a strict superset of C. If that disappears, for either syntactic or semantic reasons, then there's no way to tell how much code would break. And breaking existing code is a big no-no.
Click to expand...

If I'm not mistaken, Swift allows for "+" to add two strings. Couldn't that be added to ObjC? Looks pretty close to what I remember C++ had (Operator overloading, IIRC).

let string1 = "hello"
let string2 = " there"
var welcome = string1 + string2

Haven't fully dug into how Swift treats this, but looks like it's an object, maybe with a class you can modify or subclass.

Why is this not a part of ObjC?
 
firewood said:
It is. String literals are pointers. Adding 2 global pointers will usually point to some nonsensical part of memory. Thus useless.
Click to expand...
Ok, it's been a while since I studied C++, but can't you use operator overload to add two strings using that syntax?

So Swift is changing the way C works, as C would see two pointers and add the two pointers vs Swift would look at what the pointers point to and see two string and add two strings.
 
They could have done it, but didn't, because Swift is new and shiny and Objective-C is old and not as shiny anymore.

I will say my favorite part of Objective-C was the C. I liked having inline C in my source files. In my opinion that is the biggest pain with Swift. You can still use C using bridge files but...what a pain. Especially if you really need to mix quite a bit of your code with C.
 
AxoNeuron said:
They could have done it, but didn't, because Swift is new and shiny and Objective-C is old and not as shiny anymore.

I will say my favorite part of Objective-C was the C. I liked having inline C in my source files. In my opinion that is the biggest pain with Swift. You can still use C using bridge files but...what a pain. Especially if you really need to mix quite a bit of your code with C.
Click to expand...

Wow, I haven't gotten to the bridge files yet, but it sounds like it sucks. I'm confused as to why C would be removed from Swift. It looks like it has some C base in it and I thought it still used the ObjC runtime. In fact, that's odd that Swift would have the ObjC runtime and NOT have C inline.

I don't know yet, but I'm guessing these bridge files have a performance hit, which would defeat one of the reasons for doing inline C.

This is looking more like a mess with only a few bright spots.
 
KarlJay said:
Ok, it's been a while since I studied C++, but can't you use operator overload to add two strings using that syntax?
Click to expand...
C is not C++. They're two separate things. Related, but distinct.

So Swift is changing the way C works, as C would see two pointers and add the two pointers vs Swift would look at what the pointers point to and see two string and add two strings.
Click to expand...

No, Swift is not "changing the way C works". Swift is a separate language with effectively no syntactic compatibility. They're similar, but they lack a subset/superset relationship. Just as C++ is a separate language from C, although it has some compatibility.

You wrote before that "I'd say that Apple could have added that functionality to ObjC." I wrote that they couldn't do it without breaking C compatibility. Apple could have added functionality to ObjC++, but that isn't what you wrote, and many things in the syntax still would have broken compatibility with ObjC++ or C++.

You seem to be confusing C and C++ as a single thing. They're two distinct languages.
 
chown33 said:
C is not C++. They're two separate things. Related, but distinct.



No, Swift is not "changing the way C works". Swift is a separate language with effectively no syntactic compatibility. They're similar, but they lack a subset/superset relationship. Just as C++ is a separate language from C, although it has some compatibility.

You wrote before that "I'd say that Apple could have added that functionality to ObjC." I wrote that they couldn't do it without breaking C compatibility. Apple could have added functionality to ObjC++, but that isn't what you wrote, and many things in the syntax still would have broken compatibility with ObjC++ or C++.

You seem to be confusing C and C++ as a single thing. They're two distinct languages.
Click to expand...

C goes back many years, C++ was quite a while after that, then Java and C# for a while and haven't used them in quite a while, so yea, no doubt I'd be rusty.

TBH, I don't mind all that much the different languages, it's just syntax to me. It would be nice to have them use similar syntax. I found ObjC odd at 1st too, so maybe I just need to give Swift a good run and maybe I'll like it more later.

Maybe Apple has a really great master plan that I'm not seeing yet :D
 
Essenar said:
We do that all the time in Objective-C.

if (self.string) {
// code
}

Or even
if (self.string != nil) {

}
Click to expand...

Yeah, I did that too, but you can forget about a conditional statement.
When converting to Swift, I realized I forgot a lot of them.
 
The other problem is that you're introducing a new language, with performance advantages, to a large wealth of developers who will either immediately embrace it, plan for learning it in the future, or take a defensive stance on hating it.

My coworker hates it and never wants to use it. And he's a huge barricade when I try to present a refactoring sprint in the future. I want to refactor to Swift, he wants us to tighten up Objective-C and refactor that way.

Either way we need to refactor so I'm just going to stick with Objective-C, but we're gonna fall behind the times, I'm sure of it. So I'm going to have to learn Swift on my own time.

other platforms aren't facing this same huge syntax/language re learning process.
 
Essenar said:
The other problem is that you're introducing a new language, with performance advantages, to a large wealth of developers who will either immediately embrace it, plan for learning it in the future, or take a defensive stance on hating it.

My coworker hates it and never wants to use it. And he's a huge barricade when I try to present a refactoring sprint in the future. I want to refactor to Swift, he wants us to tighten up Objective-C and refactor that way.

Either way we need to refactor so I'm just going to stick with Objective-C, but we're gonna fall behind the times, I'm sure of it. So I'm going to have to learn Swift on my own time.

other platforms aren't facing this same huge syntax/language re learning process.
Click to expand...

Interesting that you say you'll have to learn Swift on your own time. Shouldn't the company that pays you for your service, pay you to learn the new stuff if they are going to use it? I worked at a company that did and another that didn't. The one that didn't ended up looking to hire someone else to take on new projects in new platforms instead of training the current employees.

If a company brought in a new software system, wouldn't they retrain the employees? Why wouldn't they retrain the employees for a new language?

The real issue here is the Apple sells an ecosystem to companies. Apple changed things by introducing a new language as a part of it's ecosystem. This puts its customers in a position where they have to pay for the cost of the change. It's up to Apple to consider the cost of this change.

Swift shouldn't be considered any different from an upgrade to hardware or OS, if the customers don't like it or if the cost is too high, they might switch. That would reflect on Apple thinking about the effect on their customers before they introduce something to their ecosystem.

I don't see it much different that when Windows took their path on mobile solutions, they lost market share and paid the price. Same with BlackBerry, they lost mobile market share because of how they handled things. --- Not to say Swift is that drastic, but it's still a change that causes a cost to companies that develop using Apple's ecosystem.

BTW, I'm starting to like Swift now. The more I dig in, the more I'm starting to like it. Now I'm concerned about leaving ObjC behind and maybe getting a job that uses ObjC and me being the odd-man out :D
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back