Live data from Hacker News

The Swift Programming Language

developer.apple.com

781–790 of 970 posts

Re: The Swift Programming Language

#781

Earlier quoted context omitted.

My apologies, I didn't realize that expecting a programming language to have a stable syntax, stable semantics, a stable standard library and at least one stable and robust implementation before using it seriously in industry was merely a "game". Perhaps this is news to you, but those of us who work on and are responsible for large-scale software systems tend to take such factors very seriously. This may sound harsh,…

You seem to desire both stability and a faster 1.0 release. The realistic choices are: 1. Release fast and iterate 2. Release fast and be stuck with mistakes 3. Release slow Option #1 breaks stability, so that's out. Swift appears to be taking option #2 (Apple doesn't commonly break APIs, do they?), but we can't even really be sure because it hasn't been developed in the open the way that Rust has. It's possible that…

Apple just announced in the Platform State of the Union that they won't guarantee source compatibility until Swift is released along with iOS 8 (changes to the language will require source conversions), so I believe they're taking a route closer to option #1.

Re: The Swift Programming Language

#782

Earlier quoted context omitted.

I'd prefer to see how it fares in the real world before jumping to such conclusions like you seem to be so willing to do. You may not have been around to experience it first-hand, but we heard a lot of claims made back in the 1990s about how Java and the JVM would increase security and safety. The arguments made then even overlap with some of those being made in this case! The lack of direct pointer access and manipu…

And you're telling me... with a straight face... that Java's lack of direct pointer access, automatic memory management and bounds checking do not make it safer and more secure compared to C and C++? You really should stop talking.

That's obviously not what I wrote, and you would know this had you bothered to read my comment.

I'm saying that such features alone do not actually guarantee safety, if the language's implementation happens to have flaws.

There hasn't been sufficient time and opportunity to see what Swift is like in practice. It's premature to say anything conclusive about it at this point, aside from stating that we don't yet have enough information about it.

Re: The Swift Programming Language

#783
post #440

Earlier quoted context omitted.

I have to agree. I had a love affair with unicode put directly in LaTeX markup (delta, integral signs, element-of, etc...) and it was very fun at first. Then I had to send the paper to a collaborator while writing a follow-up article together. I ended up removing all the unicode, and in subsequent work I didn't do it any more.

Why would you want to put math symbols in LaTeX using unicode? What would be the advantage over using a package like amsmath or even the native math environment? I'm genuinely curious.

Because then instead of writing \int, you can have an actual integral sign, etc., and it's more readable.

Re: The Swift Programming Language

#784

Earlier quoted context omitted.

I really don't see the Golang influence at all. The multiple- return- value semantic is closer to Ruby's than to Golang's; you're returning a tuple, which happens to have natural syntax in the language. Defining Golang features that don't exist in Swift: - Interface types with implicit adoption (Swift takes explicit protocols from ObjC) - Error types - Relatedly, the "damnable use requirement" and its interaction wit…

(I like what I've read about Swift and expect to be building things in both Golang and Swift, and often at the same time). How about a blog series where a developer implements something in Golang and/or Swift, then you explain how it's insecure? Then the developer tries to fix it and you explain something else that's insecure. Rinse, repeat.

I thought that was called "Hacker News comments."

Re: The Swift Programming Language

#785

Earlier quoted context omitted.

And you're telling me... with a straight face... that Java's lack of direct pointer access, automatic memory management and bounds checking do not make it safer and more secure compared to C and C++? You really should stop talking.

That's obviously not what I wrote, and you would know this had you bothered to read my comment. I'm saying that such features alone do not actually guarantee safety, if the language's implementation happens to have flaws. There hasn't been sufficient time and opportunity to see what Swift is like in practice. It's premature to say anything conclusive about it at this point, aside from stating that we don't yet have e…

The "flaws" discovered in Java aren't in the language, but in the most popular JVM implementations, most of which - surprise - are implemented in C (for the lack of a better alternative).

Writing in Java still remains monumentally harder to fuck up in compared to writing all your code in C or C++.

Furthermore, while Java relies on said relatively complicated interpreter + JIT virtual machine for its execution, Swift has no such virtual machine. All code is analyzed statically and compiled to machine code. The Objective-C runtime which it uses (which is not new - it's the same fucking Objective-C runtime) is a tiny C library, which implements a few basic low-level routines, such as dynamic message-to-method resolution.

So next time it's best for you to shut your mouth if you're ignorant about an issue, than telling people who know better than you to "wait for conclusive evidence".

Re: The Swift Programming Language

#786
post #739

I find it a bit sad that with all of the languages that already exist, Apple found it necessary to invent a completely new one -- and then make it proprietary. Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.) Heck, they could have bought RubyMotion and made Ruby the high-level langua…

Probably because they wanted a statically typed language. Something that didn't require the JVM and not backed by Google..

Re: The Swift Programming Language

#787
Noob here. I don't understand... so what happens to Objective-C? Why would you code an iOS app with one language instead of the other? Why would you use both? That just sounds like a pain. Is Swift the evolution of Objective-C or something?

Re: The Swift Programming Language

#788
post #739

I find it a bit sad that with all of the languages that already exist, Apple found it necessary to invent a completely new one -- and then make it proprietary. Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.) Heck, they could have bought RubyMotion and made Ruby the high-level langua…

My sense is they wanted "Their" language, as opposed to Go (Google) or Java (Oracle) or another tied in to a vendor.

Re: The Swift Programming Language

#789

First question that comes to mind: how open is this language? (I can't find any references to it)

This is my problem with the language. The language looks really nice, and the interactive environment too, but I have no apple device to use it on. I would like it if there was at least a compiler for Linux.

I have the same problem with using c#/.Net (outside of work), it isn't a language I want to use at home or want to deploy onto a server.

Re: The Swift Programming Language

#790
A lot of commenters here are asking whether it will be open sourced, I'm curious, specific to those who think it should be open sourced: why? I'm not really curious about the philosophical reasons, but really the practical ones. How would Swift being open source help you as a developer? It's clearly targeted at iOS and Mac OS X, so does this mean you won't write Mac OS X or iOS apps if it's not open source, or did you hope that you could write Swift code on other platforms?
Post reply on HN