What party is it you belong to that is AGAINST letting people have free will and the ability to work without TWO management chains overseeing what they do?

Sign me up for THAT party - said no-one, ever.

What's this have to do with unions? Do non-union industries have some mystical property that makes hiring-managers inherently non-petty?

They are of course just as petty, being the same people that would exist in both systems - but are not nearly as wired into each other as union leadership has traditionally been across companies.

I should have figured it would be going strong, it was a rough system to get used to but ran very solidly. Glad to see that's not something HP has killed.

Yea, cause that is totally how unions work.

Reply modeled after real world examples, including Teachers Unions.

If you don't think any group with power over workers prevents "troublesome" workers from finding work, you are simply naive.

nice anti-workers rhetoric

What could be more pro-worker than protecting workers from predation? Being anti-union is inherantly being for the workers, not the overseers.

I forgot to add the third aspect of "after union" - you make 20% less pay and your union leader lives in a mansion.

are you just a temporarily embarrassed millionaire?

A) Never be ashamed at having a strong opinion.

B) Not even close to a millionaire, temporary or otherwise. I work for a living thank you very much.

I had some opportunity to work with HP-UX (built GnuMake on it for a in-company build/QA system), it was always an interesting and very different beast. Is it still around in any form?

Result before unions:

Sometimes programmers hired on death marches, feel free to leave and find better work.

Result after unions:

All programming now inherently a death march because unskilled "coders" most senior members of any team, cannot be fired and also direct architecture.

Leaving a job where the petty minded rulers feel like you slighted them means you will never work as a coder again because other union shops are told not to work with you.

And after one year, you have to fork out another $100 to Apple

Even a cheap Android tablet that's realistically useful for dev is $200+, and it's certainly not going to be useful for dev after two years. So that's at best a wash.

But AGAIN, you don't have to pay $100 until you have a shippable app, not true with the state of Android emulation.

The majority of app store devs fail to make a profit, the top half of 1% make 99% of the revenue, the gold rush is now over.

The easy money is over, but what you say is even worse on Android.

Android sales have totally outstripped iOS sales for a while

A "fact" which is obtained by counting devices shipped instead of sold, devices that no-one would ever buy apps for... the real figure is far worse which is why iOS-first development is still true for every major mobile app company, and some companies to this day have dropped Android development (Luma).

You are a hopeless AnFan.

He is not you. He is not me. His needs are different

Yes they are, so why mislead him to ruin? That doesn't seem very kind.

Java, on the other hand, is everywhere.

Everywhere on legacy development projects. As I said I was a Java developer for over a decade, but there's no way I'd recommend it as a first language now.

Bullshit. In my city the rates are $2.25 a mile.

And there is no minimum fee? And there is no fee that is time based rather than distance based (because after all going a mile in Vegas in dense traffic is going to take a while).

Sounds like you just don't know taxis well at all, not to mention with your ACness you may even be a taxi driver yourself trying to con the next mark...

Operator overloading is, IMO, almost inherently a mistake. And tuples are pure syntactic sugar.

  don't like operator overloading either but you can't just hand wave t away as syntax sugar because you don't like it.

Also tuples are way beyond what I consider syntax sugaring as they replace quite a lot of parameter nonsense and lots of extra method definitions because of elements being optional.

The entire networking stack has no Swift documentation except for a very trivial NSURLSession example.

