Software Development

Looking ahead to IronRuby


With the exception of the occasional Perl script, my development efforts are squarely within the .Net ecosystem. This is not really my choice.

I like the .Net Framework because it encapsulates 90% of the dull plumbing work. I like the .Net CLR because it lets me use the best language for the job (in theory, when an alternative exists and works well). But I find VB.Net fairly unpleasant for many tasks, and C# does not particularly thrill me either (although C# 3.0 is changing my mind a bit).

In the .Net universe, it frustrates me that anything outside of VB.Net or C# is viewed as a risk simply because it is not a full-blown Microsoft product, and all too often does not "feel" like a mainstream language. Many of these fears are fairly well-founded. IronPython lacked Visual Studio support when I tried it (after its official release), and Python does not interest many developers. F# is a fun language for me to play in, but developers who enjoy working with a functional language are rare -- and those who use them well are rarer still.

Enter IronRuby (thanks for the link, Chad).

The Ruby language has interested me for some time now. From what I can tell, it combines much of the flexibility that I appreciate in Perl, a solid object model, and is a dynamic/interpreted language to boot (I have a soft spot for them). I can come up with a dozen or so reasons why I never tried working with Ruby, but many of them relate to the fact that I really like Visual Studio and the .Net Framework. All of that being said, it does not have anything to do with the Ruby language. RoR is not Ruby! It is a Web development framework and nothing more. I think that C# and VB.Net are great languages for gluing libraries up to a UI -- I just do not like writing libraries in them, and they are not great for complex logic.

So when IronRuby hits, I will definitely be willing to give it a shot. For it to gain any kind of widespread adoption, it needs to meet the following criteria:

  • Have documentation.
  • Integrate with Visual Studio, including IntelliSense and debugging.
  • Work with the .Net Framework in a Ruby-like manner (and not like Java or C#).
  • Have a reputation for not being buggy or in perpetual beta or subject to a frequent release/revision/update cycle.
  • Receive as much support from Microsoft as VB.Net or C#.

Look at this list of "never was," "maybe will be," or "almost has been" Microsoft-backed .Net languages:

  • J# (I never figured out if this was supposed to be a Java clone or a JavaScript clone and no one else did either.)
  • Managed C++ (C++ is rapidly dwindling in favor of other languages for all but the most low-level or performance-sensitive applications.)
  • IronPython (It lacks Visual Studio support; its documentation is poor; and languages where indentation matters have never been popular.)
  • Perl.Net (It's not really Microsoft, but ActiveState has close ties to Microsoft. It lacked Visual Studio support and was very odd to work in, particularly due to Perl's object model clashing with the .Net Framework.)
  • F# (It's still put out by Microsoft Research, but it's not viewed as ready for prime time as a result. It's a functional language, but it has poor documentation.)

I hope that Microsoft does IronRuby right. So far, it looks like it has a smart, dedicated team of folks working on it but that is not enough. The difference between C# and J# or F# or IronPython is that Microsoft put its full weight behind C#. If Microsoft treats IronRuby as a full partner in the ecosystem, it stands a good shot.

J.Ja

[Edited 8/22/2007 {Justin James} to add a link to "Chad"]

About

Justin James is the Lead Architect for Conigent.

70 comments
Justin James
Justin James

I really butchered a bit of the post guys, I did not notice until I saw the extract in the newsletter. This section right here: "All of that being said, it does not have anything to do with the Ruby language. RoR is not Ruby! It is a Web development framework and nothing more." The parts about RoR were remnants of some different text I had in there. I was originally going to use that little space to talk about some of the issues I have with RoR, but I took it out, and those two sentences survived, feeling quite out of place! My apologies for any confusion there! J.Ja

billyscholtz
billyscholtz

I think that anybody working in this wizard type environment must go back to school. If you an not write your apps in Java, PHP or Perl, or are not truly a LAMP/AJAX developer, stay away from clients and go back to school. It is a sinn to sell .net or .asp type applications to high paying clients, for most of the developers who do, need to go back to school

alaniane
alaniane

get arrogant about it. If you don't write your apps in Assembly or machine language then you are not a true programmer. The language or API does not make a programmer. Part of programming is learning how to deliver what the customer wants in an efficient manner regardless of the API or language used.

apotheon
apotheon

"[i]If you don't write your apps in Assembly or machine language then you are not a true programmer.[/i]" No no no . . . you're not a true programmer unless you use punch cards! I hope that "true programmer" comment of yours was a joke. It certainly reads like one.

apotheon
apotheon

I thought that was the case, but wanted to be sure. That being the case, your point was well made. Anyway, thanks for helping kick off a fun subthread.

alaniane
alaniane

It was a hyperbole in response to the previous comment about true programmers only using Java, PHP, and etc. Of course, if I could convince upper management of the need for me to write their database app in assembly or ml, I could guarantee job security for the next two centuries or until the company went bankrupt.

apotheon
apotheon

I don't have children, and using others' children has been illegalized. I'm no programmer of illegal software, so I don't take Justin's approach of kidnapping others' children. I'm stuck with water power -- which is less easily controlled and much slower than child power, anyway, so I have to fit all my programs into seven bits (plus one for parity).

Justin James
Justin James

I have an army of hamsters on wheels connected to generators to power my rig. When I want to get aboce 2 Hz, I raid a nearby village and put their children on the "Wheel of Pain" to provide me with the extra boost I need. Unfortunately, this is usually only good for a 2 week or so improvement as my PSUs tend to die on me... J.Ja

Tony Hopkinson
Tony Hopkinson

Not one being diven by your children with a shaduff I asssume? Then you'd be hardcore.

apotheon
apotheon

. . . but [b]this[/b] real programmer is using a series of cogs and levers ultimately powered by a waterwheel.

apotheon
apotheon

I have never in my life imagined that anyone would hold up PHP as an example of the tool of a "real" programmer. If anyone needs to go back to school, it's the PHP devotee. That language was, in large part, created by school children -- at least as far as I can tell. By the way, .NET doesn't necessarily indicate that you're using a "wizard type environment". It's a framework, not an IDE. The "wizard type environment" is Visual Studio.

maheshp
maheshp

IronPython does have VS support including debugging, intellisense, project system and designers emitting IPy. I recommend reading Aaron's blog at http://blogs.msdn.com/aaronmar/archive/2006/02/16/a-bit-more-on-ironpython.aspx

Justin James
Justin James

... when I tried it, the VS support was not there. :) It actually holds a huge lesson: first impressions count! It is one reason why I am not a huge beleiver in the giant public betas that are currently in vogue. I got an impression of IronPython from their "initial release", and not seeing the Visual Studio support then has become the basis of a lasting impression. I may indeed check it out again in the near future though! J.Ja

