Live data from Hacker News

The Swift Programming Language

developer.apple.com

961–970 of 970 posts

Re: The Swift Programming Language

#961
post #939
post #302

Earlier quoted context omitted.

Looks like they took inspiration for the icon also. Look at the second to last icon on that page.

more likely both icons were inspired by the bird's distinctive silhouette

I hate to admit, but dumb me didn't realize this was a bird. I thought swift as in quick.

Re: The Swift Programming Language

#962

So it looks like the language isn't open source and won't target non-Apple runtimes? I'm not trying to troll, I just think that it's a pity that Apple tends to limit the ecosystem and applications of its otherwise-great languages. Building against LLVM ought to make it fairly trivial to make this cross-platform.

I can't even view the book about the language without having an Apple device or installing Apple software.

The book is ePub with no DRM. You don't need an apple device. You could download it on iTunes on windows, and read it with any ePub reader. if you don't want to install itunes i guess you could get a friend to email you a copy.

Re: The Swift Programming Language

#963

Earlier quoted context omitted.

It's not hate, but Objective-C can be intimidating.

I just spent the past 2 months learning obj-c, about to release my first app and boom, X out obj-c. my luck.

Objective C isn’t going anywhere.

Swift is shit. I suspect it will die in a couple years, like the misguided effort to get people to adopt the Java bridge or WebScript before that.

Re: The Swift Programming Language

#964

Enumerations (from: https://developer.apple.com/library/prerelease/ios/documenta... ): Unlike C and Objective-C, Swift enumeration members are not assigned a default integer value when they are created. In the CompassPoints example above, North, South, East and West do not implicitly equal 0, 1, 2 and 3. Instead, the different enumeration members are fully-fledged values in their own right, with an explicitly-defined…

>Unlike C and Objective-C, Swift enumeration members are not assigned a default integer value when they are created

Well that’s gonna make storing persistent values tricky.

Re: The Swift Programming Language

#965

You appear to be advocating a new: [ ] functional [X] imperative [X] object-oriented [X] procedural [X] stack-based [ ] "multi-paradigm" [ ] lazy [ ] eager [X] statically-typed [ ] dynamically-typed [ ] pure [X] impure [ ] non-hygienic [ ] visual [ ] beginner-friendly [ ] non-programmer-friendly [ ] completely incomprehensible programming language. Your language will not work. Here is why it will not work. You appear…

While half of the things you checked in that copy-paste are wrong, let me take the bait and say why it will work: - it's not just an arbitrary language, it's the new officially sanctioned programming interface for Apple's gigantic, wildly profitable ecosystem - it's much more concise than Objective-C - it's faster than Objective-C - it's safer than Objective-C - it has more features than Objective-C - ...yet it's ful…

1) So was Java for a bit. It sucked. Developers ignored it.

2) UIApplication.sharedApplication.delegate vs UIApplication.sharedApplication().delegate - nope. It isn’t more concise. It appears to be a wee bit more verbose.

3) Some benchmarks on the web are saying otherwise. It adds extra bridging and ARC for numbers. I don’t see how it can be faster and even if it is - nobody cares about speed. If I need to beat it, I can drop to C, IMP cache, and kick Swifts sorry little ass.

4) Safer - like the TSA says flying without nail clipp ers is safer? It doesn’t solve any problems I actually have. I think my last type error was in 2005 - took about a minute and a half to find it. I routinely work in dynamically typed languages and avoid static typed languages like the plague they are. I’m not opposed to type annotations when they help, but these just look like cargo cultism - like a lot Swift’s silly “features”.

5) It has less features where it counts - basically a less capable object model, weaker meta model, and more budensome interaction with C code than Objective C and a number of useful Objective C features have been walled off. I have Objective C code that cannot be written in Swift.

6) Except for that kind of dynamic stuff like performSelector: afterDelay: withArguments: and that pesky NSInvocation that isn’t available.

There are better projects around than this pile of crap. I will not be porting anything. Quite a lot of code I have can’t be ported.

Java killed WebObjects. Lets not let Swift kill Cocoa.

Re: The Swift Programming Language

#966
post #52

"...we wondered what we could do without the baggage of C." Is that tongue in cheek? It's not even a particularly large, encumbered language, C.

Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. That's billions of human beings wasting hours either changing all their passwords or having their money, identities, medical records, and more stolen because they didn't. Having their accounts hijacked. For all we know tot…

>Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C.

You can write shit code in any language - even Swift.

>how about goto fail?

I haven’t seen a goto in 20+ years. Strawman much?

>C is like saying "forget seat belts, child seats, anti-lock breaks, and adaptive steering! How can I power-slide? I want full control; I need to pump the breaks. People should just drive better, then we'd have fewer accidents”.

Yeah, and I suppose you’d prefer lumberjacks use rubber axes so they wouldn’t hurt themselves - or the trees for that matter. Life is dangerous. Get over it.

