Earlier quoted context omitted.
Is it realistic to try to dive right in to the 500-page book they provided without a computer science background, just HTML/CSS/PHP self-taught experience, to learn the language? Or should I take other steps first?
Just read the first paragraph and conclusions if the have them, of each chapter. This will give you a good idea of what's there when you need it. Then I'd jump straight into tutorials. Honestly skimming 500 doesn't sound horribly hard to me. I've done that a few times to pick up something new. As ap said you won't learn the language like that but you will have a good reference to go and learn from after the fact. Aft…
The Swift Programming Language
641–650 of 970 posts
Re: The Swift Programming Language
#642I really wish we could play with it, without having to be a paid member. It's crazy how Apple is always so scared to release dev tools, at the end it will be out-there on bittorrent anyway...
Visual Studio isn't free in that regard either. What exactly are you comparing this release to?
Re: The Swift Programming Language
#643Earlier quoted context omitted.
Indeed, I'm not sure what Swift's concurrency story is yet. Other than that it's encouragingly similar to Rust (we're evolving in the right direction!), but not quite as low-level.
The similarity to Rust should scare the hell out of Rust's creators and proponents. Swift could very well render Rust almost totally irrelevant within the OS X and iOS sphere of software development. If we end up eventually seeing Swift implemented for other platforms, then the chances of Rust's long-term success diminish even more. Things might have been different had a stable, even if somewhat imperfect, initial ve…
We're not scared in the slightest. I'll reconsider when Swift has inline ASM, allocators, linear types, move semantics by default, region analysis, and a type system that guarantees freedom from data races (oh, and when the code is open-sourced, and targets both Linux and Windows as a first-class citizen).
Swift isn't intended to be a systems language: it's an application language. Anyone who's capable of choosing Swift as of today was just as capable of choosing Objective-C yesterday. And as the Rust developers themselves have discovered over the past two years, deciding to become a systems language doesn't happen overnight.
(In fact, on a personal note, I'm ecstatic that Swift has been announced. ADTs! Optional types! Pattern matching! Think of how many features are no longer alien to people who want to learn Rust! And hell, the syntax is incredibly similar as well, which further reduces friction. As a hardcore Rust contributor, I want to shake the hand of each and every one of Swift's designers.)
Re: The Swift Programming Language
#644Earlier quoted context omitted.
From a user's point of view, it's basically straight out of the Rust book, all the gravy with also relaxed ownership and syntax. It has it all [1]: static typing, type inference, explicit mutability, closures, pattern matching, optionals (with own syntax! also "any"), generics, interfaces, weak ownership, tuples, plus other nifty things like shorthand syntax, final and explicit override... It screams "modern!", has a…
Indeed, I'm not sure what Swift's concurrency story is yet. Other than that it's encouragingly similar to Rust (we're evolving in the right direction!), but not quite as low-level.
Re: The Swift Programming Language
#645Earlier quoted context omitted.
Is it realistic to try to dive right in to the 500-page book they provided without a computer science background, just HTML/CSS/PHP self-taught experience, to learn the language? Or should I take other steps first?
Just read the first paragraph and conclusions if the have them, of each chapter. This will give you a good idea of what's there when you need it. Then I'd jump straight into tutorials. Honestly skimming 500 doesn't sound horribly hard to me. I've done that a few times to pick up something new. As ap said you won't learn the language like that but you will have a good reference to go and learn from after the fact. Aft…
Re: The Swift Programming Language
#646"...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…
Some will say Rust, but we're years away from that being realistic. C++, using modern techniques, is perhaps the only feasible response.
While there may be some validity to your claim about "billions of human beings wasting hours" due to vulnerabilities in C code, we can't forget that the alternatives would also suffer from significant forms of waste.
If using a language with slower runtime performance, for example, people will need to wait longer for their computations to complete. More powerful, or even just more, hardware will be needed to alleviate these delays. Slower runtime performance also often results in much higher energy consumption. The costs just keep adding up and up.
Forcing billions of people to use far less efficient software, while requiring far more powerful hardware, on a continual and ongoing basis, for decade upon decade, could very well generate waste that far, far exceeds that of dealing with an occasional flaw in widely-used C code. I just can't seriously buy your "All the performance benefits ever derived from writing everything in C has been more than erased, by orders of magnitude, by the damage caused from even simple innocent mistakes." argument.
C won't be going anywhere until somebody provides a practical alternative that offers benefits without any downsides. It's as simple as that.
Re: The Swift Programming Language
#647As someone who always disliked Objective C, I think Swift looks very promising. I'll check it out right away :) Software-wise, I feel these current WWDC announcements are the most exciting in years. Looking at the Swift docs right now, I can see many interesting inspirations at work: there's some Lua/Go in there (multiple return values), some Ruby (closure passed as the last argument to a function can appear immediat…
From a user's point of view, it's basically straight out of the Rust book, all the gravy with also relaxed ownership and syntax. It has it all [1]: static typing, type inference, explicit mutability, closures, pattern matching, optionals (with own syntax! also "any"), generics, interfaces, weak ownership, tuples, plus other nifty things like shorthand syntax, final and explicit override... It screams "modern!", has a…
The optional type stuff is good, and it will definitely be a net safety improvement, but it's by no means attempting to approach a panacea to safety like Rust's strict static analysis does.
Particularly that Swift gives you really simple outs in the form of the '!' unwrap and 'as' (should be 'as!' at least imo) downcast-and-unwrap operators that result in run-time errors and will probably be seen as unremoveable code-smell in a couple of years.
Re: The Swift Programming Language
#648- function-level type inference much like Rust
- no constness in the type-system (I like it)
- class are reference types, structs are values types, much like D and C#
- runtime dispacthed OO interfaces called "protocols". Blend the difference between runtime or compile-time polymorphism. Classes, structs and enums can implement a protocol. Available as first class runtime values, so the protocol dispatch will be slow like in Golang.
- enumerations are much like Ocaml ADT, can be parameterized by a tuple of values, value types, recursive definitions (nice)
- worrying focus on properties.
- strange closure syntax
- optional chaining, another anti-feature in my eyes
- normal arithmetic operator throws a trap on integer overflow (!). This must be incredibly slow.
- looks like Array is a fat slice to a reference-counted array
- operator overloading is in, supercharged with custom operators, custom precedence (!?)
- builtin tuples syntax
- break with C integer promotion, like Rust.
- no pointers
- convenience is a keyword!
- no exceptions (!)
- unsigned integers: check
- type inference is "bidirectional by expression or statement"
- classes have deterministic destructors, structs have no destructors
- It seems the only RAII source is through RC and classes.
- no single root class
Make your own opinion.
Re: The Swift Programming Language
#649Earlier quoted context omitted.
Indeed, I'm not sure what Swift's concurrency story is yet. Other than that it's encouragingly similar to Rust (we're evolving in the right direction!), but not quite as low-level.
The similarity to Rust should scare the hell out of Rust's creators and proponents. Swift could very well render Rust almost totally irrelevant within the OS X and iOS sphere of software development. If we end up eventually seeing Swift implemented for other platforms, then the chances of Rust's long-term success diminish even more. Things might have been different had a stable, even if somewhat imperfect, initial ve…