Chuck.Esterbrook
Chuck.Esterbrook

Then you should probably wait to review Cobra until it hits 0.9. :-) Seriously, I wasn't planning on announcing or promoting it until 0.9 since it still has some major holes (no delegates yet!). Nor do I have a VS plugin... although I'll definitely be building one when the compiler is more mature.

Chuck.Esterbrook
Chuck.Esterbrook

Your interest in IronRuby is strange given your comment that you passed on IronPython in part because "Python is not a language that many folks have interest in". Python is more popular than Ruby: http://www.tiobe.com/tpci.htm For awhile it was even more popular than C# although I see they have switched places this month. Congratulations, C#. Also, many of the top, popular languages are not Microsoft at all, including Java, C, C++ (#4 on the list), PHP, Perl and JavaScript. Choosing a Microsoft language is not the top priority in most shops, although it may be in .NET shops. Regarding documentation, Python itself has a ton of docs and IronPython is a clone of that language. There wouldn't be much point in having a Microsoft person reinvent the docs. Also, you're still listing "lack of Visual Studio support" with IronPython in your list even though it currently supports Visual Studio! That would be like rejecting C# because it "doesn't have generics". Regarding backing by Microsoft, both IronPython and IronRuby are supported out of the box in Microsoft Silverlight and at least IronPython has Visual Studio integration (haven't checked on IronRuby). That's about as good as you can ask for... Regarding C# and VB, you stated "I just do not like writing libraries in them, they are not too great for complex logic." I'm curious what improvements you would like to see to C# (or VB) to address this problem. What could be changed about C# to make it more productive? -Chuck Esterbrook

Justin James
Justin James

Chuck - You ask a lot of good questions there. "Your interest in IronRuby is strange given your comment that you passed on IronPython in part because "Python is not a language that many folks have interest in"." I do see Ruby's popularity rising significantly. I also must add, everyone I have talked to who has used Ruby absolutely raves about it. I agree that it still is not mainstream, but of the 2nd tier (in terms of popularity) languages out there, it looks like it could hit the top. "Also, many of the top, popular languages are not Microsoft at all, including Java, C, C++ (#4 on the list), PHP, Perl and JavaScript. Choosing a Microsoft language is not the top priority in most shops, although it may be in .NET shops." I agree 100%! I deal almost entirely with Microsoft shops though... and to be honest, I see Microsoft gaining more and more developer mindshare. And if IronRuby does well, it can be a huge win, since it will allow a developer to use their skills across all platforms. "Regarding documentation, Python itself has a ton of docs and IronPython is a clone of that language. There wouldn't be much point in having a Microsoft person reinvent the docs." No, but there *would* be a point in having a Microsoft person get some docs out there that demonstrate using Python and .Net together. Without the .Net Framework behind it, IronPython is nothing more than a Python CLI interpreter further slowed down by the .Net CLR. When I was trying out F#, one of my biggest stumbling blocks was trying to use .Net from F#. I figured out the language itself, but learning how to do even basic things like cast .Net types to F# types was a touch rough! "Also, you're still listing "lack of Visual Studio support" with IronPython in your list even though it currently supports Visual Studio!" When Microsoft had their big "IronPython is here!" hype on, I tried it, and I did not find any Visual Studio support. It may well be there, but I tried to make it clear in the original post that the lack of support was when I tried it, not necessarily now. "Regarding backing by Microsoft, both IronPython and IronRuby are supported out of the box in Microsoft Silverlight..." For the moment, Silverlight is indeed interesting, but I do not see it as a huge thing. That may change, and if it does, I see Silverlight primarily being used on Intranets where you can guarantee the environment. I have a suspicion that it will be viewed as nothing more than ActiveX 2.0 or Java applets 2.0. :( "What could be changed about C# to make it more productive?" The 3.0 stuff, particularly lambda calculus is a huge step in the right direction, to be honest. My #1 most productive call in a language is eval.(). LC gives me that power in C#. On my list of things to make me dream in C#: * Regex as a string level operator (yes, I'm a Perl person)... so much of the data we deal with is string data, and regex is so insanely useful. * Better multi dimensional logic (nearly all languages suffer from this deficiency). I beleive some lmbda calc magic can remedy this though. Iterating through multidimensional collections that contain strings that are used as LC or anonymous functions would do the trick. * Incorporation of more ideas from imperative and functional languages, which is already happening. In other words, C# is actually well on its way to being more than just the glue language it started off as, and it is pretty cool to watch it develop. Most of my "I am not a big fan of C#" was actually addressed in 3.0. :) J.Ja

