Live data from Hacker News

My Swift Dilemma

owensd.io

11–20 of 129 posts

Re: My Swift Dilemma

#11
I felt mostly the same way, until last night.

Last night was one of the few times I touched ObjC in months, since I was starting a project from scratch, it took me a while to recall the precise details of @property syntax.

He's right to say that swift is mostly syntactic sugar. However, as he points out, all we really needed was ObjC with a better syntax.

Also, the debugging tools suck right now. My biggest beef with the language is not removing the return keyword. I was really hoping for a language with that was more OCaml, less C++.

In summary, is it perfect? no. is it an improvement of ObjC? Definitely. are there areas which ObjC shines? a few.

Re: My Swift Dilemma

#12

Great post. I'm not sure if it's because of my Objective-C bias or not but Swift just seems messy to me. Everything from how it's spaced and structured in the editor to how it's read. (Lack of headers, clear separations between data structures, methods..etc). Say what you want about Obj-C but it was damn organized.

You never used a programming language from the Mesa branch did you (1973)?

Re: My Swift Dilemma

#13
I wonder if it really makes sense comparing a language that is less than one year old to others that have decades of improvements and fine tuning behind them .

If there was a perfect language, all of us would be using it: each one is the result of compromises between features, performance, readability, simplicity...

For an argument against an hypothetical ObjC3, just look the unending transition between Python 2 and 3.

Re: My Swift Dilemma

#14

Great post. I'm not sure if it's because of my Objective-C bias or not but Swift just seems messy to me. Everything from how it's spaced and structured in the editor to how it's read. (Lack of headers, clear separations between data structures, methods..etc). Say what you want about Obj-C but it was damn organized.

> Swift just seems messy to me.

You probably mean "unfamiliar".

Give it some time, you'll soon realize how more modern Swift is than Objective C.

Re: My Swift Dilemma

#15
Good rant. I concur with respect to Optionals, but I don't mind the ObjC block syntax that much.

It's a real pain trying to find out what functions are actually applicable to a given value (bad reflection / discoverability / documentation).

My guess is that it will take ≥ 2 yrs until Swift can possibly replace ObjC, and even then only partially. ObjC is still a fully grown C, after all.

Re: My Swift Dilemma

#16
post #13

I wonder if it really makes sense comparing a language that is less than one year old to others that have decades of improvements and fine tuning behind them . If there was a perfect language, all of us would be using it: each one is the result of compromises between features, performance, readability, simplicity... For an argument against an hypothetical ObjC3, just look the unending transition between Python 2 and…

I'm not sure it's right to compare it to the Python versioning issues. Apple can just break old Objective-C code for later versions of iOS/OS X if they wanted to. Also, you can look at the adoption rate of ARC when it was introduced. Pretty much every popular third-party iOS library jumped on to implement it, and those that don't usually are abandoned projects.

Re: My Swift Dilemma

#18
post #3

I'm not sure I understand the point of his post. In all the examples he gives Swift comes with better and more succint syntax plus more safety than Obj-C, and on par with his "Obj-C 3.0" idea. And of course it has tons of other features and flexibility he doesn't delve into. The whole post for me boils down to his "I hate Generics" rant at the end.

My favourite part was the whole "Optionals suck because Obj-C have nil, therefore Obj-C is superior" bit.

Re: My Swift Dilemma

#19

As he predicted, I was with him until his rant about generics. While the example he makes support his point, that's nothing specific to generics but instead to the implementation of generics. For example, he uses the following example as "bad" generics: func reverse (source: C) -> [C.Generator.Element] and the following example as "good" non-generics: func reverse(source: CollectionType) -> CollectionType However, yo…

>> Because it does not actually matter. If an Int gets in my array, it’s because I screwed up and likely had very poor testing around the scenario to begin with.

>The benefits of static typing is that you don't need testing of things like that. The compiler guarantees safety, allowing you to avoid writing test case that are mundane and boring, such as checking that you don't put an Int into a String array.

This is a canard. You hardly ever (within an epsilon of "never") write tests for types. You write tests for values that you expect, which the type-system doesn't guarantee. Those values have types, so those get tested as a side effect without any additional effort.

Re: My Swift Dilemma

#20

As he predicted, I was with him until his rant about generics. While the example he makes support his point, that's nothing specific to generics but instead to the implementation of generics. For example, he uses the following example as "bad" generics: func reverse (source: C) -> [C.Generator.Element] and the following example as "good" non-generics: func reverse(source: CollectionType) -> CollectionType However, yo…

But your clean generic example is different from his. Your example specifies a CollectionType returning another CollectionType with elements of type a. His example specifies a CollectionType where the Index property is a BidirectionalIndexType returning an array of elements of the same type as the CollectionType's elements type. Im not sure about the last part because I dont really know Swift.
Post reply on HN