Live data from Hacker News

My Swift Dilemma

owensd.io

41–50 of 129 posts

Re: My Swift Dilemma

#41

when I first saw Golang, I hated it, but now I think it's the best server side language. Galang is an insanely pragmatic language. It's not fancy, just works. Facing Swift, I had mixed feelings. It's a beautiful language, probably as pretty as Ruby, but what really makes it unique, or extremely productive? I can't find any. Am I the only one agrees with the author that generics probably do more harm than good. I'd ar…

> Am I the only one agrees with the author that generics probably do more harm than good It's really the same debate as 'Dynamic' vs 'Static' languages, since without generics your code is relying on runtime type checking in anything remotely complex, thus is effectively a dynamic language. Personally, I'm of the opinion that people that don't like static typing only feel that way because they've only used the shitty…

I do agree with your points, but i think you've over generalised them into a degree that discussion is not only unnecessary but also childish.

Let's restore the context back to Swift in iOS programming to match its targeting market, shall we? Could you come up with 1 use case which: .. generic is really useful. .. the problem hasn't solved by well recognised 3rd party lib/framework.(by "well recognized" i mean github starred or forked more than 500.) .. should be used in 10% of the top 100 apps on Appstore.

Re: My Swift Dilemma

#42

Earlier quoted context omitted.

OK, I see your point. Of course, the type system will not substitute this kind of tests. But it allows you to check the whole range of values. This is helpful if you e.g. wanted to handle overflows, wanted to limit the operands to positive numbers, etc.

Not only will the type-system not substitute these types of tests, but also the reverse: you just don't write tests for types, as they are subsumed by the value tests, which is why I object to the canard of "the type system saves you from having to write trivial tests for types". And yes, a type-system can do certain types of "forall" analyses that are difficult or impossible with tests, but that's a different topic.

It's also more important.

Generally with tests, you're less concerned about having some particular examples succeed, than you are with finding if there are possible values that fail.

Re: My Swift Dilemma

#43

Earlier quoted context omitted.

OK, I see your point. Of course, the type system will not substitute this kind of tests. But it allows you to check the whole range of values. This is helpful if you e.g. wanted to handle overflows, wanted to limit the operands to positive numbers, etc.

Not only will the type-system not substitute these types of tests, but also the reverse: you just don't write tests for types, as they are subsumed by the value tests, which is why I object to the canard of "the type system saves you from having to write trivial tests for types". And yes, a type-system can do certain types of "forall" analyses that are difficult or impossible with tests, but that's a different topic.

The fallacy is assuming people write tests.

Regardless of what gets preached at agile conferences and such, the reality is that in most enterprise projects, the amount of tests is close to zero.

Re: My Swift Dilemma

#44
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.

That was exactly what I thought.

His argument seemed to be "look, you could have added this feature to existing Objective C syntax rather than inventing a new language" - which is all true, but rather misses the point.

At least one of the problems with Objective C is its syntax, and he states this himself - "Much of the Objective-C syntax is clunky, bolted on, and downright infuriating at times". Yet nothing I see in his suggestions solves that - unless he's suggesting ditching all existing syntax (which is pretty much what Swift is), then all he's doing is proposing yet another syntax structure to add to the already messy bastardisation of C and Smalltalk that makes Objective C the pain it is today.

Re: My Swift Dilemma

#45

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…

What about when you are handling external data? Don't you test what will happen when unexpected types are received? How do you test the handling when a JSON key you were expecting to be an array turns out to be a string or an integer or vice versa?

Do you handle nil's correctly in every place they might occur. These are all things that can be covered by a powerful type system (such as Swift's unless you overuse "!"[0]).

[0] Anything other than use for a member that is initialised during the init method is a code smell in my view.

Re: My Swift Dilemma

#47
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.

I really like Swift, the strong static typing, imutability options, and even generics but there are some features of Obj-C that are lost. Objective C is a very flexible dynamic language with opportunities for runtime twizzling, object introspection. It is really like a lower level Ruby and if you use it a certain way is basically duck typed (you can send any message to any object). Swift is much more a static language and only really enables introspection and downcasting if you enable the Objective C compatibility for a class. This makes some things harder at least to do the same way as Objective-C (JSON parsing with NSJSONSerialization isn't pretty).

As mentioned I prefer Swift but I do acknowledge that there are some losses that others may feel more keenly.

Re: My Swift Dilemma

#48

Earlier quoted context omitted.

> Am I the only one agrees with the author that generics probably do more harm than good It's really the same debate as 'Dynamic' vs 'Static' languages, since without generics your code is relying on runtime type checking in anything remotely complex, thus is effectively a dynamic language. Personally, I'm of the opinion that people that don't like static typing only feel that way because they've only used the shitty…

I do agree with your points, but i think you've over generalised them into a degree that discussion is not only unnecessary but also childish. Let's restore the context back to Swift in iOS programming to match its targeting market, shall we? Could you come up with 1 use case which: .. generic is really useful. .. the problem hasn't solved by well recognised 3rd party lib/framework.(by "well recognized" i mean github…

> Could you come up with 1 use case which: .. generic is really useful.

Errm arrays/dictionaries that return typed objects so that you don't have to cast everything from id either with an ugly explicit isKindOf test or just hoping for the best?

There is nothing that strong typing fixes that can't be fixed by just coding it right but when has everything been coded absolutely right without bugs? And even if it is coded right to start with when you make a change if you forget one rare case where it is used during your refactor you can end up with a crash in the field or with Swift a compile time error that you fix in a second.

Re: My Swift Dilemma

#49
post #36

Earlier quoted context omitted.

>> 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…

> Those values have types, so those get tested as a side effect without any additional effort. Not in the presence of implicit conversions, often insane in dynamic languages. (like, 12 + "34a" gives 46).

Often? what language does '12 + "34a" gives 46'? Not even perl does that.

Re: My Swift Dilemma

#50

when I first saw Golang, I hated it, but now I think it's the best server side language. Galang is an insanely pragmatic language. It's not fancy, just works. Facing Swift, I had mixed feelings. It's a beautiful language, probably as pretty as Ruby, but what really makes it unique, or extremely productive? I can't find any. Am I the only one agrees with the author that generics probably do more harm than good. I'd ar…

> Am I the only one agrees with the author that generics probably do more harm than good It's really the same debate as 'Dynamic' vs 'Static' languages, since without generics your code is relying on runtime type checking in anything remotely complex, thus is effectively a dynamic language. Personally, I'm of the opinion that people that don't like static typing only feel that way because they've only used the shitty…

Stopped reading when you referred to 'shitty implementations' in C#.
Post reply on HN