jean-simon.s.larochelle
jean-simon.s.larochelle

Although I have not done any major developement in Ruby I do enjoy the regular expression support in it because it is just great for programmer tools JS

apotheon
apotheon

More to the point, I like the fact that in Ruby regexen are first-class objects. There are both object and Perl-like syntaxes for working with regexen, there's no library call necessary to use regexen, and for most purposes the Ruby regex engine is pretty complete. Python's regex library is more complete (and, of course, no regex engine I've ever seen is as complete as Perl's), but Python's regex engine is still not a part of the core language, so there's a significant trade-off there. Also, with the development of the Oniguruma regex engine for Ruby 2.0, the power gap between Ruby's and Python's regex engines will evaporate (or even reverse itself), leaving only the unwieldy library call syntax for Python regexen as a major point of contrast. Note that I haven't personally used Oniguruma, so any quirks that may make it annoying to use (or that may make it even better to use than Perl-like regex syntax) are not within my range of familiarity.

apotheon
apotheon

"[i]I have a suspicion that it will be viewed as nothing more than ActiveX 2.0[/i]" That's because it [b]is[/b] basically ActiveX 2.0, in any way that matters. ActiveX was Microsoft's answer to Java applets, just as Flash was Macromedia's answer to the same thing -- even if nobody realized it at first (initially, everyone thought Flash was just a cheap animation tool). Because Flash did applets better than Java, and ActiveX did them worse, Flash was basically applets++ and ActiveX was kind of like applets-- (which creates sort of a strange relationship with Smalltalk, since [url=http://c2.com/cgi/wiki?TomStambaugh][b]one of the original designers[/b][/url] of Java now refers to it as [url=http://c2.com/cgi/wiki?SmalltalkMinusMinus][b]Smalltalk--[/b][/url]). Anyway, I'm getting a little off-track. Ahem: Silverlight, as a proprietary, platform-limited response to Adobe's proprietary, platform-limited Apollo->Air, is ultimately going to be viewed as pretty much exactly the same thing as ActiveX -- unless something drastic happens to change the way Silverlight is designed and distributed. I really don't see it being intentionally ported to non-MS browsers by the Powers That Be in Redmond, however. The intent, of course, is to increase vendor lock-in for IE, and thus for MS Windows. The way things are going, though, I think the only companies that are going to bite on that piece of bait are those that are already so locked in there's no getting out anyway. In fact, many organizations are looking for a way to get [b]out[/b] of the mistake of tying themselves inextricably to ActiveX -- not for a way to make the same mistake again. Granted, Silverlight may provide a [b]much[/b] better development model than ActiveX (it would be difficult to do otherwise, really), but in terms of how it fits into the larger development ecosystem it's pretty much Son Of ActiveX. edit: . . . or I'll be very surprised to discover it's not.

Justin James
Justin James

Chuck - That is good for adoption, and may very well not hurt the langugage at all. However, I am not sure if that would compromise your vision of a "Python with teeth" (my words, not yours). ;) Personally, when it comes to the idea of curly braces, I am not a huge fan of them per se, but it is common, and a heck of a lot better than the other major syntax out there, BASIC/VB/VB.Net/etc. One thing I have noticed, is that at the end of the day, languages that copy C style always end up feeling like C/C++, just without pointers. Even PAscal is really C-like, but its major syntactic sugar was replacing "{" with "begin" and "}" with "end", and clearly delimiting assignment and equality tests with ":=". Similarly, functional languages tend to orient around prefix operators and always end up feeling a lot like Lisp/Scheme. So, in a way I feel like it may actually be possible that C-style could be a disservice! It really depends on your goals. If you are looking to bring a more expressive langugage to the table (or one that is "differently expressive"), C-style hurts you. If you want to bring an accesable alternative to the table with your added features, it is a Good Thing. J.Ja

jean-simon.s.larochelle
jean-simon.s.larochelle

...a language like Python (or Cobra) if I could turn strict syntax (what you call curly :) on. I don't know how Cobra handles Regexp but in the case of Python compared to Ruby the regexp factor (regexp as first class Object as apotheon so nicely put it) would remain. Oh, and also the "iterator everywhere" approach of Ruby would remain a great asset. So, yes I think having the ability to turn strict (or curly) syntax on would be an asset. JS

apotheon
apotheon

