Live data from Hacker News

My Swift Dilemma

owensd.io

51–60 of 129 posts

Re: My Swift Dilemma

#51

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…

> generic is really useful

Container types are the most obvious. Lists, Arrays, Dictionaries, Vectors, Stacks. You'd be hard pressed to find code that doesn't use a container type of some kind.

Re: My Swift Dilemma

#52

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…

There is a lot of interest in research on the benefits of static vs dynamic typing. But unfortunately there is not a lot of hard data. There were some experiments, e.g.

    http://dl.acm.org/citation.cfm?id=2047861 
which seem to support the claim that dynamic typing is better for rapid prototyping. So if you have data that correlate typing disciplines with bug rates, it would be hugely valuable to share it.

Re: My Swift Dilemma

#53

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)

I know that's just an example and that you probably don't actually write tests like that in your day job, but it's a terrible unit test. For example, it fails to tell apart addition from the constant function 7.

Even if you add more data points, you're still not testing addition.

In a way, "testing for specific values" is very misleading. Consider that it'd be the wrong if you were actually trying to prove something. Now, tests aren't proofs, but we still should write them to be as strong as it's practical.

Strong static typing with property testing (a la quickcheck) whenever possible are preferrable in my opinion.

Re: My Swift Dilemma

#54
post #49
post #36

Earlier quoted context omitted.

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

PHP does, I just checked.

Re: My Swift Dilemma

#55
post #50

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…

Stopped reading when you referred to 'shitty implementations' in C#.

"Shitty" may not be the right word, since C#'s type system works fairly well for its problem domain. The point is that the type systems found in C# and Java are conservative and in many cases overly burdensome for the type-safety benefits you get.

As a result, when compared against purely dynamic languages, the advantages of static typing in Java and C# are not so clear cut (Hence why so many developers just use dynamic languages).

If your only exposure to static typing is in Java or C#, then you're really haven't seen a good type system at work.

Re: My Swift Dilemma

#56

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…

There is a lot of interest in research on the benefits of static vs dynamic typing. But unfortunately there is not a lot of hard data. There were some experiments, e.g. http://dl.acm.org/citation.cfm?id=2047861 which seem to support the claim that dynamic typing is better for rapid prototyping. So if you have data that correlate typing disciplines with bug rates, it would be hugely valuable to share it.

They used Java as the static language, which is relatively cumbersome as far as statically typed languages go, and is also known for its verbosity. "Rapid prototyping" and "java" does not really mesh to begin with, or at least that's what the common wisdom tends to say.

It seems that they need another survey/study to check the OPs claim (namely do some research on productivity in languages with stronger static type systems than java).

Re: My Swift Dilemma

#57
My instinct is that most well-versed Objective C programmers won't get much out of Swift. But for people like - non-Objective C programmers - it's been great. I've long since been put off by the alien syntax of it. I've been told numerous times that once you get to know it you adjust, and I believe it, but iOS programming is never going to be my full-time job, so I'm not interested in spending that amount of time getting comfortable.

With Swift, however, I was up and running very quickly. Also running in EXC_BAD_ACCESS errors, but hey, early days...

Re: My Swift Dilemma

#58
The author fails to realize one critical thing—that the imaginary "Objective-C 3" language he wants requires intentionally breaking the fact that Objective-C is a strict superset of C… exactly what Swift has done.

Re: My Swift Dilemma

#59

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…

There is a lot of interest in research on the benefits of static vs dynamic typing. But unfortunately there is not a lot of hard data. There were some experiments, e.g. http://dl.acm.org/citation.cfm?id=2047861 which seem to support the claim that dynamic typing is better for rapid prototyping. So if you have data that correlate typing disciplines with bug rates, it would be hugely valuable to share it.

On the other hand, there's the 1994 Navy sponsored study which had as an (informal) conclusion that Haskell was better at rapid prototyping when compared to other languages of the time.

http://haskell.cs.yale.edu/wp-content/uploads/2011/03/Haskel...

The experiment mostly compared Haskell with imperative languages such as C++ and Ada, but there was also at least one Lisp variant. There were several informal aspects to the study, not the least of which being that there were no clearly defined requirements for the system to be implemented (so it was up to each participant to define the scope), but the conclusion is very interesting nonetheless:

The Haskell took less time to develop and also resulted in less lines of code than the alternatives, and it produced a runnable prototype that some of the reviewers had a hard time believing wasn't a mockup. Many of the alternatives didn't even end up with a working system. It should also be noted that the Haskell participants decided to expand the scope of the experiment; i.e. they didn't "win" because they implemented a heavily simplified solution, but in fact added extra requirements to their system and still finished earlier!

Even though Obj-C wasn't included in the study, there were similar enough C-like languages in it, so my bet is that Haskell would have won against it as a rapid prototyping language as well.

Post reply on HN