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

Go vs. Swift [pdf]

github.com

Post reply on HN
Print view View original

121–128 of 128 posts

Re: Go vs. Swift [pdf]

#121

Post by mahyarm »

rimantas wrote: post #84
mahyarm wrote: post #19

Earlier quoted context omitted.

How many lines of code does your project use? How complicated is your module structure? Is everything in one huge target or do you split your app into 100s of modules? What do you use for dependency management, what is your deployment target? Are things running in one process like an iOS app or is it some sort of OS X project? Pretty much every large swift project I've seen has had the problems described. Lyft, Uber,…

You worked with source of both , Uber and Lyft? And Linkdin too?

They do presentations about swift and have twitter employee accounts where they complain about swift :)

Re: Go vs. Swift [pdf]

#122

Post by Ericson2314 »

majewsky wrote: post #97
Ericson2314 wrote: post #32

Earlier quoted context omitted.

? is bind for Either monad if you squint. `context(e?)` becomes `e >>= \x -> context(x)`

You mean `e >>= context` ? ;)

Hah!

I should have been clear about CPSing things first so I didn't need to eta-expand :)

Re: Go vs. Swift [pdf]

#123

Post by wyager »

GregBuchholz wrote: post #116
majewsky wrote: post #95

Earlier quoted context omitted.

This only works because you're working with number literals here, which have the very liberal type "Num a => a". If I replace your main function by check :: Int -> Bool check x = x == (Just x) main = print (check 5) I get a compile error: Main.hs:7:17: error: • Couldn't match expected type ‘Int’ with actual type ‘Maybe Int’ • In the second argument of ‘(==)’, namely ‘(Just x)’ In the expression: x == (Just x) In an e…

Right, it was just a fun little "Well Actually" moment. http://tirania.org/blog/archive/2011/Feb-17.html

That is possibly the most condescending thing I've ever read. Whatever the author tried to make themselves less abrasive, it didn't work very well.

Re: Go vs. Swift [pdf]

#124

Post by bad_user »

coldtea wrote: post #101
bad_user wrote: post #82

Earlier quoted context omitted.

> `5 == Just 5` fails. But in Swift this works like you would want Why in the world would you want those two to be equal when they obviously don't represent the same thing? That doesn't make sense, not even if they have the exact same memory representation, in which case I'm pretty sure it has been a compromise, which would mean you're still dealing with `null` with some lipstick on it, making that type behave incons…

> Why in the world would you want those two to be equal when they obviously don't represent the same thing? Because I care for intended use, not ontology.

That is not the intended use of Option/Maybe, the whole point of an `Option[A]` is to be different from `A`.

Re: Go vs. Swift [pdf]

#125

Post by coldtea »

bad_user wrote: post #124
coldtea wrote: post #101

Earlier quoted context omitted.

> Why in the world would you want those two to be equal when they obviously don't represent the same thing? Because I care for intended use, not ontology.

That is not the intended use of Option/Maybe, the whole point of an `Option[A]` is to be different from `A`.

Not the intended use of Option[A] -- the intended use of A. Option is just a safeguard, and for the check with A that capability is not needed at all (if it's Just A it can ...just equal to A).

Re: Go vs. Swift [pdf]

#126

Post by bad_user »

coldtea wrote: post #125
bad_user wrote: post #124

Earlier quoted context omitted.

That is not the intended use of Option/Maybe, the whole point of an `Option[A]` is to be different from `A`.

Not the intended use of Option[A] -- the intended use of A. Option is just a safeguard, and for the check with A that capability is not needed at all (if it's Just A it can ...just equal to A).

Option isn't a safeguard, it expresses missing values in a way that doesn't violate the Liskov Substitution Principle, otherwise you might as well work with `null` along with some syntactic sugar.

And they are different because the types say so. By allowing them to be equal, you're implicitly converting one into the other. That's weak typing by definition, a hole in the type system that can be abused.

So why have types at all? Dynamic typing is much more convenient and Clojure deals with nulls by conventions just fine.

Re: Go vs. Swift [pdf]

#127

Post by coldtea »

bad_user wrote: post #126
coldtea wrote: post #125

Earlier quoted context omitted.

Not the intended use of Option[A] -- the intended use of A. Option is just a safeguard, and for the check with A that capability is not needed at all (if it's Just A it can ...just equal to A).

Option isn't a safeguard, it expresses missing values in a way that doesn't violate the Liskov Substitution Principle, otherwise you might as well work with `null` along with some syntactic sugar. And they are different because the types say so. By allowing them to be equal, you're implicitly converting one into the other. That's weak typing by definition, a hole in the type system that can be abused. So why have typ…

>Option isn't a safeguard, it expresses missing values in a way that doesn't violate the Liskov Substitution Principle, otherwise you might as well work with `null` along with some syntactic sugar.

Again, it's the use that makes it a safe guard, not its ontology.

>And they are different because the types say so. By allowing them to be equal, you're implicitly converting one into the other.

Which is fine sometimes, when you explicitly need to do it a lot.

>That's weak typing by definition, a hole in the type system that can be abused.

Any examples of how A = Just A can be abused in any meaningful way?

>So why have types at all?

Because I don't believe in the Slippery Slope fallacy, and some types are better than no types at all, but exceptions can be OK too.

Re: Go vs. Swift [pdf]

#128

Post by premium-concern »

hardwaresofton wrote: post #100
premium-concern wrote: post #93

Earlier quoted context omitted.

> Also, Optionals are a light introduction to functors which is nice. Optional is not a functor, in fact it violates the functor laws quite blatantly.

I didn't assert they were functors. Just that seeing `map` on something that isn't a list should be somewhat eye-opening to someone who just casually uses it and isn't too familiar with functional programming, that was the point. Also, when I wrote "functor" I was thinking of https://wiki.haskell.org/Functor , is that what you're thinking of? In that case, which of the rules does it break? if not, what definition of…

Consider two functions (excuse my Scala):

  val str: Function[String, String] = s => if (s.length > 3) s else null

  val num: Function[String, Integer] = s => if (s == null) -1 else s.length
With Optional, you receive different results depending on whether you call map twice, or combine the functions first:

  scala> Optional.of("Foo").map[String](str).map[Integer](num)
  res12: java.util.Optional[Integer] = Optional.empty

  scala> Optional.of("Foo").map[Integer](str.andThen(num))
  res15: java.util.Optional[Integer] = Optional[-1]
This is incorrect and violates the functor law.
Post reply on HN