The way Ruby handles things (as you're probably aware), you can either use braces or not, and line termination characters are optional. I think Ruby's is one of the best approaches to block delimiting I've seen so far. . . . but I'll take what I can get. If you just provide two approaches, like C and Python, you can probably bet money that any code I wrote in Cobra would end up looking like C.

apotheon
apotheon

I've never really done development by contract -- it's something I'll have to look into. The languages I've used most, however, provide excellent unit test libraries, so that hasn't really been something I've lacked. Most of my work has been with dynamic languages -- either dynamically typed in the traditional sense or duck typed -- but in those cases where I've worked with statically typed languages, I find (dismayingly) that most are weakly typed, and require a lot of type declaration bookkeeping and the like. In fact, that's one of the reasons I end up using more dynamic languages. I have some plans that should ultimately lead to doing more development with OCaml in the next year or two, which will relieve some of the annoyance of working with statically typed languages like C (or worse, Java). It'll be nice to see Cobra develop as another type inference alternative.

Chuck.Esterbrook
Chuck.Esterbrook

What do you guys think of the idea of having *2* syntaxes? The Python-oriented one would be called "clean" since it's devoid of most punctuation, and the other would be "curly" which would be near identical to C/C++/C#/Java. The file extension would indicate which was in use, which would change the syntax only. Otherwise, the language features would be identical (classes, unit tests, etc.)

Chuck.Esterbrook
Chuck.Esterbrook

1. I do foresee a "Cobra/C" version down the road that would generate C thereby allowing native executables to be created in Cobra. I still have a lot of work left to do on the .NET version though. But when it's mature, the tokenizer, parser, error checking and other compiler parts will be reusable for the Cobra/C version. UnixLike platforms including Mac, Linux and BSD, would probably be the first target as they just make C compilation convenient. 2. Yes to type inference. Btw I'm dismayed to see a *bunch* of positive features left out of programming languages including type inference, unit tests and contracts. :-)

apotheon
apotheon

Your goals for the language look interesting. I have a couple of questions, after a first glance: 1. Will there ever be a non-managed code implementation of the language (or, rather, do you foresee such a thing)? Binary compilation and REPL execution outside of a manged code runtime sound like a couple of features that have been ignored as "must-haves", at least for my tastes. 2. Does Cobra employ type inference? The "i = 5" explanation on the website seems to indicate it does. If so -- kudos. It's a little dismaying to see such a thoroughly positive feature left out of so many mainstream (at least nominally) statically typed languages. The main downsides, for my purposes, seem to be the parser-significant indentation and the fact that it's tied to a managed code runtime. That's probably just me, though. In any case, I respect what you're doing in general, and think what you're trying to accomplish is definitely worthwhile. I'll keep an eye on it.

apotheon
apotheon

I didn't realize Silverlight was available on the Mac. Of course, as you point out, the lock-in motivation is still there -- it's just .NET lock-in rather than IE/Windows lock-in, in this case. Unless and until I see Microsoft relinquish control of the specs to a disinterested third party (standards organization like the W3C, perhaps), Silverlight will never be an open development platform. Microsoft has proven it simply cannot play well with others in the way it makes every internal "standard" a moving target. We're seeing the problems this sort of thing can cause with Mono and .NET already. Software written to be "cross-platform" is either failing to run on Mono or failing to run on newer versions of the .NET framework and the Microsoft CLR. Let's just say that, as a FreeBSD user, I find Silverlight less than exciting. It seems like the whole point of something like Silverlight, Air, et cetera, should be portability -- but real portability just doesn't seem to be in the stars.

Chuck.Esterbrook
Chuck.Esterbrook

"I really don't see it being intentionally ported to non-MS browsers by the Powers That Be in Redmond, however." If you go to the Silverlight web page http://silverlight.net/ and poke around you can see the download is available for Mac and Windows. But there is no IE on the Mac--Silverlight runs on Firefox and Safari on that platform. I think people make the mistake of assuming that Microsoft in the present is identical to Microsoft in the past. It's not. In fact, it can't be: Employees turn over; MS responds to competition from open source; MS responds to antitrust settlements. And I met some of their techies when I was there for Lang.NET 2006. They're just like other techies. They want to build cool projects and see lots of people use them. "The intent, of course, is to increase vendor lock-in for IE, and thus for MS Windows." Then why does Silverlight run in Firefox and Safari? Obviously not for IE lockin! The real point of Silverlight is to keep developers in the MS community and to popularize .NET. MS doesn't want to lose mindshare to JavaFX or AIR. "Silverlight, as a proprietary" There is an open source clone of Silverlight called Moonlight. And some of the components in Silverlight are open sourced and codeplex so they don't have to be recreated. -Chuck Esterbrook

apotheon
apotheon

"[i].Net CLR instead of COM[/i]" Of course, that alone should make it a bit less painful to developers. "[i]ActionScript is, as far as I know, an implementation of ECMAScript[/i]" ActionScript is an implementation of ECMAScript 3, as are JavaScript and JScript. As I recall, Air will be using an implementation of ECMAScript 4 (which, by all accounts, will be a significant improvement over ECMAScript 3). "[i]ECMAScript has never been (and probably will never be) taken seriously as a language (in really, it is not too bad as far as things things go, as long as you leave the browser DOM out of the picture).[/i]" I definitely agree, with regard to ECMAScript 3. On the other hand, ECMAScript 4 shows some real potential. As long as someone comes up with a general-purpose implementation (rather than tied to a browser or applet application) that has a name that doesn't sound like a variation on JavaScript, ECMAScript 4 might even eventually become a contender for the Next Big Thing. The Tamarin VM for JavaScript 2.0 (which is the JavaScript implementation of ECMAScript 4.0) strikes me as a step in the right direction. Only time will tell, though -- and, frankly, ECMAScript 4.0 seems to be playing catch-up now that Ruby has hit the big time, with Ruby 2.0 on the way, to say nothing of the potential for Perl 6 to shake things up when it becomes release-worthy. "[i]Since it did not look like an applet type thing, people let it slip in there. Meanwhile, more applet-like technologies are all languishing.[/i]" For the most part, the applet is a concept that is just not ever going to be successful outside of a given niche, as far as I can tell. Efforts like Air and Silverlight are doing interesting things with the applet idea, but the closer they get to viability as a useful technology, the more they start to look like package managers -- which are already done better by open source OSes. The major difference is that these new things sorta run in their own little virtual machine inside the host OS. There may be a convergent evolution solution to the problem in the future. Open source OS software management, these applet runtimes, VMs for OSes, and these half-baked "Web OSes" may all contribute something to the development of a "new" sort of runtime environment that provides true portability of applications across platforms. Of course, if that happens, chances are good it'll look a lot like a Smalltalk environment.

