Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Swift Dilemma

owensd.io

Post reply on HN
Print view View original

71–80 of 129 posts

Re: My Swift Dilemma

#71

Post by dkarapetyan »

lerno wrote: post #26
dkarapetyan wrote: post #6

Earlier quoted context omitted.

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…

If you had followed what Owens has written and done in Swift, you know that he has worked and pondered the language quite a bit. Dismissing it as due to "blub" is disingenuous. Aside from brushing away the value of his opinions, such a statement also implies that Swift is in some way sufficiently removed from mainstream languages as to feel "foreign". That is not true. Swift is a pragmatic amalgam of features from ma…

When it comes to programming language reviews I don't think there is any value in them regardless of who is doing the review. Steve Yegge in one of his epic posts explains why everyone should design a language from scratch to see what the process is like. Once you do that the magic and wonder disappears and you realize both how hard and easy it can be depending on what constraints you have. Here's a nice starting point http://nathansuniversity.com/.

Re: My Swift Dilemma

#72

Post by the_af »

zvrba wrote: post #69
the_af wrote: post #53

Earlier quoted context omitted.

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

> For example, it fails to tell apart addition from the constant function 7. Right. But how would you test for the addition function without exhaustive O(N^2) search over the whole input space? (You need to test for commutativity; if you're going to test for associativity, it grows to O(N^3)).

My comment was in the context of the "unit tests vs type systems" debate. It was meant to illustrate my opinion that "more general" is better than "specific values" when testing, as much as is practically possible.

I'm aware that addition is a toy example, but suppose we want to test our implementation:

Except for very simple verification, to exclude obviously broken implementations, I'd rule out testing specific values such as 3+4=7. And, like you said, performing an exhaustive exploration of all values is out of the question.

So I'd try property testing instead. Relevant properties in this case are associativity, commutativity, etc.

As an example, I'd try writing properties such as:

  for all X, Y: add(X, Y) = add(Y, X)
I'm not arguing that everything can be tested like this, or that the properties are always easy to formulate; but when they are, I think this is the superior approach.

The tools that I'm aware of that can do this (such as QuickCheck or ScalaCheck) come from statically typed languages, though I don't see why they couldn't be used with dynamically typed languages.

The point is that this starts to look a lot closer to static typing and "testing generalities", philosophically, than what proponents of dynamic typing + unit testing propose. Testing generalities is better than testing specifics, because it's at least a step closer to a proof of correctness.

Re: My Swift Dilemma

#73

Post by dragonwriter »

the_af wrote: post #72
zvrba wrote: post #69

Earlier quoted context omitted.

> For example, it fails to tell apart addition from the constant function 7. Right. But how would you test for the addition function without exhaustive O(N^2) search over the whole input space? (You need to test for commutativity; if you're going to test for associativity, it grows to O(N^3)).

My comment was in the context of the "unit tests vs type systems" debate. It was meant to illustrate my opinion that "more general" is better than "specific values" when testing, as much as is practically possible. I'm aware that addition is a toy example, but suppose we want to test our implementation: Except for very simple verification, to exclude obviously broken implementations, I'd rule out testing specific val…

> The tools that I'm aware of that can do this (such as QuickCheck or ScalaCheck) come from statically typed languages, though I don't see why they couldn't be used with dynamically typed languages.

The tools use type information to determine the universe to draw test values from and the mechanism used to do it. You can actually do something very similar for dynamically typed languages, but if you don't have queryable type annotations for parameters, etc., you have to have more verbose test specifications that provide the scope of testing.

E.g., in a statically-typed language (or a dynamically-typed one with optional type annotations), if your add function is defined as something equivalent to:

  double add(double x, double y) 
  {
    ...
  }
then your test system can use that information and a value generator function for doubles to generate the appropriate test data to validate the property.

OTOH, in a dynamically typed langage where you just have something like

  def add(x, y)
  {
    ...
  }
Without some additional specification, the test framework doesn't know how to generate the X and Y values for the test you propose.

Re: My Swift Dilemma

#74

Post by dkarapetyan »

mpweiher wrote: post #66
dkarapetyan wrote: post #6

Earlier quoted context omitted.

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…

Post https://news.ycombinator.com/item?id=8367012 suggests that it is actually Swift that is the Blub language...

I don't see how. Being a blub language has nothing to do with ease of use for newcomers and in fact no language can be a blub language. It is more a reflection of the user. If all I know is imperative programming constructs because I've been writing C for 20 years and I start to learn Prolog but fail to understand what constraint logic programming is really about because I'm constantly trying to use imperative constructs in Prolog then I'm afflicted with the blub disease. Neither C nor Prolog is a blub language.

Re: My Swift Dilemma

#75

Post by the_af »

mpweiher wrote: post #66
dkarapetyan wrote: post #6

Earlier quoted context omitted.

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…

Post https://news.ycombinator.com/item?id=8367012 suggests that it is actually Swift that is the Blub language...

That doesn't suggest Swift is a Blub-like language to me.

Though not explicitly stated in the Blub paradox, I'd say it implies that a fresh programmer, unfamiliar with both Blub and the more advanced language, would pick the more advanced language.

The Blub paradox doesn't automatically apply to every language whose syntax you find bizarre. It also has to be a more advanced language, and the reason that you don't like the language's syntax and constructs must be because you don't understand the advanced features they enable.

This is clearly not the case with Obj-C and the post you mentioned.

Re: My Swift Dilemma

#76

Post by the_af »

mpweiher wrote: post #38
solarexplorer wrote: post #32

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.

> you just don't write tests for types, as they are subsumed by the value tests

I think this is false.

Re: My Swift Dilemma

#77

Post by crazychrome »

iopq wrote: post #61
crazychrome wrote: post #22

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…

Golang is an evolutionary dead end. It missed out on the last 25 years of language research. I'm following Rust more closely because it has new ideas for systems programming. Go has no new ideas.

Rust is interesting one. The only part I dislike is the pointer ownership. Can they work out a better model/analogy after 15 years of Boost?

Re: My Swift Dilemma

#78

Post by the_af »

yen223 wrote: post #18
coldtea wrote: 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.

Except for the "therefore Obj-C is superior" part, I agree that Option types in languages such as Swift and Scala are unfortunately marred by those languages' need to be compatible with Obj-C and Java, respectively.

I understand idiomatic Scala won't use null, just as I assume idiomatic Swift won't use nil, but nevertheless the fact that they allow nulls weakens their type systems.

Re: My Swift Dilemma

#79

Post by vorg »

zoomerang wrote: post #34
crazychrome wrote: post #22

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…

> our defect rate in production dropping by 90% (!!!) when we switched from Groovy to Scala, with a notable increase in productivity)

> Occasionally I want to whip up a quick script, so will just hack it together in Python

Languages like Python and Groovy were originally created to be scripting languages for quickies. Of course what starts off as a short script can easily evolve into a larger production system. Groovy's creator James Strachan based Groovy closely on Java syntax specifically to provide a seamless upgrade path from Groovy to Java when such scripts grow into something larger. He even put in runtime type tags which would become compile-time types without any syntactic changes when code was converted from Groovy to Java. Groovy was innovative beyond its peers Python and Ruby in that way, intended to be a dual dynamic language to statically-compiled Java, enabling easy conversion to the main language when required. Other languages like C# and Scala solved that issue with type inference and by adding a "dynamic" type into the main language instead.

Unfortunately after Strachan was replaced, the management policy regarding Groovy's purpose changed. All work on a spec to encourage alternative implementations was dropped, and a user-contributed plugin enabling static compilation was duplicated into the main Groovy distribution for version 2. Groovy was then pitched as an alternative to Java, competing head on. They don't mention in their marketing, however, that a mere one person wrote Groovy's static code compared to the hundreds who contributed to Java's, and or even to Scala's. Therefore adopting Groovy for static compilation is very risky, a possible cause for your huge defect rates in production.

Re: My Swift Dilemma

#80

Post by entropy_ »

PieSquared wrote: post #5

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…

To me, by far the biggest advantage of generics is that it makes it a whole lot easier to understand function signatures. I develop on both Android and iOS and I can't even begin to count the number of times I've read a function definition, seen that it takes an (NSArray *) as a parameter and had to trudge through 5 layers of indirection(either upwards to find the construction, or downwards to find the use) to figure out what that array is supposed to be filled with. Contrast that with Java on Android, if a function takes a List I can immediately tell what type of list it's expecting. It's true that if the code had proper tests and a good architecture this shouldn't be an issue, but when was that ever the case? You just get handed a git repo your predecessor left and are expected to read the code and understand it.
Post reply on HN