Live data from Hacker News

Smashing Swift

nomothetis.svbtle.com

101–110 of 150 posts

Re: Smashing Swift

#101
post #54

Earlier quoted context omitted.

In an alternate universe where functional programming was invented by programmers rather than mathematicians, map would probably be called something like convertWith and a functor would probably be called something like a convertible . If you think of a function as being a way of converting from one kind of thing to another, then a functor is an object which has a number of things which you can convert to some other…

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

Re: Smashing Swift

#102

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…

> because obscure terms force you to refer solely to (and eventually internalise) a precise and abstract definition.

Unless some C++ people decide that “functor” is a wonderful name for a stateful function-like thing which somewhat resembles closures/lambdas but has nothing whatsoever to do with the functors from functional programming.

Re: Smashing Swift

#103
post #67

Earlier quoted context omitted.

The language is not "innovative" as they claim, so people are expecting at least some learning from mistakes of prior languages. They could've hired some smart people from more software-oriented companies or something.

> The language is not "innovative" as they claim Not innovative compared to what? Haskell? Unfinished betas like Rust? Some language 100 people use (plus 1-2 banks and a couple of universities)? This is a language that will jump in the top ten of most used languages in a year or so, just because it's used in a hugely popular development platform. And it had to fulfil several things to achieve that. > They could've hi…

It is somewhat unfair to dismiss Rust as an unfinished beta in comments on an article that demonstrates how the Swift compiler isn't even up to beta standards.

Swift is a nice language for sure. It picks up nicest features of many other language and doesn't trade that off with many annoyancies (from what I've seen so far). It also appears like a very accessible language. It breaks with older languages where those older languages are bad (eg "==" vs "===") but mostly sticks to things that work and are familiar. I think these criteria are important for what I think is "good language design".

Swift is not in any reasonable sense an innovative language. There is really nothing in there that is new. Now you can get worked up about that, or just accept that innovativity is really something far less important (or perhaps even undesirable) when compared to "good design" for Swift. Especially given its unique position.

Re: Smashing Swift

#104
post #27

Earlier quoted context omitted.

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…

Well, derived classes are meant to be drop-in replacement for the base class. In that sense it totally makes sense that you can't have a non-generic child class of a generic base class. Otherwise it encourages design where classes are treated as method dumps.

Not classes; instances. So instances of Foo : Bar should be drop-in replacements for instances of Bar.

Re: Smashing Swift

#105

Swift seems like a nice lang, but I'm surprised that proprietary, single platform language is getting so much traction on HN. Is it because ObjectiveC is as shitty as it seems at first sight (for C like langs dev) ?

I would be surprised if Apple did not BSD license the source code for Swift by the end of the year, given that they have been almost single-handedly sponsoring the framework (and employing the main developers) it's built on, LLVM, for years now - keeping it open source when there's no license requirement for them to do so.

Re: Smashing Swift

#106
post #30

Still, I look at the Swift with a low-level colored glasses: I don't care if this or that category theory aspect is covered or not. I don't care if you can imagine some nicer syntax for something (everybody can). I really care how good and how often Swift can be used instead of C, not being slower and not using more resources. I know, is nicer. But for me, if it has GC, it's a no go. I see Swift as something where I…

Note: My post was an answer to some of the comments appearing here and not the response to the original article, which wasn't so negative as the mentioned claims.

Re: Smashing Swift

#107
post #55
post #52

Earlier quoted context omitted.

Apple GUI development is obviously a major constraint. Another is: no GC in order to avoid the collections happening when they want and thus making the smoothness of the UI impossible. I still claim there isn't at this moment any more innovative language that can provide that what Swift provides, observing any GUI platform you want to observe: meaning that level of support for the platform's native GUI with that perf…

> meaning that level of support for the platform's native GUI with that performance and elegance. Seems like that criteria would bias the choice of most innovative language quite heavily towards languages developed for/by Apple, no?

Wow, when I went to bed this comment was at 2 karma. Now it is at a negative (-3) and so are all the comments in this chain of replies that was critical of Apple's product, when before they were not greyed out. Fancy that. :)

Re: Smashing Swift

#108
post #95
post #57

Earlier quoted context omitted.

/wow More please ! Also guys, please check this new submission. https://news.ycombinator.com/item?id=7895901 Alice and Bob play a cryptographic tetris game. Some french phd bloke has written it.

Would you please stop putting "/word" at the top of your comments? Gimmicks like that don't work here.

/love

It is a pattern, yes. Let me show you a pattern that I have observed in Hacker News and forums since the demise of USENET.