Justin James
Justin James

... that it really *isn't* ActiveX 2.0, even though I know it is. It is the exact same idea, just using the .Net CLR instead of COM. I just like to pretend that it is not, just to keep things interesting. Notice that Apollo/AIR/Flex etc. seem to be going nowhere as well. I think what let Flash slip under people's radar was *precisely* the impression that it was only good for animations, combined with the fact that ActionScript is, as far as I know, an implementation of ECMAScript (JavaScript is the more well know implementation, of course, along with JScript by Microsoft). ECMAScript has never been (and probably will never be) taken seriously as a language (in really, it is not too bad as far as things things go, as long as you leave the browser DOM out of the picture). Since it did not look like an applet type thing, people let it slip in there. Meanwhile, more applet-like technologies are all languishing. J.Ja

Justin James
Justin James

... I think it could be a very useful thing in a controlled environment, but complete ignored outside of them. For what it's worth. J.Ja

Tony Hopkinson
Tony Hopkinson

The big boosts over ActiveX, is it's .net code, so the client is in charge of what it allows the code to do. Though setting up the config file at the moment is a less than amusing proposition. The other one is of course WPF and XAML which will be biggest improvement to web based apps bar a proper protocol to do them. The architect on our team has been looking at it with an eye to future (18 months to two years) down the line, he described it as very clever, but at the moment very flakey.

Chuck.Esterbrook
Chuck.Esterbrook

Thanks for the detailed response. In particular, I agree that regexes should be a language level feature. Let's hope Silverlight surpasses ActiveX and Java applets in a manner that makes it a fun and productive medium to deliver apps for both us and the users! -Chuck

Justin James
Justin James

Chuck - Out of curiosity (and rather impressed by the quality of your reponse) I looked you up, if you're the same Chuck Esterbrook who is working on Cobra, I am *very* impressed. A lot of the things I see in Cobra are the things I would like to see in a language! So if you are one and the same, please keep me posted on the status of that project, I would love to be writing about it and looking into it in this space! J.Ja

Justin James
Justin James

Chuck - Glad to see that it's the same person, and glad to have you commenting on my blog! I sent that email out, BTW. From what I saw on the Cobra Web site (I spent about an hour perusing it last night), I like ther direction it is going in. My only real upfront disagreement is the importance of indentation (already discussed). I liked the design by contract stuff (you may want to check out Spec#, BTW, it is a design-by-contract oriented carient of C#, put out by Microsoft Research) and the integration of unit testing especially. As a langugage, it also looked pretty efficient. The Blind Watchmaker example was pretty good, IMHO, of showing off the langugage; that is a good example of the things that are annoying to try to code in VB.Net, Java, etc. (although a simple example), where you are doing more conceptual and less data/object manipulation. I tried to think of more efficient ways to code it. If you refactor to use less intermediate variables in Cobra (which is sort of cheating, you still have the same total number of operations but a deeper call stack to compensate), the best I could do in my head was to save maybe 3 or 4 lines in Perl, *at best*. I beleive that in a functional language, this could be significantly reduced in terms of SLOC using recursion; depending on the language and the length of the "goal", this could result in disaster, of course. Lisp/Scheme handles these things quite nicely. I am not sure how well O'Caml or F# or Haskell etc. would (I've recently played with F#, and I've been reading the SICP book during lunch). So yes, it looks quite efficient! This discovery of Cobra actually comes at a great time for me... for the next few weeks (next week will be an exception), I will be looking at less mainstream systems and langugages. In about a week-and-a-half I should be writing about Smalltalk, and take it from there based on reader response. I will probably end up discussing Cobra, since it has so many things that I like in it. :) J.Ja

Chuck.Esterbrook
Chuck.Esterbrook

Yep, that's me. I guess you can see now why I was curious about your opinions on improving C#. I have a 0.6 release coming out this month that will be more worthwhile to play with than the 0.5. I'll also be surveying for name ideas as I want to revisit my name choice one last time before hitting 0.9 and publicizing the language. If you send an email to info .at. cobralang .dot. com then I'll BCC you on the 0.6 announcement. I look forward to your feedback! -Chuck

Tony Hopkinson
Tony Hopkinson

It's unbelievably flakey. Thought the default was Javscript with IronPython because Jim already did that. That aside Silverlight has a lot of potential, could actually help cure the biggest downside of client side execution of alien code, if .Net's authorisation methodolgy is followed. ie The consumer decides what privileges the the component has not the supplier.

Justin James
Justin James

If and when would you be willing to try IronRuby? I've laid out my criteria, what are yours? J.Ja

jslarochelle
jslarochelle

