811–820 of 970 posts
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?
I'm 20% in, and you certainly should give it a try. It's very well-written, explains basic concepts really well, and has a lot of examples. It also has a good flow from the basc features to more advanced ones.
I just skimmed the tour, and my impression is: Swift is a compiled, Objective-C compatible Javascript-alike with an ObjC-like object model, generics, and string interpolation. No exceptions. Based on LLVM and appears to inherit the same data structures as Cocoa apps (Dictionaries, Arrays, &c). It feels very lightweight, sort of like an analog to what Javascript is in a browser.
I see the standard static FP features (from ML, Haskell, Scala, F#) with the syntactic flavor or Rust and some C# tossed in.
Earlier quoted context omitted.
This is an honest question: Why do you seem to care so much? Rust is in my view a great project, that yes isn't quite there yet but is making great progress. I'm looking forward to using it when it is stable, and pcwalton and the other contributors are developers that I've looked up to for a number of years: I have nothing but faith in them. At the end of the day, if Rust fails, well that will be a shame. But I'm see…
Having been in industry for a long time, I think that something like Rust would be hugely beneficial. It very well could solve some very real problems. I bring this up again and again because I'd rather not see Rust fail. I'd much rather see a slightly flawed Rust that's actually usable in the short term, rather than a continually changing Rust that nobody will seriously adopt. Rust has been in development for years…
I don't have much to say about D, but the history of Haskell implied by this sentence is hilariously wrong.
Go watch Simon Peyton Jones' talk about the history of Haskell: http://research.microsoft.com/en-us/um/people/simonpj/papers.... As well as being wonderfully entertaining, it explains the actual history of Haskell: it was designed to be a language with which various academic groups could do functional programming language research. The fact that Haskell has gradually grown more popular and now has mainstream appeal and some industrial users is quite a surprise to its creators.
We're writing a story for The Next Web on Swift. If anyone's interested in being interviewed for an article, can you flick me an email on owen@thenextweb.com with brief answers to some or all of the following questions. I'd love to talk to anyone who's used Objective-C before and share your opinions/experience: 1) How does Apple releasing Swift make you feel as an Objective-C developer? 2) Are you excited to code usi…
Earlier quoted context omitted.
My dislike is that it uses [] for method calls. It's like making Objective-English where we swap Z and A and j for o, just for the hell of it. If thzt sjunds like fun tj yju, thzn gj fjr Jboective-C.
This is in my opinion the best thing about Objective-C; it clearly delineates the object/class and C dichotomy, making it easier for a C programmer (or a Smalltalk programmer!) to pick up. For years, the only changes from vanilla C were the brackets, "#import" and the @ literal syntax (IIRC).
I'm not even an iOS developer but this is by far the most exciting thing I heard in the keynote. As an amatuer/hobbyist programmer who's self-taught with Ruby, JavaScript, etc., the one thing that was keeping me from experimenting with iOS apps was Objective-C. I know I could tackle it, but it's been hard to take the plunge. I don't know much about Swift yet, but from what I've seen it looks very exciting. So if Appl…
I don't get the hate. Yeah, syntax is unfamiliar, bu once I got used to it I began to really enjoy objective-c. Ymmv etc., but it's now one of my fav languages - though I guess this is mostly due to cocoa
There have been a lot of C-based object-oriented APIs over the years. GObject has a C API. On the Mac, there's Core Foundation and a bunch of other OS X APIs that are built on top of it. For over a decade on X11, before gtk and Qt even existed, the closest thing there was to a standard graphical environment was Motif (the corresponding desktop environment was CDE), and Motif was built on top of Xt. Xt was yet another C-based object system, although it was specialized for designing UI components.
This is all well and good but you end up with a ton of boilerplate code that does nothing but manage the lifecycles of the object instances (retain/release for example), and lends itself to extremely verbose function calls in place of object methods.
One possible solution is to put together some really elaborate preprocessor macros to make it look like you have extended the C language to include special syntax for your object system, so you can at least replace this:
obj foo = obj_factory(); int c = obj_getNumberOfElements(foo);
...with something more compact like this:
obj foo = [Obj new]; int c = [foo numberOfElements];
(the second example is ObjC-ish but the former is nothing in particular other than just what the typical C object APIs tend to look like)
The only catch is that the little mini-language you are extending C with using macros can't use existing C syntax, because you can only add to the language, not alter the behavior of existing operators. So, you can't just do method calls using a dot syntax on the instance (such as foo.numberOfElements()). So, you have to come up with something new. Maybe you always liked Smalltalk, and maybe you even based much of behavior of your object system on how Smalltalk objects behave and interact? If so, you might settle on the bracket notation. This has the added benefit of making it very clear when a chunk of code is run-of-the-mill C versus when the code is triggering the syntactic sugar you created with macros to add support for your object system to the C language.
C++ doesn't exist yet, or else you might've just gone with that instead of rolling your own thing. Eventually C++ does exist, and you start to feel a little primitive for sticking with the weird macro language. You eventually build your mini-language into a C compiler so you don't have use the macros anymore. You experiment with some new alternatives to the syntax that are more conventional, but no one uses them. Many developers like that the non-C-ish syntax makes it easy to distinguish between straight C code vs. interactions with the object system, which has its own set of rules and conventions.
Anyway, that's mostly speculation, but something like that story is how I've always thought Objective-C evolved over the years. I don't mind it nearly as much as long as I don't think of it as a separate programming language from C (like C++ or Java or pretty much anything else these days), but rather think of it as C with some useful syntactic sugar that gets rid of a ton of boilerplate code for a particular C-based object-oriented API.
Feels like they looked at a bunch of programming languages, took all their favorite features, and then put them into one which still sits on top of the ObjC runtime. And then added some Apple syntactic craziness. For example: var apples = 3; // mutable let oranges = 5; // immutable let summary = "I have \(apples) apples and \(oranges) oranges";
The language itself isn't radically different from most mainstream Algol style languages. That's good because it makes it pretty easy to pick up. In addition to what you mention on variables vs constants, the only feature which is nice seems to switch-cases. a. No fall through. This is a plus in avoiding bugs. This is minus if you really know what you are doing and want fall throughs b. Pattern Matching in case state…
Earlier quoted context omitted.
It does share Go's `func` keyword, parens-free conditionals, optional semi-colons
That's really not a lot. The optional semicolons could also be influenced by BCPL or JavaScript.
Yes, Swift's semantics are different (since it's essentially a domain-specific language designed to make writing Cocoa apps faster), but syntax-wise a Go programmer feels right at home reading Swift.
i.e.
enum BinaryTree = { case Leaf(Int) case Node(BinaryTree, BinaryTree) }
Earlier quoted context omitted.
This is an honest question: Why do you seem to care so much? Rust is in my view a great project, that yes isn't quite there yet but is making great progress. I'm looking forward to using it when it is stable, and pcwalton and the other contributors are developers that I've looked up to for a number of years: I have nothing but faith in them. At the end of the day, if Rust fails, well that will be a shame. But I'm see…
Having been in industry for a long time, I think that something like Rust would be hugely beneficial. It very well could solve some very real problems. I bring this up again and again because I'd rather not see Rust fail. I'd much rather see a slightly flawed Rust that's actually usable in the short term, rather than a continually changing Rust that nobody will seriously adopt. Rust has been in development for years…
Not for programming languages. These take years and years. Take a stab at any of the most popular languages. They weren't created 1-3 years ago. It takes time, and that's a good thing.