Live data from Hacker News

The Swift Programming Language

developer.apple.com

901–910 of 970 posts

Re: The Swift Programming Language

#901

Earlier quoted context omitted.

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…

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` will accept any object as a key, even though it will only work if the key is copiable and hashable, and it does mean that you could have keys of fundamentally different types in the same collection. Values can be heterogeneous too.

As far as type safety goes, Swift is on par with modern languages.

ObjC also inherited several security issues of the C language, like unchecked arrays and unchecked arithmetic. Swift performs bounds checking by default (you can manipulate raw arrays with `UnsafePointer`) and has checked arithmetic by default (you can allow overflows by prefixing the operator with `&`, so `&*`, `&+`, etc). It also never requires you to allocate and deallocate buffers yourself.

So Swift is more secure because it has no buffer overflows, no integer overflows (though they're more an issue when you have buffer overflows) and no unsafe memory management. These are by far the three most commonly exploited vulnerabilities in software.

Re: The Swift Programming Language

#902
post #840

Earlier quoted context omitted.

Including me, I think some syntaxes of Switft look like Go, while they actully don't share the same vision. Go tries to be a language great for system programming so it introduces channels, interfaces. But Swift want to help GUI programming and it needs the whole class system but without crazy stuffs like channels. But for others aspects that are not related these two(class system, concurrency), I would say they look…

For Go to be great for systems programming, the unsafe package needs a few more primitives and better control over the GC.

I don't know what this means. I've used Golang successfully for USB drivers, emulators, web and database servers, testing tools, a debugger, and cryptography. It seems evidently suited for systems programming as it stands.

Someone is always going to be out there saying that any language isn't ready for prime time because it lacks feature-X.

Re: The Swift Programming Language

#903

Earlier quoted context omitted.

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…

There's no real objective measure for either 'conciseness' or 'safety', in general terms. Whether or not it's faster in the real world is yet to be seen, and creeping featuritis has never been the hallmark of a great programming language. It makes good press release and marketing speak, but those assertions are a long way from making the OP 'wrong'.

There are objective measures. There aren't necessarily 'absolute' ones.

Lisp is relatively more concise than C or Java for the same tasks.

Java is relatively safer than C for the same tasks.

Re: The Swift Programming Language

#904

Earlier quoted context omitted.

It's fun once. It's impractical for someone editing the code later though, I don't want to have to look up the unicode character each time I want to remember it, and I don't want to have to copy and paste it either, it's better to stick with the characters available on a keyboard.

OS X handles some of this by assigning mnemonics to keyboard keys with the meta key (on mac keyboards, Option, or the "windows" key on the standard layout) held down. For instance, the registered trademark symbol ® is just option+r. ∑ is option-w. Diacritics are two-stroke combinations, to get é, you'd type option-e, which puts the ´ on the screen, and then type the e to complete the character. Some of them definitel…

"OS X handles some of this by assigning mnemonics to keyboard trademark symbol ® is just option+r. ∑ is option-w."

And, after they ran out of mnemonics, they sprinkled the rest of the characters on the keyboard (almost; I think they tried hard to keep things memorable, but some combinations are just plain of the "if you don't know it, you 'll never guess". The Apple logo is on the k key, for instance (IIRC). Mnemonic? MaKintosh?)

"Diacritics are two-stroke combinations, to get é, you'd type option-e, which puts the ´ on the screen, and then type the e to complete the character."

That's the old way. Recent OS X has 'hold down the e key, a menu pops up, click the desired variant or type the digit shown next to it'.

Re: The Swift Programming Language

#905

So, I picked up Objective-C a few weeks ago, and I've been struggling (only coming from a Python background, with only the CS-knowledge I've picked up along the way). I just figured it would be fun to be able to make some apps. What would your advice be? Stick with Objective C, or switch over to learning Swift? Swift looks a lot more friendly, but I don't want to sell myself short. I'm also thinking big picture, wher…

I know neither.

I'd skip Objective-C and learn Swift to actually make a thing.

If you want general language knowledge, a really hairy production language and toolset isn't the place to look. You'll be fighting with lots of incidental stuff along the way.

Learning different kinds of languages will help you learn more languages.

Re: The Swift Programming Language

#906

Earlier quoted context omitted.

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…

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.

For one, Swift avoids what Tony Hoare calls his Billion Dollar Mistake (conflating optionality and reference types). Because Tony Hoare introduced null references to Algol W, most Algol-derived and Algol-inspired statically typed languages since have made all pointers/references nullable. Some, like Java, have bolted on Lint-like null checkers an afterthought (see @Nullable, @NotNull) outside of the official compiler.

It's really nice to have the compiler not allow callers to pass null to functions where passing null wouldn't make sense, isn't useful, or the programmer was just too lazy to implement null checks. More than half of the functions I write have inputs where null wouldn't have an obvious meaning.

Objective-C's treatment of nil receivers is particularly handy for programming in the small and particularly bad for programming in the large. Sending a message to nil (similar to calling a method on null in many other languages) does nothing other than returning 0 cast to the type of variable you're storing the return value in. Chugging along accidentally accumulating nulls in many cases is worse than segfaulting and giving a nice stack trace.

Certainly in the realm of automated trading software, segfaulting when hitting a programming error is preferable to most other failure modes. Of course, failing to compile is often (though not always) the best failure mode.

Re: The Swift Programming Language

#907

Just glanced thru the Swift book in about 3 hours. Conclusion: all your programming language are belong to Swift, mostly stolen good ideas, some innovations, a few gripes. I can say Swift takes inspiration and improves on at least these languages: C: typealias struct control structures labeled statements AKA gotos varargs C++: default arguments class instance construction syntax // comment superclass, implementing pr…

Concurrency will probably be handled using Grand Central Dispatch's[0] queues. [0] http://en.wikipedia.org/wiki/Grand_Central_Dispatch

You're right. I can remember an example with something like:

dispatch_async(queue) { /* code here */}

That's an idiomatic adaptation to dispatch_async to support closures. I guess this internally might be converted to a block.

Re: The Swift Programming Language

#908
post #367

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…

The sad part, is that already in the 70's there were better alternatives, but UNIX creators just decided to ignore them and create their own language.

So they could implement SpaceWar on the PDP-11.

Re: The Swift Programming Language

#909
post #256

Earlier quoted context omitted.

You can do this in C# (and presumably other languages). I've seen people using Greek symbols in mathy code before. It's kind of fun.

It's fun once. It's impractical for someone editing the code later though, I don't want to have to look up the unicode character each time I want to remember it, and I don't want to have to copy and paste it either, it's better to stick with the characters available on a keyboard.

Bluntly, though, that's a deficiency in your OS user interface or text editor.

Re: The Swift Programming Language

#910

Earlier quoted context omitted.

> break-less switch, optional fall-thru Like Go and Dart?

There's actually a new keyword called `fallthrough`.

Interesting definition of 'new' you're using there.

http://golang.org/ref/spec#Fallthrough_statements

Post reply on HN