class Foo
include Virtus.model
attribute :foo, String
end
if (hasAccess = true) {
doSomething();
}
if current_user = find_current_user
notify_user(current_user)
end
if let currentUser = findCurrentUser() {
notifyUser(currentUser)
} if let currentUserIsAuthorized = true { // COMPILE ERROR
...
}
if current_user = find_current_user
notify_user(current_user)
end
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?
Give the vibrant community effort some time.
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.
Even if apple made great strides in open sourcing the language, compiler etc, I doubt we'll ever be able to run it on anything other than OSX/iOs.
While I can think of usages where I could see myself use it, the given example is definitely not one.
Disclaimer: I have walked the tutorial and reference and I belive it is fantastic. I am waiting for someone to release a linux compiler.
The if let x = whatever {} syntax in Swift is damn brilliant after looking at a ton of C# code with the as check.
https://leverich.github.io/swiftislikescala/
And also, a comparison to C#:
http://pietschsoft.com/post/2014/06/07/Basic-Comparison-of-C...
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"))
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.
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 ;)
Edit/Disclaimer: My first contact with programming (besides BASIC) was Autolisp (Autocad scripting) and my professional field is design.
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.
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.
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.
http://blog.rubymotion.com/post/87048665656/rubymotion-3-0-s...
I presume you haven't programmed lisp, because although there is very little syntax to memorize, there are a huge number of functions.
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.
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.
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)?
Doesn't prove anything about Ruby's suitability, though.