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

Smashing Swift

nomothetis.svbtle.com

Post reply on HN
Print view View original

141–150 of 150 posts

Re: Smashing Swift

#141

Post by hetman »

terminus wrote: post #79
lxcid wrote: post #60

Earlier quoted context omitted.

This is kinda misunderstanding Apple approach to introducing technology. Apple seldom introduce a technology as intermediary solution or discard them soon after. (the last time this happen that I could remember was GC in Objective-C which is replaced by ARC) They could double down on it even if it has its algorithmic flaws, and they will attempts to fix those flaws. One of recent technologies that fall into this cate…

> They might not be the most open of company but they had open source technologies that are awesome in their own right. LLVM is just one of them. Open sourced and won the ACM award. That by itself is a achievement hard to beat. I don't understand how a community project became "Apple's achievement." Apple did not open source LLVM. LLVM was an open source project (since 2000), which Apple used and open sourced their c…

Also true of WebKit. I don't think it makes sense to draw conclusions about a project which started as a closed in house affair, based on projects which were based on open source ones, as parent has.

Re: Smashing Swift

#142

Post by skybrian »

baddox wrote: post #101
skybrian wrote: post #73

Earlier quoted context omitted.

In Java we would call it "Mappable". A Mappable interface would have one method: map(). It hasn't been all that useful until recently due to lack of closures, but perhaps it would make sense in Java 8? "Functor" is a terrible name that only a mathematician could like.

Remind me: can you declare a Java interface with a method signature that returns the same type as the class that eventually implements the interface? You wouldn't want the map method on mappable to simply return another Mappable, because that could be any other Mappable (i.e. a CustomList could implement map to return a CustomTree, when the functor concept requires it to return another CustomList).

I would bail on type checking and use an assertion. It's not reasonable to try to statically check everything in Java that you could in some other languages.

Re: Smashing Swift

#143

Post by skybrian »

Chattered wrote: post #93
skybrian wrote: post #78

Earlier quoted context omitted.

Yes, good point. I suppose replaceEach() would be a more descriptive name, so the interface might be HasReplaceEach. It's not as easy to talk about, though. Still better than "functor". (The function being passed in to map() is an alternate way to represent a very large map, in a mathematical sense.)

Mathematicians prefer obscure technical terms to misleading and restrictive metaphors, because obscure terms force you to refer solely to (and eventually internalise) a precise and abstract definition. I think this is the case for functors, because I've yet to see a metaphor for them which isn't misleading or restrictive. "replaceEach", for instance, would confuse me. I like working with parser combinators, where par…

Well, yes, mathematicians like to be very precise about exactly what a very general abstraction entails, to the point where you are being very precise about how two almost entirely different concepts have almost but not quite nothing in common.

These fine distinctions don't belong in code meant for a general audience. Instead, don't try to generalize so much. It's not important (and in fact it's confusing) that replaceEach can be generalized to work with a parser. Parsers can have a different function with its own name and nobody needs to know that it's sort of the same concept.

Re: Smashing Swift

#144

Post by CmonDev »

hit8run wrote: post #98

"She" the programmer. Seriously this sounds ridiculous and is the outcome of the shameful male "betafication" women try to establish these days. I say "he" the programmer. Okay enugh bullshit and to the point: Swift is preview. It will get better and better fromday to day. It isn't there to mimic scala or lisp paradigms. It is there to get the job done and it will get the job done.

That's just unnecessary political correctness. It's very hip amongst a very special crowd of people. Using multiple genders somehow fixes the gender dis-balance in the craft.

Re: Smashing Swift

#145

Post by hetman »

asveikau wrote: post #71
tkubacki wrote: post #59

Earlier quoted context omitted.

You are overreacting. I'm not saying it's shitty - but it SEEMS to be at least for most Java/C# devs (I know) AT FIRST SIGHT. My hypothesis was: Objective-C is "not nice" (sorry, I'm not familiar with HN political correctness) therefore Swift feels like a true relief for iOS devs and thus this much traction.

It seems these days there are a lot of Java and C# focused people who are unfamiliar with what came earlier. They have a hard time making these sorts of comparisons. To me the comparison that makes more sense is going from C to objc. Or alternatively, comparing objc and C++ (especially C++ as practiced in the 1990s, not the RAII or template patterns that emerged later). Say you're looking at the landscape as it exist…

Comparing one 80's language to another 80's language hardly demonstrates how great it is in 2014 ;)

Re: Smashing Swift

#146

Post by hetman »

gdubs wrote: post #75
tkubacki wrote: post #59

