Move Over AJAX, Make Room for ARAX 409
sasserstyl writes "eWeek reports that Microsoft's Silverlight platform will support Ruby client-side scripting, enabling ARAX — or Asynchronous Ruby and XML. Would be cool to have the option to script client-side in something other than Javascript. 'In essence, using ARAX, Ruby developers would not have to go through the machinations of using something like the RJS (Ruby JavaScript) utility, where they write Ruby code and RJS generates JavaScript code to run on the client, Lam said. "Sure, you could do it that way, but then at some point you might have to add some JavaScript code that adds some custom functionality on the client yourself," he said. "So there's always that sense of, 'Now I'm in another world. And wouldn't it be nice if I have this utility class I wrote in Ruby...' Today if I want to use it in the browser I have to port it to JavaScript. Now I can just run it in the browser."'"
Not only... (Score:3, Informative)
Re:Look at ol' MS (Score:4, Informative)
Re:Um, my browser doesn't support Ruby (Score:5, Informative)
And because you brought up Java too, there's also JRuby, a Java implementation of Ruby.
look more closely at TFA... (Score:5, Informative)
Really this isn't a suprise as SilverLight was supposed to be the first outing of the Dynamic CLR (support for IronPython, IronRuby etc.). MS has been quite enthusiastic about dynamic languages ever since Jim Hugenin (former JPython author) started working for them.
Andy
Why is this news? (Score:1, Informative)
Is this news because of some kind of "OMG, TEH RUBY!" factor?
Are we seriously going to have another news item for IronPython ("APAX"), J# ("AJ#AX"), F# ("AFAX") or IronLisp ("ALAX")?
Re:Somebody update NoScript. (Score:5, Informative)
Strong and weak are often confused with dynamic and static. They're orthogonal concepts.
An example of a weakly statically typed language would be C. You have to declare the all the types, so you know what type you're dealing with compile time, but a boolean can be treated like an integer or a pointer. An example of a strongly dynamically typed language would be Lisp. You don't have type declarations (well in Common Lisp they're optional), and you don't know the type of a variable at compile time, but a list cannot be treated like a number.
You do get dynamically weakly typed languages, like PHP. You also get statically strongly typed languages, like Haskell. Assuming that strong and static are the same thing, or that weak and dynamic is the same thing, is a big mistake.
Uh... (Score:1, Informative)
Ruby is weakly typed, and dynamically typed, which means, as a programmer, you have a huge amount of freedom in what you can feed into a variable. It also means that you can effectively give it any input maliciously, and it will try and do something with it instead of rejecting it.
Java is the opposite. It will not accept data that does not match the variable declaration, and it will not allow variables of different types to interact without an explicit cast.
Re:Somebody update NoScript. (Score:1, Informative)
Re:Um, my browser doesn't support Ruby (Score:4, Informative)
Re:Um, my browser doesn't support Ruby (Score:3, Informative)
It's like Java, only without hacks like "primitives". Unlike Java, it is a pure OO language, where everything is an object, and it provides a few significant OO features that are missing from Java, such as mix-ins and closures.
--- SER
Re:Um, my browser doesn't support Ruby (Score:3, Informative)
Its nothing like Java.
Now, if you said it sounds like "Python for people who hate Python", that would be more reasonable. Or, say, "Perl for people who can't read Perl". But those, though better than "Java for people who hate Java", still miss the point.
Its a dynamic scripting language whose strongest initial influences were, IIRC, Smalltalk and Perl; it was more OO from the start than Python, though I think that's less of a gap now. It seems to have stronger influences from functional programming than Python, and its design follows more of Perl's "There's more than one way to do it" philosophy than Python's more "There's one way to do it" approach. It has good support for metaprogramming and internal DSLs. Its frequently criticized for the fact that the main current (1.8.x) implementation is slow, even among dynamic scripting languages, though faster implementations (the new, but less stable, 1.9 implementation, and the alternative, Java-based, 1.8-compatible JRuby implementations) exist.
Where is he? WHERE THE F*CK IS HE? (Score:2, Informative)
SHOW YOUR FACE, MOTHERF*CKER!
Re:Um, my browser doesn't support Ruby (Score:3, Informative)
I think he's referring to interactivity, ie in a thick client MVC system, you can interact with the GUI and changes are seen immediately, but the problem here isn't one of MVC being poor, its the relatively slow network that's the problem.
I suppose you could download a lot of data to the view and only show part of it as the user selects things, but that involves moving the controller to the client. I guess some people would think that's breaking the paradigm, but that's how a MFC app works - data tends to be all in the client.
So.. maybe he sees Rails as poor because it is always making roundtrips to the server.
Either way, who cares. The decoupling of presentation from logic is one of the best paradigms you can use for any application.
Re:Embedded Python on the web? (Score:1, Informative)
The two major problems are lack of sandboxing (at the language feature and library levels), which makes it a security risk for anything from untrusted sources, and lack of widespread use to enable it on the web at large.
One thing Silverlight brings to the table is a security architecture, so things running on top of it -- like the DLR Ruby implementation -- are already sandboxed.
Re:Um, my browser doesn't support Ruby (Score:4, Informative)
Re:Uh... (Score:1, Informative)
Re:Um, my browser doesn't support Ruby (Score:5, Informative)
That's nonsense.
If for no other reason than the fact that displaying a page often involves some real work. Some real heavy-lifting. Often far more than just a couple database queries being fed into a grid or report.
OOP brings order, structure, reuse and quality control to large, complex systems (and website/webapps can certainly be very large and very complex) That's true no matter what context it's being used in, web, rich client, whatever.
Yes, there is overhead involved in creating objects. But even in your worst-case scenario where there is no shared state, the overhead is hardly a deal breaker: It's far better to optimize for the developer than it is to optimize for the machine. Unless you're working on a website in the 99th percentile of traffic, you probably don't have a lot to worry about.
Further, your scenario IS worst-case.
For example, we have an in-house framework. It's not all that different than the ones you've seen. Take, for example, a simple web form:
You instantiate the data model (need to pre-populate the form), you instantiate a webform object, which is view-tier and is just a widget that binds to a data model and presents an HTML form.
When that form is rendered in HTML, the webform object and the data model it binds to are serialized and stored in the session.
When the user submits the form the front-controller will look at the formkey submitted with the form and unserialize the form and model objects. It pulls the values from the HTTP Post into the data model and they're validated and saved.
This is nothing revolutionary. It's not even complicated. And it's just one of a dozen ways to overcome the no-shared-state problem.
The idea that OOD is "degenerated" in a web environment is ludicrous. Procedural development is a thing of the past. The idea of 1 page : 1 script that runs from line 1 to line n is just not adequate for MOST modern web apps.
Todays systems are not your mothers web applications. We're doing far too much on the web. Applications the size of the web applications that are written today would collapse under their own weight if done procedurally.
Re:Um, my browser doesn't support Ruby (Score:3, Informative)
I'm sticking with Perl and CPAN, thanks.