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

91–100 of 150 posts

Re: Smashing Swift

#91

Post by gress »

bobbles wrote: post #84
acqq wrote: 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?)

Garbage collection causes problems with memory pressure and pauses.

ARC is very little different for the programmer, but suffers less from these problems and is easier to integrate with C language code.

No reason for GC.

Re: Smashing Swift

#92

Post by gress »

blahber wrote: post #22

/annoyed I Agree with what Chris Granger said in https://twitter.com/ibdknox/status/473912605350719488 . I think Rust is a good example of developing a language in the open. That said it's great to see Bret's ideas see more implementations.

If you 'agree' with Chris Granger, perhaps you can name one of the mistakes.

Also - what good is Rust being developed in the open if it can't be used for production apps yet?

Re: Smashing Swift

#93

Post by Chattered »

skybrian wrote: post #78
Dewie wrote: post #74

Earlier quoted context omitted.

What discipline did the word "map" come from? ;) Is "map" even descriptive? In a programming concept, the first time I heard it I thought it was referring to the data structure of the same name, which is pretty different.

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 parsers are functors. If I replaceEach a parser, what have I replaced? The results of the parse? The parser hasn't been run on an input yet. Maybe it never will.

If I replaceEach a promise, what am I replacing? The result of the promise? Maybe the promise will be forever blocked, or maybe I'll cancel it.

If I replaceEach a continuation, what am I replacing?

Re: Smashing Swift

#94

Post by hamstergene »

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…

I think you (and @twic in discussion below) misunderstand what's going on here.

`class Bar : Foo` is exactly the same as `class Bar : Foo`. The identifier `String` in declaration of `Bar` does not refer to built-in type String, it is a tag for any type.

In other words, you CAN have `Bar`, `Bar` and `Bar` after using that declaration of `Bar`.

Re: Smashing Swift

#95

Post by dang »

blahber wrote: post #57
twic wrote: 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…

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

Re: Smashing Swift

#96

Post by twic »

skybrian wrote: post #78
Dewie wrote: post #74

Earlier quoted context omitted.

What discipline did the word "map" come from? ;) Is "map" even descriptive? In a programming concept, the first time I heard it I thought it was referring to the data structure of the same name, which is pretty different.

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

Exactly. We'd only call the interface 'Mappable' if the method was called 'map', and that's something that's come from mathematical terminology.

(I'd probably have called the 'Map' class 'Dictionary', if that hadn't already been taken!)

I'd avoid 'replaceEach', because it sounds like it mutates the receiver. Maybe 'withEachReplaced'? Way clunky. In Smalltalk, this method is called 'collect', which is better than 'map', to my eyes, but still not all that obvious [1].

[1] Smalltalk has the names collect, inject, select, and reject for its map, foreach, filter, and complementary filter methods, because of a song: http://smalltalkzen.wordpress.com/2011/02/02/arlo-guthrie-an...

Re: Smashing Swift

#97

Post by nnq »

archgrove wrote: post #9

Compiler bugs really don't worry me - despite the name, this is is really an alpha release. 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. The primary vibe I'm getting from Swift is pragmatism . They had variou…

> must be as fast as Objective C; must have a minimal to non-existent runtime (so AOT compilation all the way); mustn't have garbage collection, must interoperate with Objective C/normal C with ease; etc.

This sounds and awful lot like what C++11/14 would bring, with a few platform specific extensions... but then again, no vendor, and especially not Apple, likes the thought of working with a language that's really trying to be cross-platform and a language that "rewards smart programmers" ( http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Key... ), as opposed to being easy-to-teach or idiot-proof...

Re: Smashing Swift

#98

Post by hit8run »

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

Re: Smashing Swift

#99

Post by baddox »

mikeash wrote: post #83
archgrove wrote: post #21

Earlier quoted context omitted.

Apple did add garbage collection to Objective C, but it only lasted a few years before being pulled. Two less important reasons are that it's hard to integrate with the otherwise trivial C(++) interop, and the frameworks just weren't designed for it. To me, the more important answers are deterministic destruction, and no GC pauses. All of Objective C is reference counted these days, with retain/releases inserted by t…

To be fair, reference counting isn't strictly deterministic either. The moment you mix in multithreading or call out to code you don't control and whose refcounting behavior could change over time, you can no longer know when an object will die. As for memory pressure, reference counting does generally behave better, but in some situations you can end up doing much worse. If you manage to generate a lot of autoreleas…

I'm not very familiar with the implementation of programming languages, so maybe the terminology is subtly different, but how are either of those situations not deterministic?

Re: Smashing Swift

#100

Post by dignati »

gress wrote: post #92
blahber wrote: post #22

/annoyed I Agree with what Chris Granger said in https://twitter.com/ibdknox/status/473912605350719488 . I think Rust is a good example of developing a language in the open. That said it's great to see Bret's ideas see more implementations.

If you 'agree' with Chris Granger, perhaps you can name one of the mistakes. Also - what good is Rust being developed in the open if it can't be used for production apps yet?

Because it's not expected to be developed in the open ever and will therefore never be useful for production apps?
Post reply on HN