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.
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!
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.
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 :(
> 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.
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).
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
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.
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).
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#.
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.