Home
FAQ
Feedback
Departments
Discussions
(new topic)
Language Evaluation
PL Courses
Research Papers
Design Docs
Quotations
Genealogical Diagrams
|
|
|
|
cross-language-runtimes
| CLR Hosting |
|
Lisp oriented weblog you say? It seems like we are turning into a .Net weblog...
Chris Brumme is on a roll. This gargantuan entry concerns hosting the CLR in such environments as SQL Server and ASP.NET.
My background as a system programmer and DBA makes me especially fond of the issues involved in hosting language runtimes, and Chris's discussion makes for very interesting reading.
Two side notes:
The vast majority of execution inside SQL Server was via Transact SQL or TSQL. Any application written in TSQL is inherently scalable, fiber-aware, and robust in the face of resource errors. Any computation in TSQL can be terminated with a clean transaction abort.
Unfortunately, TSQL isn’t expressive enough to satisfy all application needs. So the remaining applications were written in extended stored procedures or xprocs. These are typically unmanaged C++. Their authors must be extremely sophisticated, because they are responsible for integrating their execution with the unusual threading environment and resource rules that exist inside SQL Server. Throw in the rules for data access and security (which I won’t be discussing in this blog) and it takes superhuman knowledge and skill to develop a bug-free xproc.
In other words, you had a choice of well-behaved execution and limited expression (TSQL), or the choice of arbitrary execution coupled with a very low likelihood that you would get it right (xprocs).
This gives a nice perspective on DSLs vs. general purpose languages.
From time to time, readers of my blog send me emails asking if there are jobs available on the CLR team. At this moment, we do. Drop me an email if you are interested and I’ll forward it to our recruiter and our hiring managers.
If you are looking for a job in industry at the moment, I suggest taking a close look at this opportunity.
Posted to cross-language-runtimes by Ehud Lamm on 2/22/04; 1:23:01 AM
Discuss (13 responses)
|
|
| Finalization (CLR) |
|
Finalization can be a tricky business, but as usual Chris Brumme provides a detailed and readable explanation.
One wonders about the cost/benefit ratio of confusing language constructs like finalization methods. Surely, there has to be a better way?
This paper may also be of interest.
Posted to cross-language-runtimes by Ehud Lamm on 2/21/04; 1:14:11 AM
Discuss (6 responses)
|
|
| Generics in the CLR (MSDN) |
|
This month I'll dig deeper into the internal workings of the CLR with respect to generics. I'll cover type constraints, generic classes, methods, structures, and the upcoming generic class libraries.
Nothing particularly new here. This article includes a nice discussion, which might be worth a look, about the benefits to implementing generics at the runtime level, rather than at the compiler level.
Posted to cross-language-runtimes by Ehud Lamm on 2/12/04; 2:23:58 PM
Discuss
|
|
| CLR Design Choices |
|
A new installment of Bill Venner's interview with Anders Hejlsberg.
Some of the issues mentioned are interesting from a language design point of view. Others are more implementation-oriented and concern the design of the VM and IL.
Posted to cross-language-runtimes by Ehud Lamm on 2/4/04; 12:01:46 AM
Discuss (5 responses)
|
|
| The Revised C++ Language Design Supporting .NET |
|
How should we declare and use a .NET reference type? It differs significantly from the C++ Object Model: different memory model (garbage collected), different copy semantics (shallow copy), different inheritance models (monolithic, rooted to Object, supporting single inheritance only with additional support for Interfaces).
Stanley Lippman has a blog, ee i
ee io.
If you want to see the answer visit Stanley's next entry.
This might be a good time to point out that the Microsoft lingua-bloggers (e.g., Brad Abrams, Brandon Bray, Chris Brumme, Eric Gunnerson and Paul Vick) are changing the landscape of language design. More transparency, more community involvement, and perhaps most importantly for us: giving language design the status it deserves.
Note: I am no Microsoft fan, and the last sentence isn't intended to imply that the resulting languages are any good. Only that the process is a bit different than it was only a couple of years ago.
It is well worth asking whether language design benefits from this sort of openness, or whether a lone developer has a better chance of coming up with a coherent and usable language (think of your favorite language designer). Even if you favor openness, keep in mind that most programmers lack experience in language design. They may have good ideas for libraries, APIs etc. But do they really understand the implications of their suggestions on the compiler, the type system, or even on the run time system? Some obviously do. But aren't these the same people who were involved all along (via ISO, CS departmental seminars, conferences, etc.)?
Posted to cross-language-runtimes by Ehud Lamm on 12/2/03; 1:44:09 AM
Discuss (2 responses)
|
|
| First WinFx "application" written in SML |
|
Via Brad Adams we find this cool example: Standard ML code that uses the new System.Windows.Explorer.Item class.
Among the highlights of this ~20 line toy program is Enumerable.app, a part of the sml.net library that endows IEnumerables with functional abilities like apply, map and fold (morphisms shmorphisms, right?)
Marc Miller asks Isn’t cool that so many languages are getting implemented on the CLI, and can therefore target WinFx?
Well, if you are a programming language buff, it sure is.
Posted to cross-language-runtimes by Ehud Lamm on 11/7/03; 2:36:05 PM
Discuss
|
|
| CLR Panel notes |
|
The following is the "transcript" I took of the "Designing the CLR" Panel discussion. We had probably around 200 people in attendance, with an open mic forum. The Panel was swamped with standing room only folks at the end (about 40 up around the stage with lot's of questions). At the panel we had Brad Abrams (CLR BCL PM), Anders Hejlsberg (Distinguished Engineer, C# architect, Chris Brumme (CLR Architect), Patrick Dussud (lead CLR Architect), Jim Miller (CLR Architect), Sean Trowbridge (CLR Architect), George Bosworth (CLR Architect), and Jonathan Hawkins (CLR PM/Moderator).
It's PDC week, you know... So don't be alarmed: Haskell and such will return shortly.
Some interesting stuff regarding the memory model, support for AOP, and contracts.
Posted to cross-language-runtimes by Ehud Lamm on 10/30/03; 11:52:55 AM
Discuss (6 responses)
|
|
| Introduction to the Base Class Libraries (.Net) |
|
The Base Class Libraries (BCL) provides the fundamental building blocks for any application you develop, be it an ASP.Net application , a Windows Forms application, or a Web Service. The BCL generally serves as your main point of interaction with the runtime.
Not very exciting, but still...
Of specific interest: System.CodeDom (all the support necessary to be able to create code, and run it, on the fly) and System.Diagnostics (event logging, performance counters, tracing, and process management APIs).
Posted to cross-language-runtimes by Ehud Lamm on 10/28/03; 2:10:22 PM
Discuss (2 responses)
|
|
| PDC: Designing the CLR |
|
From "Everett" to "Whidbey" to "Orcas", the Common Language Runtime is evolving, with new features and improved performance in each release. Come hear the story of the CLR and discuss with the CLR architects how they designed the wicked features, and their approach to topics such as performance tuning.
See previous item. This panel includes Chris Brumme, which should make going to the PDC worthwhile...
A related panel which also looks interesting will discuss Hosting the CLR in Your Applications.
Posted to cross-language-runtimes by Ehud Lamm on 10/15/03; 2:59:06 PM
Discuss
|
|
| The Future of .NET Languages |
|
One of the unique aspects of the .NET platform is its support for multiple programming languages, with over 23 available today. How do these multiple languages influence the design of the CLR and CLS? How can languages written to the CLS differentiate themselves from one another? Join the architects of languages including C#, C++, VB.NET, Eiffel, and Cobol to get their insight on how they design new language features, for "Whidbey" and beyond.
One of the more interesting panels planned for the upcoming PDC.
The web page allows you to submit questions for the panelists, as well as to vote for questions already posted.
Since the answers should find their way to the web, even those not planning to attend the PDC may want to submit questions.
Among the panelists you'll find Anders Hejlsberg and Erik Meijer, representetives from the VB team and the Visual C++ team, as well as others.
Posted to cross-language-runtimes by Ehud Lamm on 10/15/03; 2:51:55 PM
Discuss (2 responses)
|
|
| CLR Exception Model |
|
Chris Brumme has more than you ever wanted to know about this subject...
Well, if you share my tastes you are going to find the discussion of managed exceptions interesting and have a lot to say about the Performance and Trends section, but find the explanation of the Windows Structured Exception Handling (SEH) way to detailed. But then, if you are working on implementing a compiler for this platform at the moment, you'll find the details indispensable.
I guess Chris has a point when he says that if you actually want to know more, perhaps you should just apply for a job on the CLR team...
Posted to cross-language-runtimes by Ehud Lamm on 10/2/03; 12:20:26 PM
Discuss (6 responses)
|
|
| Environment, scripting, and behavior |
|
Jon Udell on VMs and dynamically typed PLs:
Mark Dulcey wrote to point out that the Parrot VM is not intended to support Perl only, but any dynamic language ... It would be best, in my view, if the JVM and CLR could serve this purpose. My gut tells me the obstacles are cultural, not technical.
And
I'm no VM guru. Maybe there really is no way for the JVM and CLR virtual machines to properly support dynamic languages. But somehow, I doubt that.
Putting aside the ST vs. DT argument (if we can :-) I think we can all agree that it would be for the best if a single VM could support both as first class citizens. Is this possible?
Posted to cross-language-runtimes by Dan Shappir on 3/24/03; 12:50:57 PM
Discuss (8 responses)
|
|
| Introduction to Managed C++ |
|
Managed Extensions for C++ are extensions to the Visual C++ compiler and language to allow them to create .NET code and enable access to the functionality of the .NET Framework. They include a set of Keywords and Attributes to extend the C++ language to work with, and generate, managed code. There are also some additional Pragmas, Pre-processor Directives, and Options for the Compiler, as well as some Linker Options. The first interesting thing to notice is that the Managed Extensions use C++ keywords and syntax, but they follow .NET rules for types and facilities. This creates, in effect, a language within a language.
Sam Gentile is writing a three article series on Managed C++.
I think it is obvious why we need to know about MC++, this being a Microsoft world and all.
From a more technical point of view, it is worth keeping in mind that much as we may approve of VM based language platforms, there are still many reasons for using native code. Thus, the ability to mix and match is very important, even though it introduces its own set of difficulties.
Posted to cross-language-runtimes by Ehud Lamm on 1/14/03; 12:59:04 AM
Discuss
|
|
| Polyglot Programming |
|
What does it take to support several programming languages within one environment? .NET, which has taken language interoperability to new heights, shows that it's possible-but only with the right design, the right infrastructure, and appropriate effort of both compiler writers and programmers.
An article by Bertrand Meyer, first in a three-part series.
Note that registration (free) is required to read this article.
The more than 20 languages ported or in the process of being ported to .NET range from Cobol and Fortran to Smalltalk, Oberon, Eiffel, Java, Perl, Scheme and Python. How does this all work? Do languages have to sacrifice anything? Should we believe those who say that it's all smoke and mirrors, and that deep down, all languages get reduced to a common denominator, whether we call it C#, Visual Basic .NET, managed C++ (or Java)? These are some of the questions I'll examine in this three-part article.
Posted to cross-language-runtimes by Dan Shappir on 10/9/02; 9:50:50 AM
Discuss (4 responses)
|
|
| USENIX JVM Symposium '02 |
|
This was, without a doubt, one of the most interesting conferences I've ever attended. Blatantly research-oriented and academic in nature, the technical sessions were fascinating to watch.
Interesting conference report.
I am interested in the Machine Learning for Memory Management concept. I am a long time fan of adaptive software (self-tning software, if you will). I am also interested in seeing real life examples of machine learning outperforming static heuristics. This is not as common as you'd think.
Posted to cross-language-runtimes by Ehud Lamm on 8/19/02; 5:18:10 AM
Discuss (2 responses)
|
|
| Generating Code at Run Time With Reflection.Emit |
|
Registration is required to access this article.
the .NET Common Language Runtime (CLR) contains a whole namespace full of classes to help us build assemblies, define types, and emit their implementations, all at run time. These classes, which comprise the System.Reflection.Emit namespace, are known collectively as "Reflection.Emit." ...
In much the same way that XML has saved us from ever again needing to design low-level file formats for our apps, Reflection.Emit technology may save us from ever again having to devise our own state machines (like regular expression engines) that are so commonplace in advanced applications.
Close your eyes, and imagine the possibilities: parsers, interpreters, state machines, static table-lookup code... All of these things and more can now be implemented as fast, native code, optimized for each individual user's platform, thus offering a level of performance never before attainable. The Age of The Interpreter might finally be over.
Chris Sells and Shawn Van Ness demonstrate the use of the .NET Reflection.Emit services that let use generate IL code on the fly. They also provide a very quick IL tutorial and discuss the concepts of validity, verifiability, and security.
Posted to cross-language-runtimes by Dan Shappir on 8/18/02; 8:39:03 AM
Discuss
|
|
| Parrot In Detail |
|
Just to counter-balance the .NET coverage,
here's an overview of Parrot,
a highly reconfigurable multi-language virtual machine
(Perl, Scheme, Python, BASIC, Jako, Cola).
The VM provides a "single point of abstraction" for
async I/O, threads, events, and objects.
Uses "arena" Allocation of core structures
(see David Hansen's Advanced C book
Main,
Arena.c)
and three separate threading models.
A register-based virtual machine, unlike the stack-based JVM and .NET CIL.
(See this
recently published VM book.)
Dynamic opcodes allow the VM to run code
from other virtual machines such as "JVM, .NET, Z machine, Python, Perl 5, Ruby."
The VM has a regex engine that "can act as a
parser as well as just a regex engine."
Parrot has a tracing, compacting
garbage collector, not the reference counting that
scripting languages typically employ.
There is a
tutorial
at the main site
and an O'Reilly book available.
A recent
questions answered session
by a principal developer and an interesting
thread.
A Scheme port is included in the distribution
but the presentation does not mention any of the features
to support functional programming that the
ILX extension to the .NET runtime
adds like closures, thunks, and parametric
polymorphism.
In short, it's hard to get up to date information on the Parrot
Virtual Machine and the link to the distribution at CPAN from the
main site
is broken so it's even a little hard to get your hands on it.
Posted to cross-language-runtimes by jon fernquest on 7/28/02; 3:01:32 AM
Discuss (2 responses)
|
|
| Rotor, SemiWorks, and Technology Transfer (job opening) |
|
The CLR and Rotor product teams are creating a technology transfer team that can take on the major challenge of applying ideas that have been prototyped using the Rotor code base. The code name for this team is "SemiWorks"
If you have PhD, are looking for a job, and you don't mind working for Microsoft, this may may be ideal for you...
We discussed the way languages evolve, and the differences between academia and industry. This is one possible approach for solving the technology transfer problem. I am far from certain this is the best way, by the way.
Posted to cross-language-runtimes by Ehud Lamm on 7/19/02; 1:33:17 AM
Discuss (1 response)
|
|
| Scripting and .NET |
|
The Microsoft .NET platform has a set of classes that offers the benefits of Active Scripting without the drawbacks. This set of classes, named Visual Studio® for Applications (VSA), provides a pluggable IDE and debugger for Visual Basic® .NET.
But support for a hosted design-time environment is only half of the VSA story. The other half is the runtime. It doesn't come with an IDE or a debugger, but it is freely available with the standard .NET platform and has been engineered as the .NET replacement for the COM-based Active Scripting architecture.
While the interfaces look similar, the implementation of scripting on .NET appears to be very different than COM Active Scripting. First, the scripting languages are the same VB.NET and JScript.NET that you use in VS.NET, not a limited subset. second, the code is compiled to a native .NET assembly and executes as native code. Third, .NET allows scripts to directly access all of the .NET BCL, including the interop layer (I'm not sure how script "safety" is enforced in this environment.)
Posted to cross-language-runtimes by Dan Shappir on 7/17/02; 6:57:02 AM
Discuss
|
|
| Exploring .NET Alternatives |
|
via Slashdot
NM: What are the strengths of C# that make it worth porting to Linux in the first place?
MI: I would say that the major strength of C# comes from it being like Java, but it goes beyond that. It's not simply that you have a new language and a new runtime engine, so now you have to rewrite your code and deploy it into this new platform. It's more of an evolutionary approach. For example, you might have some existing code. You get a way to keep your code, and we're going to provide you with all sorts of mechanisms for you go grow that code with this new runtime. So if you have 10 million lines of C code, you're not going to drop them. Instead, you extend your existing 10 million lines of code with probably a hundred thousand lines of C# code. That's the first step. And, eventually, you'll probably migrate the whole application over. It might take you 10 or 20 years to bring the entire application over. Your app might always be a hybrid. It doesn't matter; you can do it always with .NET.
An interview with Miguel de Icaza, cofounder and CTO of Ximian, on the Mono project. Mono has been discussed here before, but this interview provides some additional insights as to the motivation behind this project.
Posted to cross-language-runtimes by Dan Shappir on 7/17/02; 6:04:30 AM
Discuss
|
|
| Advanced .NET Remoting examples online |
|
As of today, all examples for Advanced .NET Remoting are now available in C# and VB.NET. Yes, each and every sample is available in both languages.
.Net remoting sounds really cool. Truth be told, I know practically nothing about it. But when I'll have the time to learn, I'd like to remember that these examples are available...
Posted to cross-language-runtimes by Ehud Lamm on 6/10/02; 6:47:51 AM
Discuss
|
|
| CLI Standard (ECMA-335) |
This is the ECMA standard for the Common Language Infrastucture. Defines the file format and the IL instruction set which I've been meaning to dive into one of these days - hopefully the standard is somewhat stable at this point in time.
Posted to cross-language-runtimes by Chris Rathman on 5/16/02; 7:53:18 AM
Discuss
|
|
| Shared Source CLI Beta |
|
(via Peter Drayton's Radio Weblog)
The Shared Source CLI goes beyond the printed specification of the ECMA standards, providing a working implementation for CLI developers to explore and understand. It will be of interest to academics and researchers wishing to teach and explore modern programming language concepts, and to .NET developers interested in how the technology works.
Now you can download the source and start hacking.
Posted to cross-language-runtimes by Ehud Lamm on 3/27/02; 6:00:41 AM
Discuss (7 responses)
|
|
| Tachy |
(via Patrick Logan's Radio Weblog)
Tachy is a Scheme-like (R5RS is the template, but not the goal) language that is being developed in C# for the .NET framework and is made available as Open Source (BSD License).
Assuming this trend continues .NET is going to be more fun than I expected.
Posted to cross-language-runtimes by Dan Shappir on 3/20/02; 6:56:17 AM
Discuss
|
|
| Microsoft Visual J# .NET Beta 2 |
|
The tool integrates the Java-language syntax into the Microsoft Visual Studio® .NET IDE, and supports the functionality found in Visual J++® 6.0, including Microsoft extensions such as JavaCOM and JDirect.
Also note that:
Microsoft Visual J# .NET is not a tool for developing applications intended to run on a Java virtual machine. Applications and services built with Visual J# .NET will run only in the .NET Framework; they will not run on any Java virtual machine.
And obviously:
Visual J# .NET has been independently developed by Microsoft. It is not endorsed or approved by Sun Microsystems, Inc.
I truly wonder if anyone will use this, and if so why.
Posted to cross-language-runtimes by Dan Shappir on 3/20/02; 2:29:36 AM
Discuss (4 responses)
|
|
| Ongoing Discussion on the Value of DotNet |
|
Peter and Patrick are discussing the merits of .Net
Most of the issues they raise were mentioned here in the past (e.g., compiling various languages into Java bytcodes/CLR). Still the discussion is worth following.
When I first saw Java I thought that the languages isn't that exciting, but I did like the language-as-platform idea. Seems to me like the next step is going to return to the distinction between language and implementation (think Java on CLR), and we'll just be stuck with the (not very exciting) languages Java and C# (and VB.Net). This is going to be boring.
The next step after that, let me venture a guess, is going to be allowing interoperability between the two platforms, using emulation and other tricks.
I think there's a good chance that these phases will happen at roughly the same time, so there's still hope.
Posted to cross-language-runtimes by Ehud Lamm on 3/13/02; 8:47:07 AM
Discuss (5 responses)
|
|
| Terrarium |
|
(via Scripting News)
Terrarium, a sample application built by Microsoft, is game for software developers that provides a great introduction to software development on the .NET Framework. In Terrarium, developers create herbivores, carnivores, or plants and then introduce them into a peer-to-peer, networked ecosystem for a survival-of-the-fittest type competition.
This sounds nice (many of you will remember Axelrod's repeated prisoner dilemma competitions). I use something like this when I teach about multi-tasking. Still, this is not really programming language related... But read on:
At present, creatures for Terrarium can be developed in either C# or Visual Basic .NET. This is to prevent cheating. As mentioned earlier, when a creature is loaded, its code is scanned by the Terrarium client to ensure that it does not harbor any functionality that could give it an unfair advantage over the other creatures. Static methods, threading calls, and deconstructors could all be used to effectively cheat. Unfortunately, some language compilers automatically generate a static constructor method, for example. The Terrarium code scan picks up on this and denies that code the right to run. In the future, Terrarium will support more programming languages.
Now that's what I call multi-language support: you can either use VB.Net (from Microsoft) or C# (which is made by guess who). I am sure this is a coincidence..
Still, you may be interested in reading the short description of Evidence-based and Code Access Security
Posted to cross-language-runtimes by Ehud Lamm on 3/12/02; 8:35:23 AM
Discuss (2 responses)
|
|
| Smalltalk and the CLR |
|
Two links to the same weblog in one day?! Well, how about that!
I think it is time to say the obvious thing about this language neutral runtime debate: Yeah, you can implement any language using these runtimes. Heck, you can implement any language using a LC evaluator. The problem is that if you expect the runtime to help you, you are probably looking for a runtime that isn't so damn neutral 
Posted to cross-language-runtimes by Ehud Lamm on 3/6/02; 12:35:27 PM
Discuss (1 response)
|
|
| The .NET team on VB.NET |
|
So despite the relative parity that VB.NET has achieved within the .NET language family, it's still seen, internally, as the "entry-level" language, which is rather surprising, because the entire rationale for the radical alterations to classic VB were to make it a "first-class" .NET language. Sridharan did hasten to add that any additional features would not detract from VB.NET's current capabilities.
I generally find the articles at DevX a bit light on content, but this interview with Anders Hejlsberg, Distinguished Engineer on the VS .NET Frameworks Team, David Treadwell, the General Manager of the VS .NET Developer Platform, and Prashant Sridharan, the Visual C# Product Manager, raised some interesting issues.
Until the release of .NET, VB has been positioned as the programming tool for "the rest of us". Its RAD environment enabled easier and faster development, the price to pay being some loss of functionality. Over the years, lots of hacks have been published on methods to circumvent or overcome VB's limitations, the most direct course being the development of add-on components in C++.
Microsoft has always been derided for VB's limitations and in .NET it has finally bitten the bullet and has brought VB.NET up to par with the other .NET languages (specifically C#). In my opinion this move, while supposedly benefiting VB, actually removed the rational for its existence. As far as I can tell, VB.NET is semantically equivalent to C#, moreover the development environment and toolkits are the same. Thus there is absolutely no advantage in using VB.NET over C# (maybe a slightly easier transition for those familiar with the VB syntax, though the changes might actually confuse them instead.)
It now appears that the .NET team is looking for ways to differentiate VB.NET as the entry level language, though with no specific details as to how this might be accomplished (or why any improvements that ease development should not be applied to other .NET languages as well). Maybe they should point beginners at Mondrian.
The article includes other interesting points:
- A rule-of-thumb as to how to distinguish between a VB programmer and a real programmer (according to Microsoft).
- The future of C# (generics).
- Finally "Both Bill Gates and Anders made a point of saying that future API's released by Microsoft would target the .NET framework rather than the C-style API releases we've seen from Microsoft in the past."
Posted to cross-language-runtimes by Dan Shappir on 2/18/02; 8:48:45 AM
Discuss (3 responses)
|
|
| One Runtime to Bind Them All |
|
(via CamWorld)
We follow with a partial list of limitations of the CLR/CTS/CLS...
The list of limitations includes:
- The CLS only supports single, static inheritance.
- There is currently zero support for generic programming in the CLS
- The CLS only supports a standard model of vtable-based / single-receiver method dispatch, static-typed signatures, and single return. There are no first-class methods.
Notice this is hosted on JavaLobby.
Posted to cross-language-runtimes by Ehud Lamm on 2/8/02; 1:48:50 PM
Discuss
|
|
|
