Hacker News Reader

Comment by localhost | Hacker News Reader

My first job at Microsoft was to build IronRuby, which was an implementation of Ruby on top of the Common Language Runtime. I got the job because I had built a bridge that connected MRI (Matz's Ruby Interpreter) to the CLR before I joined the company. This project ultimately failed because of a principle that we learned from the school of hard knocks: respect developers' existing code investments. Developers couldn't use it because many of Ruby's existing libraries were thin wrappers over native code, and we couldn't get them to work for many reasons.

It turns out that the project was more of a demonstration of our ability to get dynamic languages to run efficiently on the CLR. To that end, I think we were successful. But once we achieved that there was not much of a path forward so the project was eventually shuttered.

View on HN

We use IronRuby for a monitoring application at my job. Its provides dashboards with hundreds of red/green annuciator tiles that users across the enterprise can create and customize. They can make a call to an API or run an SQL query or whatever and then as part of the tile configuration they include a few dozen lines of Ironruby to determine if the query results are good or bad and what messages to display on TV screens around the offices.

We couldn't have made it user customizable without something like IronRuby, thank you so much for implementing it!

Wow. Thanks for sharing this! I had no idea that it was still being used somewhere. I'll share with folks on the team that I'm still in touch with!

I remember IronRuby. It was a great demonstration and I think you inspired a lot of folks who came after.

Maybe it didn't accomplish your original goal, but props for what you did accomplish. Quite impressive.

IronRuby may not have succeeded but it and the DLR were inspirational, and I don’t think I’d have been working on JVM based language implementations for the last decade and a bit without initially being to point at things like IronRuby and say, “We know it’s possible.”

I got so much mileage out of the DLR they built to support those languages even if things didn't work out afterwards. To this day, I don't think anything as effective exists anywhere in language tech land.

Was this basically what doomed IronPython also?

I remember a conversation ages ago about how you couldn't really get a (common?) lisp running properly, irrc due to limitations in the way CLR modeled classes amongst other things, but FFI came up there too.

Yes. The problem was that the interpreters for both languages did not have a well-defined FFI. From a native library you could reach up into the interpreter and party over the AST to your heart's content. We couldn't in any practical sense emulate those data structures from the CLR which meant that native libraries couldn't run. That meant that existing scripting code that used those libraries would need to be rewritten to use an equivalent .NET library (e.g., regex). We naively thought that was what people would do and that turned out to be a mistake :(

What do you mean by well defined FFI? Why couldn't calls to native libraries be marshaled?

Iirc They did something like this for c++ and it wasn’t pretty but I can’t remember details, it may have been mostly because of the unstable ABI.

> That meant that existing scripting code that used those libraries would need to be rewritten to use an equivalent .NET library. We naively thought that was what people would do...

AFAIK, that's what JRuby does but Java had (has?) a bigger community and is more platform independent. Microsoft was a different company back then and wasn't supported on Linux. Betting on IronRuby/IronPython meant you had to use Windows as your platform.

I think it was in part because in 2010, Microsoft was already switching gears to Windows 8. A part of that was DevDiv getting sidelined by Windows. Windows was not a fan of .NET in general since Longhorn/Vista, but more importantly, the grand plan for Win8 involved the brand new application framework, WinRT. So when it came to VS 2012 and .NET 4.5, the emphasis was on WinRT interop - which is not a scenario where DLR is useful.

It's a good thing that DLR is still there, though. While undeniably niche, sometimes it makes things so much easier. For example, I've used it to support dynamic reloading of C# code in a game, for rapid prototyping of mods.

Our funding was gone by April 2009 IIRC, which was before Windows 7 shipped. Jim Hugunin and I shopped the team around and eventually landed in the Technical Computing org. The only thing that survived from that era was Python Tools for Visual Studio.

> respect developers' existing code investments

As a former Microsoftie myself, it saddens me that the company seems to have forgotten this.

For what it’s worth, I’m pretty sure we still have a little bit of iron ruby deep within some of our build tooling.

FWIW I remember IronRuby quite fondly. If not the outcome, the effort.

Does this mean a version of VB6 (classic ASP) could run on .NET Core (Linux)? That would finally liberate the language from the platform (IIS on Windows).

No. But in theory you could implement a wrapper, sure. But do yourself a favor, and just rewrite your application with a modern framework.

I agree, many benefits would be realized in a modern framework.

With so much functionality stored in stored procs, VBScript was essentially just looping records and writing things out to tables. But there was lots of business logic there too.

It felt like I had a purpose liberating "old database" logic into application code--the sky castles of Brooks, as it were--where it could be changed "more easily."

Given the app was ported to C#, I suppose the stored procs would be the last to go.

Recently, I learned Cloudflare had started with lots of the domain living in the db. So it is not an unfamiliar technique, but a pleasant surprise to hear of it (for me).

The business logic you may be able to convert to VB.net. It’s a bit weird but not worse than C#.

At least one product was developed in VB.NET. We tried to keep the current conventions when maintaining or extending it. It was mostly a wrapper around stored procs, so just a lot of Response.Writes.

For some reason, to me VBScript feels like I can whip up something really quickly, and VB.NET is "all the power of the CLR, with a bit of sugar to help transition to .NET."

VB.NET does feel a bit weird. Maybe some compromises to transition folks to .NET, and from there to C#.

Classic ASP used VBScript, not VB6. These two are closely related but not quite the same.

And the answer really depends on what you mean by "run on". .NET already supports two-way COM interop, and it does work with DLR to handle stuff like IDispatch. But the COM code in that scenario is still native (or, in case of VBScript, intepreted by its Active Scripting provider).

Implementing VBScript, or even VB6, as a language running entirely on top of .NET, is certainly possible, although it would be somewhat awkward because the object model in VB pre-.NET was specifically designed around COM. You can port the templating engine, as well. But the real hurdle is not the language - it's all the APIs. ASP itself was pretty basic, but most web apps would also need to talk to the database - so now you need ADO. And then there are all the third-party components, most of which were proprietary binary blobs compiled for 32-bit Windows.

And, well, why? There are many better languages running on top of .NET these days, starting with VB.NET.

You're right. It's mostly nostalgia value :) Although I have been a hosting customer for a while now.

ES3 is nice, and short of prayer or sacrifice one was able to import Crockford's JSON library and Ramda. Server-side Node.js without npm (for better or worse).

With Babel, the idea was to use ES6 constructs and transpile it down to something IIS could run. Or Ruby, or anything else, and VBScript becomes kind of like the "machine language" description of the program.

VBScript is less painful with aspunit [1] and plenty of comisseration/resources with drian bamaged [2], aXe, and even [3].

It was amazing how much could get done with Microsoft SQL Server, a loop, and Response.Write(). Enough to build a company and to get acquired, even. Could have been a right place/right time thing for the owner.

  [1] https://github.com/rpeterclark/aspunit
  [2] blogsite
  [3] the person with the classic ASP book

I would start looking here: https://github.com/aspcompiler/aspclassiccompiler

Thank-you, that looks like the most feasible approach for VBScript: given existing code, run it through something that would convert it to .NET.

That reminds me: it actually happened. An existing VBScript parser was used with a custom C# transpiler to generate the port to .NET, in order to realize performance and maintenance benefits.

Reply on news.ycombinator.com