Lambda the Ultimate The Programming Languages Weblog - join today!

XML icon






(new topic)

Language Evaluation

PL Courses

Research Papers

Design Docs


Genealogical Diagrams

Join Now



Cross-language future of open source desktops

Havoc Pennington considers higher-level language authorship of future open source desktops like GNOME. Common-language runtimes are discussed. Someone from LtU should dive in.

It may not quite relate but I will plug my idea that languages should target a common intermediate compiler language, not a common language runtime.

via OS News

Posted to cross-language-runtimes by Mark Evans on 3/18/04; 8:58:32 PM

Discuss (6 responses)

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)

Basic Principles of Code Access Security
A nice little presentation over on MSDN TV about CLR security.

Obviously related to the PL-as-OS theme.

Posted to cross-language-runtimes by Ehud Lamm on 2/19/04; 3:47:02 AM


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


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, a part of the 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


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


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.


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)

S#.NET Tech Preview Release Information
If you are interested in efficient compilation of dynamic languages for .Net.

For the highlights check the LtU discussion group message I got this link from.

Posted to cross-language-runtimes by Ehud Lamm on 1/29/03; 3:17:47 PM


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


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)

Observations on CIL books
Peter Drayton has some useful comments about both of the IL books on the market.

Posted to cross-language-runtimes by Ehud Lamm on 9/30/02; 8:01:02 AM


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


Shared Source CLI Essentials (beta chapters)
(via Peter Drayton)

Shared Source CLI Essentials. By David Stutz, Geoff Shilling, Ted Neward. O'reilly (Nov. 2002)

Two beta chapters are available: types and memory management.

Posted to cross-language-runtimes by Ehud Lamm on 7/31/02; 11:05:06 AM


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)

Eiffel on .Net
From the LtU discussion group: A link to a paper by Bertrand Meyer about implementing Eiffel on .Net.

Posted to cross-language-runtimes by Ehud Lamm on 7/25/02; 2:33:27 PM


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


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


IK.VM.NET Weblog
I came across this weblog which may be of interest to LtU readers. It's tag line is The development of a Java VM for .NET.

Posted to cross-language-runtimes by Ehud Lamm on 7/4/02; 1:38:54 AM


Managed C++ FAQ
(via Peter Drayton)

This is not really a FAQ, in fact it is a weblog! This means that if you are really interested in MC++, you can subscribe to the RSS feed.

Posted to cross-language-runtimes by Ehud Lamm on 7/1/02; 1:07:29 AM


Mark Shields: A compiler writer's guide to C#
I found this link on Peter's weblog. This booklet is a great resource on C#!

Posted to cross-language-runtimes by Ehud Lamm on 6/10/02; 7:13:06 AM


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


Language Neutrality and the Java Platform
(via Programming Languages for the JVM)

Nik Boyd, the creator of Bistro, takes exception with the claim that the Java Platform is incapable of supporting languages other than Java - discussing how the Smalltalk object model was mapped on top of Java.

For an alternate viewpoint, David Simmons discusses why .Net has better facilities for support of SmallScript, a Smalltalk based scripting language. (Of course, would he'd really like is to have something along the lines of the AOS VM to support dynamic scripting languages).
Posted to cross-language-runtimes by Chris Rathman on 5/25/02; 6:37:03 PM

Discuss (3 responses)

Compiling Eiffel for the CLR
Bertrand Meyer explains an approach to compiling Eiffel's multiple inheritance into .Net's single inheritance model. Essentially, the solution is based on clever use of interfaces.

(From the LtU discussion group. Thanks, Dan!)

Posted to cross-language-runtimes by Ehud Lamm on 5/20/02; 2:40:28 PM

Discuss (1 response)

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


The Implementation of Model Constraints in .NET
Many people noticed this article...

.NET Extensions that provide an infrastructure for enforcing database-like data integrity constraints, such as Entity integrity, Domain integrity, Referential integrity, User-defined integrity.

Related to contracts and metadata.

Easter holiday is over. You can post now...

Posted to cross-language-runtimes by Ehud Lamm on 4/9/02; 1:28:36 PM


More Rotor links
Peter Drayton gives some interesting links about Rotor (the shared source CLI).

Posted to cross-language-runtimes by Ehud Lamm on 3/28/02; 1:24:43 AM


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)

(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


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)

Stacking them up: a Comparison of Virtual Machines
From the LtU discussion group!

Posted to cross-language-runtimes by Ehud Lamm on 3/13/02; 9:15:46 AM

Discuss (1 response)

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)

(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)

Making a decision: C# or VB.NET
I don't like language comparisons, since they usually produce more heat than light (they make you think about being closed in a dark oven..). This essay from Richard Caetano, however, is reasoned and well written. (And contains code examples!)

In a second piece Caetano discusses Drayton's brain teaser.

Caetano promises to keep discussing these issues on his weblog.

Posted to cross-language-runtimes by Ehud Lamm on 3/8/02; 7:33:46 AM

Discuss (1 response)

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)

Uncovering Rotor -- A Shared Source CLI
(via Peter Drayton's Radio Weblog)

Rotor is Microsoft's shared source CLI implementation.

This short essay explains the general design and possible uses of Rotor.

Admin note: I am far from being an expert on the topic of this LtU department. Your contributions are required if we want to have an informed discussion of these issues.

Posted to cross-language-runtimes by Ehud Lamm on 3/5/02; 10:50:56 AM

Discuss (2 responses)

Implementations of .NET-Targeted Languages Problematic
From the discussion group.

Notice: new department!

Posted to cross-language-runtimes by Ehud Lamm on 3/1/02; 1:39:52 AM


Continuing the theme of cross-language integration, here's one of my favorite "language gumbo" brainteasers...
Posted to cross-language-runtimes by Ehud Lamm on 2/26/02; 2:38:35 AM

Discuss (3 responses)

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


Don's Favorite Aspects of the CLR

This is just a short page on which Don Box, of the COM fame, lists the things that he likes about the Common Language Runtime.

Posted to cross-language-runtimes by Dejan Jelovic on 1/4/02; 3:44:53 AM

Discuss (3 responses)

Intro to the Common Language Infrastructure with David Stutz
(on TechNetCast)

CLR is the Mircrosoft commercial implementation of the CLI ECMA standard. Microsoft is also working on a shared source version, which will not include features not in the ECMA standard, that are built into the commercial CLR.

The shared source version uses a BSD like license.

Posted to cross-language-runtimes by Ehud Lamm on 8/11/01; 6:27:53 AM

Discuss (6 responses)

Languages for the JVM
This is a list of languages that have compilers targeting the JVM. Aside from Java, naturaly.

This effort has many interesting consequences. One is the sudden rise of languages with garbage collection...

This approach also opens new options for cross language programming.
Posted to cross-language-runtimes by Ehud Lamm on 9/3/00; 5:12:35 AM

Discuss (1 response)

Logs: Hack The Planet ; JavaLobby ; Daily Python-URL ; xmlhack ; PHP everywhere ; (more)
Wikis: WikiWiki ; Erlang ; Common Lisp ; Haskell ; Squeak ; Tcl ; Program Transformation
Print-Friendly Version
Create your own Manila site in minutes. Everyone's doing it!