1) I already use Ruby as a programmer tool and the reasons for this are mainly the following: 1.1) Great Regular expression integration. Regular expression are first class object and can be used very efficiently to parse and manipulate text. They can be used in switch/case statement if and passed around, you name it. 1.2) Ruby uses what I call the "iterators everywhere" approach. For any sequence of operations on an object that feels like "iterating" you can bet that the Ruby class as an iterator available for it. Since Ruby has Closures (more on this later) this makes the language very flexible and expressive (you can do a lot with very little code). Just great for programmer tools. 1.3) Great file I/O library where iterators and closure are well integrated. Making file manipulation very economical in terms of lines of code. 2)I might use Ruby for other types of project because it is generally a very good OOPL. Here is a couple of nice features: 2.1) Closure. Like I mentionned earlier is a great feature. C++ programmers can think of a closure as a special type of function pointer. With closure you can define a snippet of code that you can pass around. Of course one place where you can use closures is as argument to one of Ruby's numeraous iterators. But you can use closures in other ways also because they are more than function pointer. For one thing a closure remembers the context where it was created...(check-out the Web for more about Ruby's closure) 2.2) Mixin. This is a great language construct that lets you reuse code very efficienly. You can think of it as a kind of "clean" multiple inheritance. You define functionality in a module. You can't instanciate a module but any class can include the functionnality in a module and in fact a class can include several module. Define once and use everywhere. Finally, I don't have the place here to enumerate all reasons (or be more rigourous in my descriptions) why I like Ruby however I hope I helped more than I hurt. The commercial product I work on is written in Java and for such a big project Java is great. However, the mega-company that bought the company I work for a few years ago is mainly a Microsoft shop (whereas we were a Java previouly Borland shop). So, I may very well have to get involved with .NET and if I do I will consider IronRuby for any work that I perform. Of course to be really interesting IronRuby will have to remain strictly compatible with the real thing. The only exception to this rule is any special mechanism required for integration into the platform. There should be very little of this. JRuby the Java Ruby implementation added a keyword to used Java library classes and this is ok. I will expect IRonRuby to be as minimal as far as deviation from the standard are concerned. JS

Justin James
Justin James

All of the things you've listed are reasons why I am attracted to Ruby (don't worry, you helped, not hurt!). The things that drive me away are nearly, 100% RoR related, beleive it or not. That is one reason why IronRuby appeals to me. I think that without IronRuby, my choices are either CGI (no, thank you) or RoR (no, thank you). At this moment in time, I feel thatr ASP.Net, flawed as it is, as miserable as it can be, is the best framework out there for serious Web development. Not that it is great (or even good), but that it is the best game in town. Being able to use Ruby in it appeals to me a lot. My negative thoughts towards RoR are almost exclusively based on the videos on their Web site. There is something about a framework in which the directory structure is so closely tied to the functionality which makes me queasy. Part of it is that it perpetuates the broken page model of Web development, we need to start working at a much more discrete level of functionality folks. The other end is a combination of access rights and maintenance problems. Enforcing a directory structure is like enforcing a particular commenting style, IMHO. Nother against RoR, it looks like a good platform for a *dynamic Web site*. But I work on *Web applications* which have an entirely different set of challenges; if anything, RoR's structure makes meeting those challenges more difficult. J.Ja

jean-simon.s.larochelle
jean-simon.s.larochelle

..development. I did read a number of good review about it. The Ruby language I think you will definitly like. Of course it will depend on how good is the IRonRuby implementation. I also maintain my comment that it should be very close to the Ruby interpreter definition of the language even for someone who plans to stick with .NET. JS

apotheon
apotheon

First-class lexical closure is one of the killer features that I always look for in a new language. It's a must-have. They're not the most commonly used construct in a program, but there's nothing that really fills in for them sufficiently when a proper lexical closure is what I need. In addition to the "special type of function pointer" explanation, you might also think of a closure as an object++. Closures provide more complete encapsulation and protection than objects in (almost?) every OO language out there, and they are more easily passed around, used to maintain persistent state, and generated as needed than basically anything else more complex than a variable, constant, or symbol (in the Ruby or Lisp sense of the term). I first learned about first-class lexical closures in Perl, and found that Ruby handles them quite well, also. Rumors suggest that Python has finally gotten around to supporting proper closures as well, though Java is still limping along with half-baked wannabe closures. Of course, I think lexical closures were invented in some Lisp dialect or other -- possibly a Scheme.

Justin James
Justin James

I could not agree more. Closures are by far the most powerful element out there in programming that I have come across. Once you have closures, many other deficiencies in a language can be rendered irrelevant. I first encountered them in Scheme, my 3rd year of instruction, and ever since then, I use them whenever available. I'm glad that C# finally "gets it", and they are coming in VB 9 (should be the VB.Net in .Net 3.5) as well (not sure how good they are in either language yet). Yes, they are in Lisp proper... indeed, Lisp is more of a shortcut to closures than anything else (I beleive they are called macros). One of the most bizarrely unique and fascinating aspects of Lisp is that through definitions and closures, you can use Lisp to re-write Lisp to suit your needs. I am not sure if Lisp *invented* closures (it is a very old system), but it certainly introduced them to a lot of people at the very least. J.Ja

alaniane
alaniane

however, I probably will not use Ruby or Python since I rarely write web apps. Most of the programming I do is on the backend at the database level. Still, I may play with it.

Tony Hopkinson
Tony Hopkinson

OO languages with dynamic typing. Interpreted vs compiled can be a consideration, but if so you'd have to throw any .Net or Java environments in the bin as well. That could be ncessary of course.

apotheon
apotheon

Ruby and Python are not simply web development languages. They're useful for a lot more than that.

apotheon
apotheon