>At some point we have to admit C is no longer acceptable.

You bubble wrap your kids and lobby for lower jungle gyms at your kids schools too?

Swift doesn’t solve these problems and you sound like a self righteous ninny.

But hey - thats why there are scripting languages - for people who can’t deal with the machine. Pick one and go for it - but your scripting language isn’t suitably performant for things like audio processing (CoreAudio is in C/C++), real time control with tight tolerances, etc.

Grow the fuck up.

Sometimes you have to get your hands dirty and think hard and make stuff work. Your Swift code isn’t actually “safer” in the same way that the TSA hasn’t made flying safer - it is all security theater.

Re: The Swift Programming Language

#967

Earlier quoted context omitted.

Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. That's billions of human beings wasting hours either changing all their passwords or having their money, identities, medical records, and more stolen because they didn't. Having their accounts hijacked. For all we know tot…

>Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. You can write shit code in any language - even Swift. >how about goto fail? I haven’t seen a goto in 20+ years. Strawman much? >C is like saying "forget seat belts, child seats, anti-lock breaks, and adaptive steering! Ho…

> you sound like a self righteous ninny [...] Grow the fuck up

Personal attacks are not allowed on Hacker News. Please don't post anything like this.

Re: The Swift Programming Language

#968

Earlier quoted context omitted.

How is Swift safer than Obj-C? I'm not sarcastic or anything by the way, I just don't understand yet the foundation behind that statement.

Are we talking about type safety or general security? Either way, Swift does better than ObjC in both regards. ObjC was exceptionally type-unsafe. Any object type could be implicitly converted to and from the `id` type: NSString* foo = @"hello world!"; id bar = foo; // no warning NSDictionary* baz = foo; // no warning The Foundation collections all used `id` for the values and keys when they had keys. `NSDictionary`…

Dynamic typing is not "type unsafe". Objective C objects are completely "type safe". They are actually true objects in that they can receive and potentially handle any message sent to them.

This is an advanced but powerful feature and is in fact exactly what Dr Alan Kay meant when he coined the term "Object Oriented". Any system that has abstract data types that does not have a default message handling capability is not actually "Object Oriented" and the "type safety" brigade strikes me as a bit like depression era prohibitionists. They can't handle it so nobody should have it.

The "type safety" thing is a myth. I have worked on colossally sized systems written in PERL/Mason, PHP, Ruby, Smalltalk, Java, and C++. You'll note that all but the last two are "type unsafe" by your definition and yet I think my last "type related" error was sometime around 2003.

Also, not all collections are meant to be homogeneous.

>ObjC also inherited several security issues of the C language, like unchecked arrays

Objective C developers use NSArray and NSString. Raw arrays and pointers to raw memory are beyond exceptionally rare in Objective C. This is just more prohibitionist propaganda. In the cases where there really are raw memory accesses - you need them - but for the most part Objective C provided safe alternatives and were used heavily (NSData for instance rather than raw arrays and NSString instead of arrays of char).

Nobody is going to do audio or video processing in Swift. The CoreAudio team used C/C++ because when you need performance, you need performance and bounds checking is inefficient.

I heard this sermon from the C++ people in 1992, and then the Java people in 1998 - there's nothing new here and the myth of "type safety" vs "type unsafe" still isn't really true. It is just a lot of baggage and lost capability we are being sold here.

Raw C is potentially unsafe. Objective C - not so much. You can write quite a lot without even using a pointer (apart from id - a safe dynamically typed pointer).

Re: The Swift Programming Language

#969

Earlier quoted context omitted.

I think you're putting words into his mouth, and perhaps intentionally misrepresenting what he wrote. Swift was announced just a few hours ago. While we can make assumptions about its safety based on its feature set, or we can assume that the very vague performance details Apple provided are valid in a real-world setting, none of this has really been tested or verified independently yet. What cratermoon wrote is perf…

I'm not misrepresenting what he wrote, I'm directly responding to it. While you may not be aware with recent language development and modern LLVM-based languages in general, to me and many others what was announced at WWDC today wasn't just a set of buzzwords and marketing speak. Anyone who has been into language design and watched the keynote today can make a pretty good guess about the properties of Swift. There's…

And quite a bit behind in flexibility and dynamism.

Giant step backwards. Vtables? I don't think so.

override keywords? WTF? Its not so much they removed the C as the "Object".

Re: The Swift Programming Language

#970

I'm reading the manual and liking nearly everything. But then I stumble across: > Alternatively, remove a key-value pair from a dictionary with the removeValueForKey method. Is that the day where an Objective-C got to choose method names? Why not dict.delete() or similar?

You mean an API than you can actually read and understand? How dare them take your 1970s 80-char display away from you!

You mean a methodNameThatOverlyExplainsEverythingEvenThoughTheContextMakesItClear()?
Post reply on HN