NSURLConnection seems to have full Swift documentation (though it doesn't show up by default under all for some reason).

Or you could just use one of the countless online examples of networking with Swift, even the AlamoFire library written by the same guy that did AFNetworking...

The conceptual docs for pretty much every technology area, for starters. You can say all you want to that the language doesn't matter in conceptual docs, but IMO, that's not the case if you truly don't know any Objective-C

I still disagree with that but even if it were so you can find any conceptual based thing you want online now from other sources that is very Swift specific. In particular Ray Wenderlich and company have been really prolific in churning out Swift guides for all kinds of topics.

you have to admit that Apple has a long history of coming up with what seems like revolutionary improvements in technology, and then dropping them a couple of years laterâ"Objective-C Garbage Collection, for example.

GC on ObjC was never revolutionary, it was added on because everyone else had it - ARC was a much better idea, and they aren't dropping that. I don't see a history of Apple dropping much of anything as all other frameworks and technologies they've developed have pretty much stayed and evolved. Can you provide any other example, because I con't think of any that I was using that ever got dropped... hell, even iCloud document support which has historically had a ton of issues is still there, evolving and iterating...

I won't be using it for any nontrivial code until I'm sure it is going to stick..

The canaries on that one are already deep inside and chirping loudly still. Anyone who is not switching to Swift now as rapidly as they can is going to be behind the curve in terms of modern iOS development.

In case you haven't heard, decent android tablets are going dirt cheap

Which, to be clear, is still going to be more than the $100 the dev program costs.

Cheap is relative... I can claim the dev program is dirt cheap also (which it is), and as I said you don't have to spend ANYTHING until you have an app you want on the store.

Several of my friends who were in similar situations after grad school have done so and are making a healthy living getting contract work.

Which means they learned iOS development, not Java generally.

However, IT has its own craziness - just look at the ongoing misogamy

Some of my best co-workers have also been women - leave California if you've been subject to mysogny at work. It's not IT, it's specific areas of the country...

The poster asked for specific advice.

Yes he did, and your response gave him terrible advice.

iOS is just iOS. There's a big world out there,

And most of it is working with iOS first, Android secondarily.

If you want a job learn iOS. If you are just messing around, Android is fine for hacking.

And since he already has 2 friends who are into iOS development, maybe they won't mind if he makes Android

Since he has two resources that can help him learn what he is doing (AND can help him find work), he would have to be an idiot to follow your crazy notion to learn Android. Why, just for the sake of some nobel "platform diversity"? You said it yourself, he wants real work. Obviously in his situation learning iOS is the quickest and most realistic path to that, not some Android fantasyland where he learns the platform because it has "more devices" even though 80% of those devices suck at running apps.

If he had a couple of years, my answer might be different

Ask me how I can tell it would not be - you are simply not a realistic person, and frankly I find it unethical to toy with a person's life as you are simply because you are an Android booster.

If he had said he knew Java, if he had said his friends knew Android, my answer would have been different regardless of timeframe. But it's pretty clear from the question not only does he want to learn iOS development but it's simply the best path for him.

He simply doesn't have the time to become "good enough" in both Swift (a changing target) and Obj-C

You only need one and Swift is not changing much past this point (that was the point of the general release, or did you not know that?)

he needs to be flexible enough so that he isn't locked into just mobile development,

thought you said he didn't have enough time to learn two things, how your tune changes as you dance...

He NEEDS to focus on one thing and do it well, if he wants to find a job. Plenty of time after that to branch out. However he doesn't NEED to because mobile development will be quite a good field for many years to come, and is absolutely the best field for a newcomer to start in as it offers way more job mobility and satisfaction than traditional IT development (where I spent over a decade).

An interesting summary, but you should really group Swift with Python/Ruby in terms of what you get from learning it from a pure language standpoint.

I totally agree with the sentiment it's better to know a number of languages...

No one's going to run a high availability web server, database or number-cruncher on a mobile.

Yes in fact they do. In fact if you stopped to think about it, all aspects of mobile computing correlate strongly to "high availability" concepts because the user wants an application that works fluidly, with as little delay or error as possible, and because it's a small portable device always with them, is less tolerant of said delay/error than with a desktop where we are all used to applications being slow at times.

Also of course, many mobile apps are simply arms of a larger system that is considered a high availability system, so the applications by default fall under that umbrella.

I've worked on mobile applications that have very large datasets, or a tremendous amount of processing of data from a server... it's not that uncommon.

Lag due to an algorithmic choice would be an even more unlikely occurrence

You are SO naive. That is in fact a HUGE problem for new developers on mobile platforms, something I have helped correct for many times, making a HUGE difference in how an application responds to the user. Any number of times it has been the difference between a feature even being possible on a mobile device.

A programmer will always be better with a solid grounding in CS, obviously; but your argument is misdirected.

Sorry if I only speak with several years of real world mobile development behind me, including some J2ME work in the past...

one of the advantages of Android that I haven't seen anyone mention is that you don't need to know C or C++ or ObjectiveC/ObjectionableC. Just a subset of Java

I was a Java developer for around a decade. Now I've been doing iOS development full time for several years, most with ObjC and recently in Swift.

The thing is, from a language standpoint all of those are comparable in terms of effort to learn - so if he doesn't know Java it's no harder to pick up ObjC over Java, or Swift over Java (and Swift has the advantage of being a lot lees verbose than the Java or ObjC, while still maintaining the good descriptive aspects of ObjC [named arguments]).

The real effort is in learning the frameworks for whatever system you are developing for, Java was actually the first platform I know of where that mattered more than the language because the frameworks were extensive - but so are the iOS frameworks.

As a bonus, you can develop for free on any laptop.

You can with iOS/Swift also, the simulator is very good and you could realistically write an entire app ready to ship to the store then pay for a dev license only when you felt you had something worth using.

What you gloss over is that with Android development you often NEED to have a device to develop, because the Android simulators are so poor/slow. If he doesn't already have an Android device where is that $100 advantage? Gone, and more than gone because to buy a reasonable test device (or several test devices which is more realistic) is going to cost way more than $100... I have an Android device I bought when abroad for around 70 EU, that is utterly worthless for development or even running apps.

Maybe you'll decide that, until you get that sorted out, you want to take a (probably low-paying, but with your degree, who knows where that will lead) job at some humanitarian organization

Which will have even worse politics going on than in a normal company, and probably be very draining for the soul... those are the kinds of places you want to volunteer for, not work for. They will eat you up rather than giving you the uplifting you speak of. Have you really worked for one or does it just seem like a good idea?

you don't have to worry too much about this

iOS developers have not had to worry about THAT because we have THIS.

Which is Infinitely better than having to research the dreaded other thing because your app just locks up at times...

Seriously, have not had to look for leaks in years.

it will give you the basics of OOP

Swift will give you the basics of OOP *and* functional programming, which is far more valuable going forward. And it's much more interactive since you can use Playgrounds to explore.

The demand for Java developers is either for people who know the Android frameworks really well, or incredibly seasoned IT developers with years of service experience. A few weeks of learning Java will be of little use in finding a job anywhere.

That was the part that Swift had shortcomings.

So a bit like RestKit (which I hate BTW, though not because of what you are trying to do), it doesn't seem like that should have been more code in Swift.

RestKit itself is a massive bloated thing, which would be way easier to have a lean version of written in Swift..

About them enums, I'm saying that havng to use a specific toRaw() to access the value is effin idiotic

It's not because mostly you are using the symbolic values from the enums - it's handy to also be able to attach a "real" value to them as well, and not as used.

Wether your code is small and modular doesn't change the fact that you are still sending out entire source code out

You aren't though if that module is it it's own framework. Then all that is visible is the headers - just like you can see Swift headers for all the iOS frameworks, not the internals.

The Obj-C mangled names was in the documentation and WWDC presentation

That is REALLY out of date, but even immediately after WWDC I was using mixed Swift/ObjC and never had to use mangled class names for anything. That's the point of the generated Swift bridging header, which was there from the start...

And yes, code size was bigger in swift. Despite having 2/3 the number of files that the Obj-C version had

I really think that had more to being new with the language and not knowing how to use it efficiently, along with of course improvements made to the language in the intervening months...

Given the syntax is inherently shorter for Swift even if all you did was port Objective-C code into swift it should be shorter though. I'd be curious to know what aspects exactly caused the code to blow up beyond the natural compression.

No header files confuscate passed-on intended usage by exposing ALL class details rather than the intended consumable APIs.

Which is OK within the same app, especially since you can mark methods as private now.

Visibility is limited to what you can use when using a framework written in swift, you get what is essentially an automatic header view.

The idea is to write more small frameworks for more modularity.

Real-world test code being written showed you end up peppering your code with ? and ! symbols.

Not as true since the iOS frameworks were re-worked to indicate properly to Swift when something is an optional or not. The choice to use an optional should be a thoughtful one in your own code.

var view: NSView = anyObject as NSView

What's wrong with being explicit in casting? You had to do that a lot in ObjC also ( NSView view = (NSView *)myObject ) only now without the pointer syntax... as the tested casting is a much nicer concept since it fails gracefully if wrong, instead of just proceeding and crashing.

Your code end up having full of "as othertype" in it.

No, it really hasn't, not in real use.

Integration with existing code: Obj-C require Swift mangled name

Don't know where you got that, but just no. I've worked with mixed Swift/ObjC code, there is no need to use the mangled name - that has not come up in any way for real use.

String-types enums are a major fubar

Oh no, you have to call toRaw()? Never mind that in ObjC enums can ONLY be integers, not strings at all, which means you have to write a whole method somewhere to translate those ints into strings if you want an enum of strings, and also figure out where that method belongs... enums in Swift are a HUGE advancement.

The localized strings would thus expose the structure layout

Now that's just plain silly given that format strings in ObjC are simply passed the various objects in the call to format, and structure discerned from those pass parameters every bit as easily.

In fact what is REALLY silly is that ObjC is way more hackable, since it's all message passing... Swift takes that aspect away unless you re-enable it with things you mentioned like explicitly enabling KVC for methods.

I created a REST/JSON multi-threaded transaction framework with full JSON object parsing through an object factory that returned fully instantiated objects

That's interesting but sounds dubious since all of the JSON parsing Swift code I've seen is really compact, and I've been dealign with a lot of REST/JSON code in a production app myself, using swift. It's smaller. I've not measured speed but it's not much slower, if any.

Of course is real life you are just using NSJSONSerializer, right? Right?

That test framework was built with a multi-programmer, globally-spread coding team such as what I have to deal with at the office

I have to deal with the same stuff all the time, I'm a full time iOS consultant who has worked with a number of very large teams. I like the idea of a more modular app with more internal frameworks myself, it will REALLY help in a case like that.

I really think you are greatly mistaken about swift, you should use it in real development and not just a test case. Swift has already seen a lot of advancement and uptake...