.net and rebol

Osborn: Another area of confusion, I think, is understanding where C# stops and the common runtime begins. What's the innovation in the C# language itself versus what it gets from the common runtime library? Hejlsberg: Well, I think some of this confusion comes from the fact that when people talk about Java, they don't really know which is the language and which is the runtime. Some of this confusion arises when people talk about Java. Which is the language and which is the runtime? What do people mean when they say Java? Do they mean Java, the language, Java, the syntax, or do they mean Java, the platform? People lump these different aspects together. We've taken an approach that says we want to be a multilingual platform. We're going to build a platform that actually allows you to implement multiple programming languages and also have them share a common set of APIs (Application Programming Interfaces). Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did. We're not saying, "Now that there's only one language, there shall be no further innovations in this race." We're saying that our industry advances by its flexibility. How did Java come about? It came about because there were programming languages before it and there will be programming languages after it. We want to build a platform where your preference for one language over another doesn't negate the whole value proposition. We want to create a platform where there can be innovation. Who's helping COBOL programmers today? Who's taking them to the Web? Only on the .NET platform can you embed Fujitsu COBOL in an ASP page. I mean it's truly revolutionary. Osborn: Given the availability of multiple languages for the .NET platform, why would you choose C# over Visual Basic, C++, or even COBOL? What is it that makes C# so compelling? Hejlsberg: First of all, with C# we were able to start with a clean sheet of paper, so to speak. We did not have any backward compatibility requirements, and that certainly made things simpler. And not just from an implementation standpoint, but also from a usage standpoint. For example, we only have one kind of class in C#, and it is always garbage-collected. Managed C++, on the other hand, has two because it has to preserve the non-garbage collected style of programming. So, C# simply has fewer concepts you have to understand. Language is a funny thing: It's a matter of taste. Language is almost a religious thing, and it's a lifestyle choice for programmers. I mean, we realize that we can't walk out and say, "Here's a platform where you have one language base." Even if you could do everything in that platform with one language, some people may not like its syntax; they might like curly braces instead or some other block delimiter. That's what they're familiar with. That's what makes them feel at home and productive and enabled. And so our approach with C# has simply been to offer an alternative to C++ programmers who find that language too complicated and to Java programmers who miss certain features of C and C++ that were lost in the translation. We looked for ways to simplify C++ and then put the result on a multilingual platform that provides greater interoperability, and that gives you all of these component concepts, and so forth. Goodhew: One of the interesting things that came out of our developer tracking study is that over 60 percent of all developers in the professional developer market use two or more languages to build their applications. And what that tells us, especially when we ask which tools programmers use, is that there isn't going to be one object-oriented programming language which is the end all and be all language that everyone will use. As Anders said earlier, people will want certain syntaxes for what they're doing or how they feel. It's a personal choice. And that's what the whole .NET platform is about, providing developers with a choice of languages in which to implement. I think we've done a pretty good job. You can basically do the same tasks in Visual Basic, .NET, and C#. Visual Basic is still viewed as more accessible to programmers. C# has more headroom and more power than VB does. Osborn: Meaning that you can accomplish more with fewer statements in C#? Hejlsberg: Well, meaning you have more power through the provision for unsafe code. Osborn: So you can't write unsafe code in VB? Hejlsberg: No, you cannot. Goodhew: But basically, both languages can do the same thing. That's a fundamental change from where we were with Visual Studio 6. If you wanted to build a multi-threaded MTS object using Visual Studio 6.0 and you were a VB programmer, you couldn't. You'd have to use C++. Now, with the .NET framework, you can use whichever language you want. Hejlsberg: It's the thing I talked about in my general session talk: The unification of programming models, which the .NET framework offers. In the evolution of languages and frameworks, we always seemed to end up marrying a programming language to a particular API and a particular form of programming. VB was about rapid application development and forms, MFC (Microsoft Foundation Classes) was about sub-classing, and ASP was about putting stuff in web pages. In each case, your choice of programming model always dictated your choice of programming language and your choice of available APIs. It added to your workload the burden of learning new languages and APIs every time you switched frameworks. We have really tried to unify all of that. We provide one API, one supporting visual design tool, and we give you the flexibility to choose whichever language works for you. Osborn: I'm wondering what this does to the use of scripting languages such as VBScript and JScript? Hejlsberg: One of the wonderful things the .NET framework has done for scripting languages is to make them compiled. Look at ASP+. Now, you're actually running real compiled code in your pages; it's not late-bound, dispatch look-ups where you don't see a runtime error until the user hits the page. ASP+ developers can use the full power of Visual Basic .NET instead of VBScript. And for the first time, they have the ability to use Perl, Python, and other popular languages if they so choose. Petrusha: Server-side JavaScript is now compiled? Hejlsberg: Yes, that's right. Goodhew: The .NET framework allows scripting languages to be used as full-featured languages because they now have access to a true programming framework and to the same base-class APIs. You should look at what the guys who are doing the JScript implementation have accomplished. [Editors Note: JScript is the Microsoft implementation of the ECMA 262 language specification (ECMAScript Edition 3). With only a few minor exceptions (to maintain backward compatibility), JScript is a full implementation of the ECMA standard.] So the .NET platform provides a common language framework, which is a huge benefit to script writers.... ...more at url above... << end excerpt here is an article on the c# language: http://msdn.microsoft.com/msdnmag/issues/0900/csharp/csharp.asp Rishi ------=_NextPart_000_00CA_01C01ABA.7C4C7A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> <META content="MSHTML 5.00.2614.3500" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT face=Arial size=2>I'm not a microsoft fan at all, but there .net stuff is the most interesting thing i have ever seen this company do. Their c# language is actually pretty good. The thing that is really interesting to me about this .net stuff is that it is programming language independent. You can use C++, javascript, visual basic, C# and, according to the articles, any programming language you are comfortable with. It allows you to mix and match different languages. Anyway, I was wondering if Rebol could work with this .net stuff. I rememeber it being mentioned that rebol cannot be compiled, but microsoft has apparently figured out some way to compile all interepreted or non-interpreted languages to this "IL" code. </FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=Arial size=2> <DIV><FONT face=Arial size=2>So does this mean it is possible to compile rebol? Will rebol/command for windows work with this .net infrastructure. What is also interesting to me is that this .net stuff is supposidly portable to other platforms.</FONT></DIV> <DIV></FONT>&nbsp;</DIV></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=Arial size=2>here is an interview with architech of .net platform where he discusses things like programming language independence:</FONT></DIV> <DIV><FONT face=Arial size=2><A href="http://windows.oreilly.com/news/hejlsberg_0800.html">http://windows.oreilly.com/news/hejlsberg_0800.html</A></FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=Arial size=2>here is an interesting excerpt from that interview (click on url above to read full interview):</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=Arial size=2>>>begin excerpt</FONT></DIV> <DIV><FONT face=Arial size=2> <DT><B>Osborn</B>: <DD>Another area of confusion, I think, is understanding where C# stops and the common runtime begins. What's the innovation in the C# language itself versus what it gets from the common runtime library? <P></P> <DT><B>Hejlsberg</B>: <DD>Well, I think some of this confusion comes from the fact that when people talk about Java, they don't really know which is the language and which is the runtime. Some of this confusion arises when people talk about Java. Which is the language and which is the runtime? What do people mean when they say Java? Do they mean Java, the language, Java, the syntax, or do they mean Java, the platform? People lump these different aspects together. We've taken an approach that says we want to be a multilingual platform. We're going to build a platform that actually allows you to implement multiple programming languages and also have them share a common set of APIs (Application Programming Interfaces). Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did. We're not saying, "Now that there's only one language, there shall be no further innovations in this race." We're saying that our industry advances by its flexibility. How did Java come about? It came about because there were programming languages before it and there will be programming languages after it. We want to build a platform where your preference for one language over another doesn't negate the whole value proposition. We want to create a platform where there can be innovation. Who's helping COBOL programmers today? Who's taking them to the Web? Only on the .NET platform can you embed Fujitsu COBOL in an ASP page. I mean it's truly revolutionary. <P></P> <DT><B>Osborn</B>: <DD>Given the availability of multiple languages for the .NET platform, why would you choose C# over Visual Basic, C++, or even COBOL? What is it that makes C# so compelling? <P></P> <DT><B>Hejlsberg</B>: <DD>First of all, with C# we were able to start with a clean sheet of paper, so to speak. We did not have any backward compatibility requirements, and that certainly made things simpler. And not just from an implementation standpoint, but also from a usage standpoint. For example, we only have one kind of class in C#, and it is always garbage-collected. Managed C++, on the other hand, has two because it has to preserve the non-garbage collected style of programming. So, C# simply has fewer concepts you have to understand. <P>Language is a funny thing: It's a matter of taste. Language is almost a religious thing, and it's a lifestyle choice for programmers. I mean, we realize that we can't walk out and say, "Here's a platform where you have one language base." Even if you could do everything in that platform with one language, some people may not like its syntax; they might like curly braces instead or some other block delimiter. That's what they're familiar with. That's what makes them feel at home and productive and enabled. And so our approach with C# has simply been to offer an alternative to C++ programmers who find that language too complicated and to Java programmers who miss certain features of C and C++ that were lost in the translation. We looked for ways to simplify C++ and then put the result on a multilingual platform that provides greater interoperability, and that gives you all of these component concepts, and so forth. <P></P> <DT><B>Goodhew</B>: <DD>One of the interesting things that came out of our developer tracking study is that over 60 percent of all developers in the professional developer market use two or more languages to build their applications. And what that tells us, especially when we ask which tools programmers use, is that there isn't going to be one object-oriented programming language which is the end all and be all language that everyone will use. As Anders said earlier, people will want certain syntaxes for what they're doing or how they feel. It's a personal choice. And that's what the whole .NET platform is about, providing developers with a choice of languages in which to implement. I think we've done a pretty good job. You can basically do the same tasks in Visual Basic, .NET, and C#. Visual Basic is still viewed as more accessible to programmers. C# has more headroom and more power than VB does. <P></P> <DT><B>Osborn</B>: <DD>Meaning that you can accomplish more with fewer statements in C#? <P></P> <DT><B>Hejlsberg</B>: <DD>Well, meaning you have more power through the provision for unsafe code. <P></P> <DT><B>Osborn</B>: <DD>So you can't write unsafe code in VB? <P></P> <DT><B>Hejlsberg</B>: <DD>No, you cannot. <P></P> <DT><B>Goodhew</B>: <DD>But basically, both languages can do the s