I'm not buying this. It basically says "there are a few concepts in Ruby that map nicely to Swift". There are quite a lot of concepts that don't map, for example evaluated classes, which enable things like:
class Foo
include Virtus.model
attribute :foo, String
end
Now, I could go on like this, but that would be moot. I just question the basic premise of saying that just because 5 features match somewhat nicely (even if it involves more braces of different kinds), those would be reasons for Rubyists to love Swift. Much in contrast, similarity might not be the most compelling reason to switch to something different.
The thing that's interesting about optional binding is Swift is that it is a special construct for unwrapping optionals, not a normal assignment. If you try to bind to something that is not an optional using that syntax, it won't work. For example:
if let currentUserIsAuthorized = true { // COMPILE ERROR
...
}
This makes it useful for the one case where you'd actually want it without introducing any pitfalls, because using it incorrectly will be a syntax or type error.
if current_user = find_current_user
notify_user(current_user)
end
Funny to see an anti-pattern in C/C++ so lauded in another community.
Also, you know what I like about Ruby? I can write it and it'll run everywhere, and it is maintained by a vibrant community effort. Where's that on this list?
You realise that you're talking about a prerelease, right? The language hasn't even been available to developers for a month yet, let alone the general public.
I could be wrong, but I believe the parent is referring to the inability for a "vibrant community" to maintain Swift as a language implementation (instead of Apple), which is very different than Ruby. There's no doubt in my mind that there will be swarms of people developing with the language, but AFAICT, we'll mostly only see Apple developers working on the language itself.
>There's no doubt in my mind that there will be swarms of people developing with the language, but AFAICT, we'll mostly only see Apple developers working on the language itself.
Well, it's not like there's a "vibrant community" working on Ruby either.
AFAIK, the core developers are Japanese ( http://rubycoreteam.heroku.com/ ) and the core communication and decisions is mostly opaque to outsiders, and new language stuff mostly comes in bunches pre-formed.
As opposed say to Python and the PEPs discussion, PHP etc.
I entirely disagree. As most all open source projects, Ruby has a set of core contributors, but is clearly open to community contribution, as can be seen from their Git repo's history (https://github.com/ruby/ruby/network). And no, core communication and decisions are NOT opaque to outsiders, as is the usual case with most open source software (Google groups, mailing lists, IRC channels, etc). And lastly, language features and design is a product of the RubySpec, which is itself a Git repo for people to contribute to possible language design/syntax/core libraries for Ruby VM implementors to introduce (https://github.com/rubyspec/rubyspec/).
The swift API, not necessarily the language. No more than obj-c is at least. With the support for swift to call obj-c code, if they release an implementation it might be interesting to see where projects like Etoile can take things.
The comparisons with scala and c++ are stronger. This is a large language, with a lot of complexity from having to maintain compatibility with an existing environment, plus lots of new concepts bolted on top. Like those languages, the time to basic proficiency may be faster than with their predecessors, but the time to mastery will be much longer.
Scala, yes, but not C++ at all. Indirectly from C#, perhaps (and there is a fair bit of that), but there is very little that borrows from C++ at the language level.
Oh I would love to see a write up comparing it with Scala idioms. As a person who has done C# for a while a lot of idioms translate very well to Swift.
The if let x = whatever {} syntax in Swift is damn brilliant after looking at a ton of C# code with the as check.
As a wannabe-rubyist who thinks reading Obj-C is somewhere between having a migraine and using H2SO4 eye drops, so far I'm in love with the language. I'm doing lots of tripping over the Cocoa APIs, though, in no small part due to Xcode.
The error messages you get when you've done something wrong are unintuitive at best and downright misleading at worst.
Example: I've got a field I want to render an image in. It's represented as an object of type NSImageCell.
I've got my image file defined as an object of type NSImage. So far, so good.
I type the . after the image cell, and I'm presented with a number of autocomplete suggestions. One of which is a method called "setValue" which accepts an object as an argument.
Okay cool.
myCell.setValue(NSImage(named: "myImage"))
Compile and.. instacrash with "Unrecognized selector"
What?
Some research turns up that this error means you've tried to send a message to (call a method on) something that doesn't accept that type of message.
Turns out that the method I needed is called setObjectValue. And it also accepts an object as an argument.
So, Xcode. Why did you give me setValue as an autocomplete when it isn't valid on that object? Why are these method names nearly identical? facepalm
And that's before I get into the almost completely worthless inline error messages. "Cannot convert to $T1". What?
I really, really like the language, but Xcode is trying its damndest to turn me away. I've got a stack of bugs/feature requests that need to be entered into Apple's reporting tool - hopefully some of these are just warts that'll get fixed as Xcode 6 comes out of beta.
It's still in beta dude. Night and day difference between beta and gold master. If you're turned away from a brand new language due to an IDE's autocomplete, then you're in for a world of hurt when you start learning all the Cocoa APIs.
Sure, and he acknowledged that they're still working on it, and is filing bug reports ;)
Having new people join a project/language, and finding it's warts/weird parts is awesome! It's part of how you learn where the REAL issues that bother people are, and set a development roadmap. He's using it, and telling Apple where it should evolve. That's the whole -point- of a Beta ;)
That is true for every programming language and platform pair. The syntax is always the easy part, but unfortunately the only thing most people fixate on.
That setValue(AnyObject)->Void autocompletion is interesting. I don't believe any such method exists anywhere in Cocoa. I think it's probably a bug where a spurious method declaration is being generated from the NSKeyValueCoding protocol header based on setValue:forKey:.
I'm not a rubyist, neither I am a professional programmer, but I'm sad that Apple didn't/couldn't choose Ruby as their main language. Nowadays I'm deciding what programming language to learn as a hobby. Reality (market) tells me that should be JavaScript or right now Swift (looks like javascript for me). It makes me sad, I wish it could be Ruby. So clean and clear. Everything makes sense, I don't need to memorize almost nothing.
Edit/Disclaimer: My first contact with programming (besides BASIC) was Autolisp (Autocad scripting) and my professional field is design.
The primary difference between swift and dynamic languages like ruby is the type system. An existing language like ruby would've been unsuitable if one of the objectives was a safer type system. Taking ruby and putting a static type system into it would've been interesting, but would've created a fork of the primary ruby language, which has its own pain points (being so close, but not quite the same language).
On the other hand, an existing language with the right type system features would've needed a lot of rework to make it suitable for the object model and API.
Or it'd be like C++, where you can program C++ for Linux, or C++ for Windows, and a lot of things may be the same, but then you find out that one of them has different semantics for what you thought was a standard library.
Nothing about making programs requires static typing ever. If you're targetting reliable, performant programs, then static typing is a boon.
Dynamically typed languages require additional tooling beyond the language itself to provide a lot of the reliability/correctness assistance that good statically typed languages can offer. See the dialyzer for erlang, a very useful tool, but a separate tool. If you want to see an example of statically typed languages that require extra tools, see C and its various static analysis tools. Swift, Rust, Ada, etc. (I'm sticking with the more imperative ones with good or better than average type systems) don't require that extra tooling. It's not an additional step. It's just part of the language.
If you want good performance, that is C/Fortran level performance, you either need a sufficiently smart compiler (see SBCL) that can take type hints (derived from the static analysis tools perhaps), or static typing. Static typing (and good static typing like the languages I've mentioned seem to have) improves performance compared to dynamically typed languages. You can remove all the possible branches based on the types used for addition if you know that you're adding two ints, two floats, an int and a float at compile time. In a tight loop, having to select between all those options is a drag on performance. Statically typed languages can reduce that to a single path, instead of the 3 branching paths I just came up with (and there are probably more for most languages).
Besides, performance on mobile is critical. We're depending on miniscule (relatively) batteries. The better performance we can get out of our code, the better battery life we'll see. Every app that's written in a dynamically typed language that doesn't have good type hints (like CL, there are probably others) is going to be a huge drag on battery performance.
Fuck, a friend writes python to run on clusters for numeric code (simulations, he's an Aerospace Engineer). Fucking brilliant, the type system hinders his performance compared to Fortran/C/others. He has jobs that take 24 hours to run on an 80-machine cluster. I hate to consider how much time is wasted because they don't use a language with even a simple static type system like Fortran and C offer.
I love dynamically typed languages, my favorite languages are erlang and common lisp, scheme is a close 3rd. But they have their place, and if performance is one of your requirements they (in general) are not what you want. If reliability is what you want, something that knocks out a huge percentage of errors right off the bat is wonderful, dynamically typed languages (without extra tooling) can't tell you, until you run the program, that you added an integer to a binary blob. And delightfully some are also weakly typed, meaning they'd permit such an operation and you'd get bizarre errors later on in your execution.
--
EDIT: Some scheme implementations offer good performance. Do they, like SBCL, implement static analysis under the hood?
EDIT: I may have left in words that should've been removed when I switched gears in mid-sentence.
Ruby isn't fast enough, and it would chew battery on a phone and make some apps impossible to do correctly. Ruby is a great language, it's my favourite hands down, but all that sugar comes at a cost. Even in ruby, we often use c libs to do the heavy lifting, they're just wrapped by ruby using the C extension framework.
RubyMotion for Android features a completely new Ruby runtime specifically designed and implemented for Android development. This is a new implementation of the Ruby language, it does not share code with RubyMotion for the Objective-C runtime. We are using the RubySpec project to make sure the runtime behaves as expected.
...
We feature an LLVM-based static compiler that will transform Ruby source files into ARM machine code. The generated machine code contains functions that conform to JNI so that they can be inserted into the Java runtime as is.
...
RubyMotion Android apps are packaged as .apk archives, exactly like Java-written apps. They weight about 500KB by default and start as fast as Java-written apps.
It's a bold claim, but I haven't seen anything to back it up. I haven't tried all the apps made with the framework, but I haven't seen too many heavy apps that would require the power. Every game is a puzzler of some sort it seems. Nothing to really test if it is fast enough for gaming, or time critical operations.
That doesn't actually dispute either of the claims you're saying it does. Everything you just quoted can be true and Ruby could still be too slow compared to Objective-C and chew up too much battery.
Swift is not anything like JavaScript. And unfortunately ruby isn't powerful enough to do what Apple needs, but I agree that it would be nice if they could have chosen something with more syntactic elegance, although I'd have preferred it if they'd just gone in the direction of Smalltalk.
I presume you haven't programmed lisp, because although there is very little syntax to memorize, there are a huge number of functions.
I can't say that Swift is like JavaScript, my technical knowledge is not enough to have an opinion about it. I say that looks like, or using the right terms, has as much syntactic elegance as JavaScript.
I programmed a little bit in Autolisp (lisp dialect for AutoCAD scripting) as amateur and what I liked about it is that everything works the same way (even if you don't know all functions is not a big deal), it's just a list. JavaScript looks like a mixture of paradigms and syntax, trying to please everybody. When I don't program in it often I forget most of the stuff. Probably it needs to be like this but it doesn't look like an optimal solution.
> And unfortunately ruby isn't powerful enough to do what Apple needs
I'd say on the power spectrum of programming languages, ruby is MORE powerful than swift.
There are so many things you can do in ruby that you can't do in swift, especially along the lines of reflection. The only stuff swift has that ruby doesn't comes in way of restrictions eg. typing.
>And unfortunately ruby isn't powerful enough to do what Apple needs
If this was the main and only reason such that removing this limit Apple would have used Ruby, then why in your opinion didn't Apple try to implement themself something like RubyMotion (which was made by a company a thousands orders of magnitute smaller)?
You seem to care a great deal about a topic you don't yet know enough about. You seem to have a superficial attraction to Ruby, which is fine, but it doesn't actually make Ruby better in any meaningful way. If you actually use a language and make real programs in it, you'll stop being a beginner before long, and your opinion now will be irrelevant even to you. Ruby is my go-to language for getting things done, but there is still a whole lot that is awesome in Swift.
