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…
The Swift Programming Language
781–790 of 970 posts
Re: The Swift Programming Language
#782Earlier 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.
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
#783Earlier 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.
Re: The Swift Programming Language
#784Earlier 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.
Re: The Swift Programming Language
#785Earlier 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…
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
#786I 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…
Re: The Swift Programming Language
#787Re: The Swift Programming Language
#788I 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…
Re: The Swift Programming Language
#789First question that comes to mind: how open is this language? (I can't find any references to it)
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.