Ruby's used for lots of stuff, including some astronomy research work, AI research, and even some of the software management system utilities for the FreeBSD operating system. There are a lot of good libraries for Ruby, including some database API stuff. In fact, one of the defining characteristics of a good language for web development is that it must provide a decent interface to some of the most popular database management systems.

alaniane
alaniane

I took a look at Ruby and it does appear useful at more than web development. I falsely assumed they were web development languages based on the sites that I saw them mentioned on. I liked some of the features of Ruby; however, currently it is not liable to help me since I am doing more SQL and T-SQL programming than anything.

Dr Dij
Dr Dij

with Iron Speed Designer, right?

Justin James
Justin James

Iron Speed Designer is a tool for rapidly constructing applications based upon a DB schema (that's my understanding of it, at least). IronRuby is an implementation of Ruby on the .Net platform, similar to IronPython being an implementation of Python on .Net. Not quite sure why they chose the "Iron" moniker though. One trend I hanve noticed, is that things that come out of Microsoft Research tend to be "Sharp" like F# and Spec# (I beleive that C# was originally a Microsoft Research project as well). The CodePlex related projects are "Iron" (IronRuby, IronPython). It's kind of like when you realize that all Ford SUVs have an "E" name (Excursion, Escape, Expedition, Explorer) or all GMC trucks are named after mountain ranges (Sierra, Silverado, Denali, Yukon, etc.). Kind of makes me wonder why it is and such. J.Ja

oisleach
oisleach

I have been duped and locked into microsoft development before. Now my company has a strict rule. If the OSF says it is not open source then we will not use it. If the app is freeware, we can use it in enigneering and development, but it will not be used in the field. This is one company that will not depend on microsoft ever again.

Justin James
Justin James

The GPL (particularly v. 3) is just as "lock in" oriented as Microsoft, it is just designed to lock you into the license, not the technology. J.Ja

Tony Hopkinson
Tony Hopkinson

Do bear in mind it's an implementation, takes Ruby code and converts it into .NET IL. Whether it keps up with mainstream Ruby, Python et al is certainly open to question. Not sure how it works out under mono, I've heard it should but other than that give your intent I can't see how you'd ever want to use it. Even if the OSF welcomed IronRuby with open arms it's still 'only' an interface to the .NET framework.

carlos
carlos

Well, the question is "will you try IronRuby" and my answer is most definately not. I just heard about Ruby about a month ago, and as a developer, I had a duty to run and read up on it ASAP. Maybe it's just the top X articles in google, but practically everyone who raved about it had some grudge against Microsoft in one form or other. - Not a reasonable argument to move away from your current development platform. Also, reading the posts here in TechRepublic, I'm not hearing that many good things about it - indenting sets blocks??? COME ON! - .."End If" is obvious, squiggly is annoying but still denotes the end of a block, but an indent??? Next you are going to tell me double spaces is the equiv of a "sleep function" - and double line spacing exits the application In the TechRepublic email that linked me to this article, Justin James says "it is a Web development framework and nothing more." So why switch to a something that seems to be just a fad (ranked NO. TEN of most used prog langs) Ok, ok, not a fad ...if you hate Microsoft. I'm sticking with .Net - it works, easy to use gets the job done and it's been around long enough to prove itself. If Microsoft embraces it, i MIGHT try it.

apotheon
apotheon

"[i]practically everyone who raved about it had some grudge against Microsoft in one form or other. - Not a reasonable argument to move away from your current development platform.[/i]" The fact that a number of people seem to have grudges against Microsoft in no way indicates that the programming language they're using is only useful to people with grudges against Microsoft. Also . . . if you're using IronRuby, you aren't moving away from the .NET development platform, since the point of IronRuby is that it's Ruby on the .NET development platform. "[i]indenting sets blocks???[/i]" That's Python, not Ruby. "[i]Justin James says 'it is a Web development framework and nothing more.'[/i]" That's Rails, not Ruby. So . . . now that I've just eliminated all of your complaints, perhaps you could start over.

apotheon
apotheon

"[i]What can it do that the .net platform can't?[/i]" Ruby is a language. IronRuby is a variant implementation of that language. The .NET platform is a development framework, and you can use a whole bunch of languages with it -- including IronRuby. Thus, asking what you can do with Ruby that you can't with .NET is kind of like asking what you can do with a Toyota Prius that you can't with the New Jersey Turnpike. You can use a Prius on the Turnpike just as you can use a Ford Taurus there. . . . and darn it, I've used a car/computer analogy again. I really need to stop doing that. [b]edit:[/b] While I'm at it -- Rails (also known as Ruby on Rails, because it uses the Ruby programming language) is a web development framework. Rails is not the same thing as Ruby just as C# is not the same thing as the .NET framework. In fact, the .NET framework and the Rails framework are not even exactly comparable -- for that, you'd need to compare Rails to something like ASP.NET instead.

Tony Hopkinson
Tony Hopkinson

C# and VB.NET are statically typed. If you want a list of things in python you do this myList = [0,"Fred", 78.059,['x',67,"Bill]] (It's called a sequence in Python). You'd have to do a lot of arsing about to get that into C#. :D This is not free of course, but nor is generics. Whether you have a good use for dynamic typing or not, scripting is an extremely powerful tool. Lets say you have an object with lots a numerical properties, some of which are calculated. But the calculations are sspecified by a third party, the government in my case, but it could just as easily be a customer. The calcs change frequently or can be adhoc, properties may be added or removed from the class again on the direction of a third party. If don't want to have to code for every potentiaal situation scripts are your best buddy. You write something to get the script from somewhere, you pass in your .net class, it does it's stuff you get the class back and save the answer. Running scripts from executables in windows has always been a massive pain, with .net and one or even many of the iron*.dlls it's not. About ten lines of code and you can configure in the business logic, possibly without even having to compile. Don't have to write your owwn language and parser, no shell and wait, no file permisssions, no dumbass f***wit exit codes. It just works. .Net I find pretty impresssive for busines applications, adding dynamic scripting is just outright wonderful. I'm, not now and never have been a big fan of MS, but this one they have got right. MS admittledy didn't think of it, but they are running with the ball big style now.

carlos
carlos

To the fellas that replied to my post - thanks for the explanation(s). I must admit, when I first heard of "Ruby" - it was "ruby on rails" so that's what i googlewhacked. I didn't realize there was a big distinction as you guys have described to me. What can it do that the .net platform can't? I keep hearing that .net isn't TRUE obj oriented programming - who can explain? i thought .net was very Obj oriented..... I'm not seeing the reason to switch...

Tony Hopkinson
Tony Hopkinson

IronRuby and IronPython are .NET, that's the point of them. They bought out Jim Huggins who did IronPython, they have brought out a DLR (Dynamic Runtime Library), SilverLight is basically built on the idea. Time to take your blinkers off, before you get blindsided. If you need the power of scripting in .NET, your alternative is windows scripting host and messing about with exit codes... So Iron.... is a no brainer except for whether you choose IronRuby, IronPython, even JavaScript will be available, though that would be a numpty choice in my book.

alaniane
alaniane

From what I read in the comments, Python is the one that uses identation to parse the code and not Ruby. Also, the article mentions RoR (Ruby on Rails) as being a Web development platform. RoR is different from Ruby just like Basic is different from VB.Net.

apotheon
apotheon

I'm unlikely to give IronRuby a try, in large part because I simply don't do any work that requires .NET, and I'm already using (the original) Ruby on non-MS platforms. If I were to find myself in the position of developing with the .NET framework, though, you can bet your left foot I'd be giving IronRuby a try.

Tony Hopkinson
Tony Hopkinson

concept for a new project. There were a few wrinkles to work round, but it worked like a charm. Certain aspects of Python as a langauge don't impress me though (indent to get a block statement is moronic in my opinion), so I'm going to have a look at IronRuby as an alternative. Still on the original .9 at the moment, will pick up the later version soon. I'm hoping they solved a horrible performance deficit. From my investigations it would appear that every time you reference an unimported .net class instance in the script, it walks teh reflection tree. Gained performance, by assigning the object properties to local variables. It also appears that if you import it into the IronPython Engine, it's doing a shed load of work every time you execute the script. The engine does not provide an option to persist the environment. Talking about 60 -70 times slower by the way. I wanted it for inline auto calculation scripts and validations, which change year on year and under guvmint control.

Chuck.Esterbrook
Chuck.Esterbrook

Don't you indent your blocks in C#, Java, etc. anyway? Every program I see in the "curly brackets" language does so for formatting reasons.

jean-simon.s.larochelle
jean-simon.s.larochelle

I'm not convinced. I don't pretend to be perfectly rational and objective about this indentation business. But I don't think this is a problem since I'm perfectly happy with Ruby and you seem happy with Python. I think that it is impossible to remove all subjective elements involved in language selection. Thanks for your comment anyway. Who knows, it might eventually work like a worm and destroy this rule about indentation that seems to be deeply buried in my neural net. :) JS