USENET had an elegant way of ignoring without hellbanning, which the negative karma has done to me now.

Would you please study the history of Stalinism ?

Let me summarise it for you.

Ideology -- pg.

Yeah, Marx is a good guy too.

It is made of dictators and the inner ring -- Admins and Karma users like you. These people have special "powers" of punishment.

Admins have far greater powers of purging and renaming things.

Then the party cadre -- people who submit and actually keep the things in motion. They are usually not aware of the "inner ring", users like you. They want to help the lay people.

In fact no one even knows who is in the inner ring. The inner ring is clueless of the Admins.

Then there are lay users like me, who lurk around and want to help but are generally punished.

If you think I am shitting you consider the rate of new users becoming high karma users in HN over the years.

You can use d3 and it will go the top of HN.

Your pedantry is just arbitrary. There is nothing really substantial in it. Rather than judging on the basis of content, you are judging me on the "words" I use.

Gimmick: An ingenious or novel device, scheme, or stratagem, especially one designed to attract attention or increase appeal.

Why thank you, it is novel :)

Please understand the democratic roots of the word "forum" and take it seriously.

Re: Smashing Swift

#109
post #101

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

You can't do it directly, but there is a standard idiom for doing something like that - define the interface like this:

  interface Functor>
And then in the implementing class, bind R to the implementing class:

  class Option implements Functor>
However, this doesn't let you write an actual functor. Try to write the map method on it:

    class Option implements Functor> {
        private final A value;
    
        public Option(A value) { this.value = value; }
    
        @Override
        public  Option map(Function fn) {
            // er, i want to return an Option, not an Option
        }
    }
The problem is that you don't want to return an instance of the type of the receiver, you want to return an instance of a similar type with a different type parameter (Option rather than Option).

You would be absolutely fine if your functions were functions from values of some type to other values of that type (eg functions from integers to integers), because then A = B and you can get away with this. But there's no way to extend this hack to let you return an Option from map.

The closest you can get in Java is probably this:

    interface Functor>

    class Option implements Functor> {
        private final A value;
    
        public Option(A value) { this.value = value; }
    
        @Override
        public  Option map(Function fn) {
            return new Option(value != null ? fn.apply(value) : null);
        }
    }
There, you leave the element type of the returned functor undefined, as a wildcard, which lets you slip an Option out as a return value.

The problem with that is that it's useless. Given:

        Option x;
        Function fn;
Then mapping the function over the option gives you:

        Option y = x.map(fn);
An Option. Which is no use to man or beast, because it's lost the type information.

What you really want to be able to write is:

  class Option implements Functor>
Where the underscore is borrowed from Scala to mean "nothing to see here, move along please", and leaves that reference to Option in its unbound form. And then have a way of binding it right in the definition of the map function. But that's higher-kinded types, and Java doesn't have that.

If you were absolutely desperate to do this in Java, like if terrorists burst in and put a gun to your head and told you to do it, you could restore the type information by pebble-dashing the functor with some simple reflection:

    interface Functor> {
         R map(Function fn);
         Functor as(Class b);
    }

    class Option implements Functor> {
        // other stuff as above
    
        @Override
        public  Option as(Class b) {
            return new Option(b.cast(value));
        }
    }
Which, given the above definitions of x and fn, lets you write:

        Option y = x.map(fn).as(Integer.class);
And even the same thing but typed as functors, to show you there's nothing up my sleeve:

        Functor> fx = x;
        Functor> fy = fx.map(fn).as(Integer.class);
And as a separate function which contains no mention of the concrete functor class anywhere (although it does still need a type token for the result functor's parameter):

    private > Functor applyAbstractly(Functor fx, Function fn, Class b) {
        return fx.map(fn).as(b);
    }
But to be honest, all of this is a bit like trying to carve a fine wooden sculpture with a chainsaw. If you want to do this, don't use Java. If you want to use Java, don't do this.

Re: Smashing Swift

#110
post #84
post #30

Still, I look at the Swift with a low-level colored glasses: I don't care if this or that category theory aspect is covered or not. I don't care if you can imagine some nicer syntax for something (everybody can). I really care how good and how often Swift can be used instead of C, not being slower and not using more resources. I know, is nicer. But for me, if it has GC, it's a no go. I see Swift as something where I…

As a fairly inexperienced programmer, can someone please explain why everyone is so happy there is no garbage collection going on? Shouldn't that be something we would want? (Is it because control over this allows us to do extra things?)

There's a helpful bit of writing about garbage collection on http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...

It boils down to there being a big performance penalty on garbage collection in memory-constrained environments.

Post reply on HN