Earlier quoted context omitted.

You are overreacting. I'm not saying it's shitty - but it SEEMS to be at least for most Java/C# devs (I know) AT FIRST SIGHT. My hypothesis was: Objective-C is "not nice" (sorry, I'm not familiar with HN political correctness) therefore Swift feels like a true relief for iOS devs and thus this much traction.

Objective-C is a great language; at least a lot of us who have been developing in it for years think so. We're excited about Swift because although ObjC has modernized a great deal, there are limitations to how far it can be pushed. Swift's clean block syntax is a good example here. Objective-C, if you're not turned off by the syntax, can be a joy to program in.

It doesn't even have namespaces. ARC basically made "struct" obsolete (goodbye easy literal data instatiatons), and it doesn't have a lot of the things programmers have come to expect even in compiled languages these days. Now don't get me wrong, for a 30 year old language, it's pretty good, but calling it great may be a little over stated.

I don't mind the syntax, but I don't think it's the nicest language out there feature wise.

Re: Smashing Swift

#147

Post by ksk »

rsynnott wrote: post #131
ksk wrote: post #111

Its amusing to see Apple cheerleaders defend Swift as being good enough for version 0.1 when supposedly Apple is this company that only releases products when they're complete/polished/etc. Apple themselves proclaim its "Ready Today" on their marketing page as well. ( https://developer.apple.com/swift/ )

Apple does that with _consumer_ products (well, usually; please ignore Siri). They've historically been much more willing to ship developer stuff that's very rough around the edges; the iPhone OS 2.0 SDK shipped in a barely usable state, for instance, and Xcode 4 was a similar story.

Fair enough. :)

Re: Smashing Swift

#148

Post by dllthomas »

leorocky wrote: post #24
muaddirac wrote: post #23

Earlier quoted context omitted.

Thank you for this. I find explanations that eschew category theory bizarre, this really cleared things up for me (having spent a lot of time with functors mathematically, and almost no time with them in a programming context).

I appreciate orbifold taking the time to reply but I couldn't understand his answer at all, even after perfectly understanding what others have said. There are 3 sentences in that paragraph the second of which is very large and difficult to parse and missing an end parenthesis somewhere. Why do you get a composition of functions by applying a functor to individual functions? It seems like a functor is just something…

I think it gets worlds better with diagrams. I'll try to revisit this and provide some, when I've a bit more time.

Re: Smashing Swift

#149

Post by specialist »

archgrove wrote: post #18
danabramov wrote: post #15

Earlier quoted context omitted.

>However, I ran up against the lack of generic protocols myself today (for those with access, there's an interesting debate at https://devforums.apple.com/thread/230611?tstart=0 ). It seems like a deliberate design choice, but one I'm not really sure about. So did I! A few more related links if you're interested in this question: http://schani.wordpress.com/2014/06/11/associated-types-cons... http://www.artima.com/we…

Very interesting, thanks. I also ran up against another annoying bug/oversight/v0.1ism : You can't inherit from a generic class without becoming generic yourself. So, even if you fully instantiate your parent's type information, you have to be generic as well! For example: class Foo { ... } class Bar : Foo { ... } You'd expect Bar to be a non-generic type, but this throws a compiler error. You have to declare: class…

In Java, to clean up the brackets (exposed via APIs) I'll do something like:

  class NodeList extends List { ... }

Re: Smashing Swift

#150

Post by afthonos »

jmah wrote: post #136
afthonos wrote: post #45

Earlier quoted context omitted.

That doesn't actually work, because you're limiting the return type of the method in the implementation of the functor. So by implementing that protocol, you could have one mapping from Int to String (say), but not another from Int to Double. Put another way, you need to specify FunctorResult at implementation time, and the whole point is to only have to specify it at call time.

This code works: let d = [1: 1, 2: 2, 3: 3] let intToInt = d.map { $0 + 1 } var IntToString = d.map { String($0) }

The code works, but the type of the generic is not guaranteed at compile time. FunctorResult could be anything at all. There is no compile-time obligation for the code to return a Dictionary.

The more canonical example of a Functor is really the Optional. The mapping method for an optional looks like this:

  func fmap(f: A -> B) -> Optional {
    switch self {
    case Some(let a):
      return Some(f(A))
    case None:
      return None
    }
  }
However, with your protocol, I can define the mapping function for the Optional as:

  func fmap(f: A -> B) -> B[] {
    switch self {
    case Some(let a):
      return [f(A)]
    case None:
      return B[]()
    }
  }
This would pass the type-checker, but is not what a Functor does.
Post reply on HN