Chuck.Esterbrook
Chuck.Esterbrook

I'm going to use underscores here because most comment systems strip leading whitespace. Check out this C (or C# or C++): ____if (x>y) ________if (y>z) ____________doSomething(); ____else ________doSomethingElse(); The programmer's intent is expressed through his indentation: he meant for the "else" to go with the first "if". But the compiler can't read his mind or his whitespace, so it puts the "else" with the *2nd* "if". This is a well known weakness in languages that neither use indentation nor require block delimiters. Regarding Fortran, it's use of columns has nothing in common with Python which will not convert code to comments, ever.

jean-simon.s.larochelle
jean-simon.s.larochelle

One advantage of the begin/end or curly braket approach is that it is more "typo proof". The closing bracket is also a hint when code spans two pages. I would be very nervous using a code formatting utility with Python. I guess also that part of the problem for me is psychological and goes back to the days of Fortran on punch cards. If I remember correctly I had a bug once because a line was turned into a comment because it started 1 column off. JS

Justin James
Justin James

I always do my indentations, but I do not always do them the same as the person sitting next to me. That's my gripe with mandatory indentation, it is a topic of religious wars, so to enforce it is dangerous. That is like if a language enforced Hungarian notiation (although it can be argued that languages that use symbols to denote type, like Perl does, enforce a type of notation). It would annoy everyone who did not like doing it "just like that". I have seen a lot of code lately (not written by me) that almost entirely eschewed indentation on the part of the coders, for whatever reason. J.Ja

Tony Hopkinson
Tony Hopkinson

But that's for readability not the compiler. I can sort of see the reason for it as the guy who designed it was a making coding approachable nut, but personally I think it makes it more difficult for us. As for the parser, tokens to mark up statement blocks were invented to make implemnenting one easier. Guess mostly it's just what I'm used to, but there are reasons why I have got used to it. :D