Live data from Hacker News

My Swift Dilemma

owensd.io

31–40 of 129 posts

Re: My Swift Dilemma

#31
post #21

My take on swift : use it once apple release a real product made with it.

Which is fair enough, but if you look at the amount of effort they are putting in to bring Swift's documentation / tooling up to speed, it seems pretty obvious that Apple themselves have high ambitions for the language. Also, it's going to be hard to tell how much Swift code is being shipped by Apple - the interfacing with existing Obj-C code is sufficiently clean that it's relatively simple to have parts of a produc…

I recently learned that core data wasn't used internally at apple. That freaked me out, because it made me feel that choosing that technology for a serious project was a mistake, despite the numerous documentation and support apple provides for it.

Re: My Swift Dilemma

#32

Earlier quoted context omitted.

Well, types are essentially sets of values. So if you can capture the values that you expect in a type, then the type system _does_ give you a guarantee.

But tests test for specific values. Example: testThatAddWorks result = add( 3, 4 ) EXPECT( result , 7)

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.

Re: My Swift Dilemma

#33
post #31

Earlier quoted context omitted.

Which is fair enough, but if you look at the amount of effort they are putting in to bring Swift's documentation / tooling up to speed, it seems pretty obvious that Apple themselves have high ambitions for the language. Also, it's going to be hard to tell how much Swift code is being shipped by Apple - the interfacing with existing Obj-C code is sufficiently clean that it's relatively simple to have parts of a produc…

I recently learned that core data wasn't used internally at apple. That freaked me out, because it made me feel that choosing that technology for a serious project was a mistake, despite the numerous documentation and support apple provides for it.

Really? Not that I'm doubting you. Could you please provide me a link so that i can educate myself?

Re: My Swift Dilemma

#34

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 implementations in Java or C#.

Regardless, This is a religious war that has raged for decades, and isn't likely to be answered anytime soon. The answer really comes down to "It Depends". I fall firmly in the 'static typing is good' camp, mainly because I have hard evidence to back up my opinion that it results in significantly fewer defects.

(Specifically, very clear reports from from issue tracking systems showing our defect rate in production dropping by 90% (!!!) when we switched from Groovy to Scala, with a notable increase in productivity).

Some of the developers complained, since they had to learn knew tools. But being professionals, they learned new tools and were better off for it.

Now while I'm an extremist religious zealot about proper static typing being the one true way, I'm quite mindful that, for many developers, that tasks they are working on just aren't complex enough for it to make much of a difference in practice - they are able to test all edge cases and deploy stable software to production, just with a little more runtime testing than they'd otherwise need.

Some languages - such as Go, or pre-enlightenment Java, do not implement Generics, and thus require runtime casting in many cases. In these languages, there's still a degree of compile time checking, just not as thorough as it should be. As with dynamic languages, they can work with no perceived issues for projects up to a certain size and provide a reasonable halfway point. Beyond this, you're going to hit a wall.

As to your argument that Generics do "More harm"? I'd strongly disagree. If you're unfamiliar with the gotchas generics introduce (i.e. Variance can be a mindfuck), then they can seem difficult and problematic. But like any other professional tool, once you've gotten over the learning curve you're more productive with it than without.

tl;dr If I wanted to bang a few pieces of wood together, I'd feel comfortable using a Hammer. the learning curve small, and I can connect those two pieces of wood in no time.

My Uncle is a carpenter. As a professional carpenter, he bangs pieces of wood together all day long, every day, for his entire career. As such, a nailgun is a more appropriate tool. While being more complex to use and having a steeper learning curve, he's a professional, and uses a professional tool to do a professional job. Occasionally he might want to bang some quick project together in his shed, and getting out the nailgun is overkill, so he uses a hammer for the odd thing here and there.

I'm a professional programmer. I use professional tools, even if they have a steeper learning curve and might be more complex. Occasionally I want to whip up a quick script, so will just hack it together in Python.

Re: My Swift Dilemma

#35
post #8

"I look at the feature set of Swift, and I have to ask myself the question: what’s the point? What is really trying to be solved? And does it provide significant benefits over languages that already exist?" One reason may be that large companies want ownership of a modern, C#/Java/Go-like language [1]. I was an intern at Adobe when it was trying to develop such a language (ActionScript 4) + VM, and a primary reason n…

> One reason may be that large companies want ownership of a modern, C#/Java/Go-like language

Quite true. A major reason why c# exists is that circa 2000, Microsoft wanted ownership of a modern, Java-like language.

Re: My Swift Dilemma

#36

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…

> 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).

Re: My Swift Dilemma

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

This is just a side-effect of the blub paradox disease. One of the symptoms for those that are afflicted with it is ranty blog posts about new languages that the afflicted person does not perceive as being better because it doesn't really have the same semantics as the one language they are used to. I think it was Douglas Crockford that said this. We don't get new and better technology because the old people accept i…

> it doesn't really have the same semantics as the one language they are used to

His complaint is that Swift does have mostly the same semantics as Objective C, and offers only a prettified syntax.

Re: My Swift Dilemma

#38

Earlier quoted context omitted.

But tests test for specific values. Example: testThatAddWorks result = add( 3, 4 ) EXPECT( result , 7)

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.

Re: My Swift Dilemma

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

This is just a side-effect of the blub paradox disease. One of the symptoms for those that are afflicted with it is ranty blog posts about new languages that the afflicted person does not perceive as being better because it doesn't really have the same semantics as the one language they are used to. I think it was Douglas Crockford that said this. We don't get new and better technology because the old people accept i…

[deleted]

Re: My Swift Dilemma

#40
post #31

Earlier quoted context omitted.

I recently learned that core data wasn't used internally at apple. That freaked me out, because it made me feel that choosing that technology for a serious project was a mistake, despite the numerous documentation and support apple provides for it.

Really? Not that I'm doubting you. Could you please provide me a link so that i can educate myself?

Unfortunately it's not a written statement ( you can imagine that nobody working at apple would publicly say a thing like that). And it's not a direct source either, so you can very well take that with a grain of salt.

Actually, I am still hoping that someone will contradict me by providing concrete example of apple software using core data though, because as i stated, i invested a lot in that technology for an important project.

Post reply on HN