Go vs. Swift [pdf]

Post by seertaak » Thu, Jan 19, 2017, 2:22 PM UTC

bad_user wrote: post #80

chmike wrote: post #74

I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance. The interface concept of Go makes programming with composition much more flexible and powerful than with the class model. The author skips this Go specific and original interface typing. This provides a multiple inheritance equivalent…

OOP is primarily about polymorphism (subtyping) and encapsulation, code reuse by means of inheritance is just a nice to have, so that comparison doesn't make sense. You can compare OOP with parametric polymorphism, you can compare it with type-classes. Heck, OOP isn't necessarily about subtyping and we could be talking about row polymorphism (e.g. OCaml) which has some really nice properties. > This provides a multip…

Post by premium-concern » Thu, Jan 19, 2017, 2:25 PM UTC

hardwaresofton wrote: post #51

wfleming wrote: post #43

Earlier quoted context omitted.

Maybe I'm wrong about how it works, but I feel that Optionals in Java are a bolt-on solution that only solves half the problem that the same concept solves in Swift (or Haskell, or Rust, etc.) An Optional in Java is just another value, and nothing in practice stops that from being null. I.e. a method that returns an Optional can still return an actual null if poorly implemented. So the major benefit Optionals give yo…

I completely agree with your point -- you can't compare the power of compile-time checking to Java's Optionals, for the most part. However I tend to think that what's important about Optionals is the spreading of the notion of thinking critically about failure modes around improper input/output. "Defensive" coding is often considered a mid-range skill (at least I think), and IMO it's because a lot of junior programme…

Post by majewsky » Thu, Jan 19, 2017, 2:46 PM UTC

GregBuchholz wrote: post #47

ridiculous_fish wrote: post #20

Earlier quoted context omitted.

One of the things that makes Optional so pleasant in Swift is the syntax support. This includes optional-chaining, if-let and guard-let unwrapping, and some convenient operators. For example, in Haskell, by default you can't compare an Optional with the value it wraps: `5 == Just 5` fails. But in Swift this works like you would want. All that is to say that Options in Swift are a bit nicer than what you could get wit…

>in Haskell, by default you can't compare an Optional with the value it wraps: `5 == Just 5` fails. -- Probably nothing like in Swift instance (Num a , Integral a) => Num (Maybe a) where fromInteger x = Just (fromIntegral x) main = print $ 5 == (Just 5)

  check :: Int -> Bool
  check x = x == (Just x)

  main = print (check 5)

  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 equation for ‘check’: check x = x == (Just x)

Post by majewsky » Thu, Jan 19, 2017, 2:50 PM UTC

Ericson2314 wrote: post #32

comex wrote: post #29

Earlier quoted context omitted.

Rust copied 'if let' from Swift (~2 years ago) despite having decent pattern matching; community consensus today is that it's highly worthwhile as a feature. There have also been proposals to add 'guard let'. So, while I don't have enough Swift experience to judge its ADT support overall, I wouldn't cite those features as evidence that it's wanting. They might not be as natural in traditional FP languages like Haskel…

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

Post by specialist » Thu, Jan 19, 2017, 3:00 PM UTC

ninjaroar wrote: post #67

hardwaresofton wrote: post #51

Earlier quoted context omitted.

I completely agree with your point -- you can't compare the power of compile-time checking to Java's Optionals, for the most part. However I tend to think that what's important about Optionals is the spreading of the notion of thinking critically about failure modes around improper input/output. "Defensive" coding is often considered a mid-range skill (at least I think), and IMO it's because a lot of junior programme…

Checked exceptions also forces thinking critically about failure modes, but they seem to be an unpopular language feature, and few new libraries seem to use them. No other popular language has adopted them. Why are optionals good and checked exceptions bad? (I'm certainly not implying that one replaces the other - i'm just saying that it they both have an origin of forcing programmers to think about errors)