Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Virtual Fireside Chat With Miguel De Icaza

By Carnage4Life in Technology
Sun Sep 23, 2001 at 06:29:41 PM EST
Tags: Interviews (all tags)
Interviews

What follows is my interview with Miguel de Icaza, the founder of GNOME and Ximian, where he talks about UNIX components, Bonobo, Mono and .NET.


Dare Obasanjo: You have recently been in the press due to Ximian's announcement that it shall create an Open Source implementation of Microsoft's .NET development platform. Before the recent furor you've been notable for the work you've done with GNOME and Bonobo. Can you give a brief overview of your involvement in Free Software from your earlier projects up to Mono?

Miguel de Icaza: I have been working for the past four years on the GNOME project in various areas: organization of it, libraries and applications. Before that I used to work on the Linux kernel, I worked for a long time on the SPARC port, then on the software raid and some on the Linux/SGI effort. Before that I had written the Midnight Commander file manager.

Dare Obasanjo: In your Let's Make Unix Not Suck series you mention that UNIX development has long been hampered by a lack of code reuse. You specifically mention Brad Cox's concept of Software Integrated Circuits, where software is built primarily by combining reusable components, as a vision of how code reuse should occur. Many have countered your arguments by stating that UNIX is built on the concept of using reusable components to build programs by connecting the output of smaller programs with pipes. What are your opinions of this counter-argument?

Miguel de Icaza: Well, the paper addresses that question in detail. A `pipe' is hardly a complete component system. It is a transport mechanism that is used with some well known protocols (lines, characters, buffers) to process information. The protocol only has a flow of information.

Details are on the paper:
http://primates.ximian.com/~miguel/bongo-bong.html   [Dare -- check the section entitled "Unix Components: Small is Beautiful"]

Dare Obasanjo: Bonobo was your attempt to create a UNIX component architecture using CORBA as the underlying base. What are the reasons you have decided to focus on Mono instead?

Miguel de Icaza: The GNOME project goal was to bring missing technologies to Unix and make it competitive in the current market place for desktop applications. We also realized early on that language independence was important, and that is why GNOME APIs were coded using a standard that allowed the APIs to be easily wrapped for other languages. Our APIs are available to most programming languages on Unix (Perl, Python, Scheme, C++, Objective-C, Ada).

Later on we decided to use better methods for encapsulating our APIs, and we started to use CORBA to define interfaces to components. We complemented it with policy and a set of standard GNOME interfaces for easily creating reusable, language independent components, controls and compound documents. This technology is known as Bonobo. Interfaces to Bonobo exist for C, Perl, Python, and Java.

CORBA is good when you define coarse interfaces, and most Bonobo interfaces are coarse. The only problem is that Bonobo/CORBA interfaces are not good for small interfaces. For example, an XML parsing Bonobo/CORBA component would be inefficient compared to a C API.

I also wrote at some point:

My interest in .NET comes from the attempts that we have made before in the GNOME project to achieve some of the things .NET does:

  • APIs that are exposed to multiple languages.
  • Cross-language integration.
  • Contract/interface based programming.

And on top of things, I always loved various things about Java. I just did not love the Java combo that you were supposed to give or take.

APIs exposed to many languages we tried by having a common object base (GtkObject) and then following an API contract and a format that would allow others to wrap the APIs easily for their programming language. We even have a Scheme-based definition of the API that is used to generate wrappers on the fly. This solution is suboptimal for many reasons.

The Cross-language integration we have been doing with CORBA, sort of like COM, but with an imposed marshalling penalty. It works pretty well for non inProc components. But for inProc components the story is pretty bad: since there was no CORBA ABI that we could use, the result is so horrible, that I have no words to describe it.

On top of this problem, we have a proliferation of libraries. Most of them follow our coding conventions pretty accurately. Every once in a while they either wont or we would adopt a library written by someone else. This had lead to a mix of libraries that although powerful in result implement multiple programming models, sometimes different allocation and ownership policies and after a while you are dealing with 5 different kind of "ref/unref" behaviours (CORBA local references, CORBA object references on Unknown objects, reference count on object wrappers) and this was turning into a gigantic mess.

We have of course been trying to fix all these issues, and things are looking better (the GNOME 2.x platform does solve many of these issues, but still).

.NET seemed to me like an upgrade for Win32 developers: they had the same problems we had when dealing with APIs that have been designed over many years, a great deal of inconsistency. So I want to have some of this new "fresh air" available for building my own applications.

Dare Obasanjo: Bonobo is slightly based on COM and OLE2 as can be gleaned from the fact that Bonobo interfaces are all based on the Bonobo::Unknown interface which provides two basic services: object lifetime management and object functionality-discovery and only contains three methods:

module Bonobo {
interface Unknown {
void ref ();
void unref ();
Object query_interface (in string repoid);
};
};

which is very similar to Microsoft's COM IUnknown interface which has the following methods

HRESULT QueryInterface(REFIID riid, void **ppvObject);
ULONG AddRef();
ULONG Release();

Does the fact that .NET seems to spell the impending death of COM mean that Mono will spell the end of of Bonobo? Similarly considering that .NET plans to have semi-transparent COM/.NET interoperability, is there a similar plan for Mono and Bonobo?

Miguel de Icaza: Definetly. Mono will have to interoperate with a number of systems out there including Bonobo on GNOME.

Dare Obasanjo: A number of parties have claimed that Microsoft's NET platform is a poor clone of the Java™ platform. If this is the case why hasn't Ximian decided to clone or use the Java platform instead of cloning Microsoft's .NET platform?

Miguel de Icaza: We were interested in the CLR because it solves a problem that we face every day. The Java VM did not solve this problem.

Dare Obasanjo: On the Mono Rationale page it is pointed out that Microsoft's .NET strategy encompasses many efforts including

  • The .NET development platform, a new platform for writing software.
  • Web services.
  • Microsoft Server Applications.
  • New tools that use the new development platform.
  • Hailstorm, the Passport centralized single-signon system that is being integrated into Windows XP.
and you point out that Mono is merely an implementation of of the .NET development platform. Is there any plan by Ximian to implement other parts of the .NET strategy?

Miguel de Icaza: Not at this point. We have a commitment to develop currently:

  • A CLI runtime with a JITer for x86 CPUs.
  • A C# compiler.
  • A class library

All of the above with the help of external contributors. You have to understand that this is a big undertaking and that without the various people who have donated their time, expertise and code to the project we would not even have a chance of delivering a complete product any time soon.

We are doing this for selfish reasons: we want a better way of developing Linux and Unix applications ourselves and we see the CLI as such a thing.

That being said, Ximian being in the services and support business would not mind extending its effort towards making the Mono project tackle other things like porting to new platforms, or improving the JIT engine, or focusing on a particular area of Mono.

But other than this, we do not have plans at this point to go beyond the three basic announcements that we have made.

Dare Obasanjo: There are a number of other projects that are implementing other parts of .NET on Free platforms that seem to be have friction with the Mono project. Section 7.2 of Portable.NET's FAQ seems to indicate they have had conflict with the Mono project as does the banning of Martin Coxall from the dotGNU mailing list. What are your thoughts on this?

Miguel de Icaza: I did not pay attention to the actual details of the banning of Martin from the DotGNU mailing lists. Usenet and Internet mailing lists are a culture of their own and I think this is just another instance of what usually happens on the net. It is definitely sad.

The focus of Mono and .NET is slightly different: we are writing as much as we can in a high level language like C#, and writing reusable pieces of software out of it. Portable.NET is being written in C.

Dare Obasanjo: There have been conflicting reports about Ximian's relationship with Microsoft. On one hand there are reports that seem to indicate that there may be licensing problems between the license that will govern .NET and the GPL. On the other hand there is an indication that some within Microsoft are enthusiastic about Mono. So exactly what is Ximian's current relationship is with Microsoft and what will be done to ensure that Mono does not violate Microsoft's licenses on .NET if they turn out to be restrictive?

Miguel de Icaza: Well, for one we are writing everything from scratch.

We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques.

Dare Obasanjo: It has been pointed out that Sun retracted Java™ from standards processes at least twice, will the Mono project continue if .NET stops being an open standard for any reason?

Miguel de Icaza: The upgrade on our development platform has a value independently of whether it is a standard or not. The fact that Microsoft has submitted its specifications to a standards body has helped, since people who know about these problems have looked at the problem and can pin point problems for interoperability.

Dare Obasanjo: Similarly what happens if Dan Kusnetzky's prediction comes true and Microsoft changes the .NET APIs in the future? Will the Mono project play catchup or will it become an incompatible implementation of .NET on UNIX platforms?

Miguel de Icaza: Microsoft is remarkably good at keeping their APIs backwards compatible (and this is one of the reasons I think they have had so much success as a platform vendor). So I think that this would not be a problem.

Now, even if this was a problem, it is always possible to have multiple implementations of the same APIs and use the correct one by choosing at runtime the proper "assembly". Assemblies are a new way of dealing with software bundles and the files that are part of an assembly can be cryptographically checksummed and their APIs programmatically tested for compatibility.   [Dare -- Description of Assemblies from MSDN glossary]

So even if they deviate from the initial release, it would be possible to provide assemblies that are backwards compatible (we can both do that: Microsoft and ourselves)

Dare Obasanjo: Looking at the Mono class status page I noticed that a large number of .NET class libraries are not being implemented in Mono such as WinForms, ADO.NET, Web Services, XML schemas, reflection and a number of others. This means that it is very likely that when Mono and .NET are finally released apps written for .NET will not be portable to Mono. Is there any plan to rectify this in the future or is creating a portable .NET platform not a goal of the Mono project? Similarly what are the short and long term goals of the Mono project?

Miguel de Icaza: The status web page reflects the classes that people have "requested" to work on. The status web page is just a way of saying `Hey, I am working on this class as of this date' to avoid code duplication. If someone registers their interest in working on something and they do not do something after some period of time, then we can reclaim the class.

We are on the very early stages of the project, so you do see more work going on the foundational classes than on the end user classes.

I was not even expecting so many great and talented programmers to contribute so early in the project. My original prediction is that we would spend the first three months hacking on our own in public with no external contributions, but I have been proved wrong.

You have to realize that the goals of the Mono project are not only the goals of Ximian. Ximian has a set of goals, but every contributor to the project has his own goals: some people want to learn, some people like working on C#, some people want full .NET compatibility on Linux, some people want language independence, some people like to optimize code, some people like low level programming and some people want to compete with Microsoft, some people like the way .NET services work.

So the direction of the project is steered by those that contribute to it. Many people are very interested in having a compatible .NET implementation for non-Windows platforms, and they are contributing towards filling those gaps.

Dare Obasanjo: How does Ximian plan to pay for the costs of developing Mono especially after the failure of a number of recent venture funded, Free Software-based companies like Indrema, Eazel and Great Bridge and the fact that a sizable percentage of the remaining Free Software based companies are on the ropes? Specifically how does Ximian plan to make money at Free Software in general and Mono in particular?

Miguel de Icaza:Ximian provides support and services. We announced a few of our services recently, and more products and services have been on the pipeline for quite a while and would be announced during the next six months.

Those we announced recently are:

  • Red Carpet Express: a subscription service for those who want a reliable high speed access to the Red Carpet servers.
  • Red Carpet Corporate Connect: We modified our Red Carpet updater technology to help people manage networks of Linux workstations easily and to deploy and maintain custom software packages.
  • Support and services for the GNOME desktop and Evolution: Our latest boxed products are our way of selling support services for the various products we ship.
We have also been providing professional services and support for people integrating free software based solutions.

The particular case of Mono is interesting. We are working on Mono to reduce our development costs. A very nice foundation has been laid and submitted to ECMA. Now, with the help of other interested parties that also realize the power of it, we are developing the Mono runtime and development tools to help us improve our productivity.

Indeed, the team working on Mono at Ximian is the same team that provided infrastructural help to the rest of the company in the past.

Dare Obasanjo: It is probably little known in some corners that you once interviewed with Microsoft to work on the SPARC port of Internet Explorer. Considering the impact you have had on the Free Software community since then, have you ever wondered what your life would have been like if you had become a Microsoft employee?

Miguel de Icaza: I have not given it a lot of thought, no. But I did ask everyone I interviewed at Microsoft to open source Internet Explorer, way before Netscape Communicator was Open Sourced ;-)

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o GNOME
o Ximian
o Bonobo
o Mono
o .NET
o Microsoft' s .NET development platform
o Let's Make Unix Not Suck
o Brad Cox's
o http://primates.ximian.com/~miguel/bongo-bong.html
o COM/.NET interoperability
o Mono Rationale page
o Portable.N ET's FAQ
o banning of Martin Coxall from the dotGNU mailing list
o reports that seem to indicate that there may be licensing problems
o there is an indication that some within Microsoft are enthusiastic
o Dan Kusnetzky's prediction
o Descriptio n of Assemblies from MSDN glossary
o Mono class status page
o Indrema
o Eazel
o Great Bridge
o interviewed with Microsoft
o Also by Carnage4Life


Display: Sort:
Virtual Fireside Chat With Miguel De Icaza | 30 comments (21 topical, 9 editorial, 0 hidden)
What C# is (4.00 / 1) (#10)
by ucblockhead on Sun Sep 23, 2001 at 08:12:44 PM EST

I've been taking a serious look at C# for the last week or so on the theory that having it on the ol' resume can't hurt, and I've come to the conclusion that it is neither a "Java killer" nor a "C++ killer". What it really is is a "Visual BASIC killer", and that's a good thing.

The Visual Studio.NET version of C# includes all of the same form editing and drag and drop tools that up until now only came with VB. That's a very good thing, because for whatever faults it ends up having, C# is a real OO language, as opposed to the vileness that is VB. This cannot be accidental, and I strongly suspect you'll see Microsoft pushing away from VB in the future.

All the more reason to port C# to Linux, as this means that there will be hordes of C# programmers coming down the pikes in the next few years.

('Course I'm a bit dubious about .NET in general, so there ya go...)
-----------------------
This is k5. We're all tools - duxup

I disagree with some of your points. (5.00 / 1) (#11)
by Carnage4Life on Sun Sep 23, 2001 at 08:32:48 PM EST

I've been taking a serious look at C# for the last week or so on the theory that having it on the ol' resume can't hurt, and I've come to the conclusion that it is neither a "Java killer" nor a "C++ killer". What it really is is a "Visual BASIC killer", and that's a good thing.

I used C# all summer while working at MSFT and from all impressions it is close enough to Java to attempt to be a Java killer. In fact the similarities between Java and C# are enough that my next major article will be a comparison between both languages with the goal of a showing the strengths and weaknesses of both languages.

The Visual Studio.NET version of C# includes all of the same form editing and drag and drop tools that up until now only came with VB. That's a very good thing, because for whatever faults it ends up having, C# is a real OO language, as opposed to the vileness that is VB. This cannot be accidental, and I strongly suspect you'll see Microsoft pushing away from VB in the future.

The fact that Visual Studio.NET has drag and drop tools for C# has less to do with the language and more to do with the IDE. After all Java has similar IDEs from JBuilder to NetBeans.

Also VB isn't going anywhere soon especially since it has been rewritten from scratch to make use of the .NET runtime and is in effect C# with a few less features (no operator overloading for one) and friendlier syntax.

All the more reason to port C# to Linux, as this means that there will be hordes of C# programmers coming down the pikes in the next few years.

Here I agree, primarily because I think Mono can do great things for *nix development if given enough time and resources.

[ Parent ]
C# vs. Java (5.00 / 1) (#12)
by ucblockhead on Sun Sep 23, 2001 at 09:08:22 PM EST

The important thing in this battle is that almost no one uses Microsoft tools for Java right now. People who use Java now have already chosen against Microsoft. These means that in the battle between the two, it is mostly a matter of merit, and I don't see the differences as large enough to be compelling. Perhaps some people will use C# in that niche on new projects, but I can't see existing Java shops changing.

(Personally, I find VB's syntax ghastly, but that's just my C++ bias.)

As a C++ guy, I'd now choose C# instead of VB for the sort of app VB is good for. That was not the case with Java, mostly because of compatibility issues in J++. I would dispute that it is "just the IDE" as C++ still lacks a lot of that stuff.

But obviously that is likely mostly just my personal biases. I have to admit I'd not cry at Visual BASIC's funeral.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Are you sure . . . ? (5.00 / 1) (#13)
by Sunir on Sun Sep 23, 2001 at 10:00:50 PM EST

almost no one uses Microsoft tools for Java right now

Anecdotally that seems false. Even if a small percentage of Java programmers use VJ++, a large number of developers still prefer VJ++ to anything else. We use it where I work simply because it works, it doesn't take all your RAM, it's fast, and it's easy to work in. I know many other people who think the same way.

Then again, we haven't chosen against Microsoft. Mostly because we don't care. Being customer-centric means not "chosing against" anything, or worrying about stupid, overhyped "battles."

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

No... (none / 0) (#14)
by ucblockhead on Sun Sep 23, 2001 at 10:16:59 PM EST

No, I'm not really sure. I'm a C++ guy and what I know from Java is what other people I know tell me.

Though I'd personally stay away from J++. Not because it is Microsoft, after all, I spend eight hours a day in the Visual Studio IDE. Because it is nonstandard, and I loathe nonstandard stuff.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Java standard? (3.00 / 1) (#18)
by Sunir on Mon Sep 24, 2001 at 01:30:32 AM EST

There is no Java standard. There is the JDK and there is not the JDK. That doesn't make for a standard, but a product. I used to work at OTI/Ottawa; I heard the vast amount of griping about how bogus the Java Compliance Tests were. I witnessed how bogus they were first hand.

I feel rather safe in my conviction to state that there is no Java standard, just like there is no Perl standard. There is Java, there is Perl, and there are ports and clones thereof.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

No Java standard??? (5.00 / 2) (#20)
by Carnage4Life on Mon Sep 24, 2001 at 02:00:36 AM EST

If you mean there isn't a Java standard as in something ratified by a standards body then I agree with you.

On the other hand if you are simply claiming that there is no conclusive specification for the Java language and platform (i.e. like there is none for Perl) then I have to point you to the The Java™ Virtual Machine Specification and the Java™ Language Specification. Even if Java suddenly became ratified by a standards body, all they'd do is adopt the current specifications so I don't think your comparison to Perl is valid at all.

[ Parent ]
JDK doesn't comply with own specifications (5.00 / 1) (#29)
by Sunir on Mon Sep 24, 2001 at 03:10:55 PM EST

As I discovered when working on VisualAge at OTI, the JDK isn't Java compliant. However, it is the de facto standard. Since Java is really a product line, it doesn't make much sense to describe it terms of a standard for that implies other competing implementations that could be in theory correct. In reality, there is only one correct version, which is the JDK by definition.

On the other tact, Perl has the Camel book and various other official (well, semi-official) texts that define it. This is similar to Java except the Perl documentation isn't as pretentious.

While I do agree that perhaps Perl isn't a perfect analogy, as one could claim that the JDK wasn't standards compliant and then seek to implement a Java compliant with published standards (ignoring licensing issues), I don't think that's really meaningful until there are multiple vendors legally capable of competing at an equal level. Until then, I feel it is more consistent to consider Java a Sun product that has been cloned by other vendors, much like WINE is a clone of Windows.

Indeed, you might consider Windows standardized if you choose MSDN as the specification, even though Win32 doesn't match the MSDN documentation perfectly. But I think this it is dishonest to weaken the definition of "standard" to include any form of technical documentation for any type of technical product.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Don't short-change your customers. (none / 0) (#15)
by regeya on Sun Sep 23, 2001 at 11:32:36 PM EST

Being customer-centric means not "chosing against" anything, or worrying about stupid, overhyped "battles."

Ehrm, which stupid, overhyped battle are you referring to?

If you're referring to the "Linux is Going Down" battle, I can tell you who's on the offensive. And it ain't anti-MS types.

Then again, I'm not working in a company that helps force MS solutions on customers.

[ yokelpunk | kuro5hin diary ]
[ Parent ]

Persecution Complex (none / 0) (#16)
by Carnage4Life on Mon Sep 24, 2001 at 12:20:49 AM EST

Ehrm, which stupid, overhyped battle are you referring to?

If you're referring to the "Linux is Going Down" battle, I can tell you who's on the offensive. And it ain't anti-MS types.


Considering that the discussion is about Java versus C# & J++ I fail to see what Linux has to do with anything.

Then again, I'm not working in a company that helps force MS solutions on customers.

This is such a pathetic cheap shot that it is almost beneath you. PROFESSIONAL software developers choose the best tool that meets the customers needs instead of foisting their pet operating system and programming languages independently of what's best for the customer.

[ Parent ]
Re:Persecution Complex (none / 0) (#17)
by truth versus death on Mon Sep 24, 2001 at 01:11:19 AM EST

How do you choose what's best for the customer?

"any erection implies consent"-fae
[ Trim your Bush ]
[ Parent ]
It's my job (5.00 / 2) (#19)
by Sunir on Mon Sep 24, 2001 at 01:36:37 AM EST

It's my job to make responsible technical decisions. That does not include "Windows sux0rs" or "Linux sux0rs." A responsible developer works with the client to find a solution to fit her needs. If the client feels that we are not representing her needs, then she is free not to continue the contract.

On the other hand, no matter where I end up, I usually have to work through reams of middle management to find out what the customer wants. This is not good, and highly irresponsible in my opinion, but it seems to be the industry "best practice."

Note, none of this particularly affects my opinion of Java, which is a pure Hatred. However, that doesn't affect me professionally when I am tasked with solving someone else's problems.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Bah (none / 0) (#31)
by regeya on Mon Sep 24, 2001 at 06:43:02 PM EST

Ehrm, which stupid, overhyped battle are you referring to? If you're referring to the "Linux is Going Down" battle, I can tell you who's on the offensive. And it ain't anti-MS types. Considering that the discussion is about Java versus C# & J++ I fail to see what Linux has to do with anything.

Well, since you're not Sunir, I have no idea why you're commenting. I was wondering if that was the stupid, overhyped battle referred to. Do you know? No? Buzz off, then.

This is such a pathetic cheap shot that it is almost beneath you. PROFESSIONAL software developers choose the best tool that meets the customers needs instead of foisting their pet operating system and programming languages independently of what's best for the customer.

I'm a customer too. Hey, I want QuarkXPress on the Linux platform. I lobby. Heck, Linux Journal lobbies them. They say, no demand. None? That's funny; I could have sworn I asked for it, and I could have sworn others did, too. So, I have an operating system (Windows, or, ideally MacOS) foisted upon me.

And let me repeat: I'm a customer too. Despite the fact that I make "unreasonable" demands.

And before you start pointing out "technical deficiencies" in Linux...no, scratch that, I know someone will, it'll lead to the old circular argument, and I'll just get pissed off. SO here goes. Go ahead and argue. I won't respond. It doesn't mean you won or that I agree. It just means I'm finally tired of the old, stupid debate made by people who Just Don't Get It(TM). :-P

[ yokelpunk | kuro5hin diary ]
[ Parent ]

C++Builder (none / 0) (#25)
by shaum on Mon Sep 24, 2001 at 12:12:29 PM EST

I would dispute that it is "just the IDE" as C++ still lacks a lot of that stuff.
C++ does have a lot of that stuff, but only if you're willing to look beyond Microsoft's offerings. Borland C++Builder is basically a VB-like interface builder and component set, but with C++ as the underlying language. (The components are actually written in Object Pascal, since they are ported from Delphi.)

I personally would prefer Perl, Python, or Ruby as the underlying language, and I'm looking forward to ActiveState and theKompany.com providing solutions along those lines. I know C++, and have used it professionally in the past; but RAD-style development really calls for a dynamic "scripting" language, not a system programming language like C++.

:wq!
[ Parent ]

VB is great (4.50 / 2) (#21)
by the trinidad kid on Mon Sep 24, 2001 at 06:35:42 AM EST

VB is a fantastic language if you use it for to do things that it is good at.

The combination of Microsoft Office and VB is truly fantastic. Using OLE Automation to make Microsoft Word a string manipulation class that you can implement in VB is stupendous. There is no better way to produce and manipulate documents than that - despite the minor inconveniences that Word poses to someone who is trained as a typesetter like me (particaluarly my bugbear of fine-grained control of line spacing).

The sort of component embedding that you can do with Office as well knocks any free Office Suites into a large success of decidedly cocked hats - and hats off to Miguel becuase he alone in the free software world seems to recognise that.

If you work in any office environment and have any sort of background in flowing information on paper then Linux is just nowhere near Microsoft.

If your philosophy is use the right tool for the right job, then don't diss VB just cos your range of jobs doesn't line up to its strengths.

[ Parent ]
C# (none / 0) (#23)
by ucblockhead on Mon Sep 24, 2001 at 10:58:10 AM EST

What attracts me to C# is that it looks like it has most of the advantages of VB without any of the disadvantages.

That's why I'd personally choose C# over VB for the sort of thing I'd have chosen VB for in the past. I.e. stuff that uses a roughly standard UI, where performance isn't a concern, but that needs to be banged out fast.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

VB (none / 0) (#24)
by btlzu2 on Mon Sep 24, 2001 at 11:01:53 AM EST

After extensively using Visual Basic in the MS Office environment, then being directed into a text only Unix environment, I can whole-heartedly say that VB is a steaming heap of s**t. I'll take Perl/troff anyday over the machinations required in VB, not to mention the inherent security problems with VB in Office.

Can anyone say "Love virus"? Some people, you know, actually have compared the functionality of VB with other tools available and have made educated decisions to not use VB.
"This machine will not communicate the thoughts and the strain I am under." --Radiohead/Street Spirit (Fade Out)
[ Parent ]
Wondering about Java (none / 0) (#22)
by slaytanic killer on Mon Sep 24, 2001 at 07:50:16 AM EST

If Java were ported over to .NET, Java's cross-platform ability would still exist, at the cost of being incompatible with old bytecodes. I wonder if Sun will consider that the sticking point to not port Java over unless they had to.

If not Java, then will there be another project pushing hard for a large crossplatform .NET API? Is being crossplatform a false economy, since everything exists for the lowest common denominator? I still would like the ability to code crossplatform GUIs that are useful and have different look & feels, which Java does but neither Microsoft nor Ximian apparently will.

How would Java still be cross platform? (none / 0) (#26)
by Carnage4Life on Mon Sep 24, 2001 at 01:32:10 PM EST

If Java were ported over to .NET, Java's cross-platform ability would still exist, at the cost of being incompatible with old bytecodes. I wonder if Sun will consider that the sticking point to not port Java over unless they had to.

I'm confused as to what you mean by this. Java is currently cross platform because JVMs exist for the major OSes so a Java class file from Windows can run on Linux or Solaris with little or no problems. Porting Java to .NET would primarily require writing a compiler that converted Java source code to .NET Instruction Language.

Once this is done I fail to see how this retains the cross platform nature of Java since unless you are referring to some time in the future where a .NET platform exists on the major OSes from Windows to Linux and other Unices.

[ Parent ]
That is what I mean (none / 0) (#27)
by slaytanic killer on Mon Sep 24, 2001 at 02:35:02 PM EST

The following was from an interview with Hejlsberg:
But people in the industry have been reading too much into our use of the words COM and DLL. They conclude that the .NET platform is for Windows platforms only, and that's absolutely incorrect.
If Ximian makes a clean enough .NET implementation, which supports the BSDs as well as Linux, then it is reasonable to call .NET "cross-platform." When enough platforms are supported, an all-encompassing API can be built, and Java could provide it.

So it takes two things:

  1. Port of Java to .NET
  2. Port of .NET to other OS's
I thought that the whole point of Ximian's involvement was to take care of #2. #1 was the hypothetical situation that interested me. It might take some native code for GUIs and sockets, but I see nothing more complicated. Maybe J2EE conformance will be a pain.

Is there an error in that logic? I had been sitting, thinking of ways that .NET would not kill the JVM ('cause I know I'd probably switch if implementations become good), and basically it comes down to how much more crossplatform the JVM is. If .NET was also crossplatform, then that would knock down the JVM's technical advantages.

Perhaps there is something you know about Microsoft's intentions that would keep this from happening? I don't see Java and C# being mutually exclusive, just JVM and .NET IL. The J2EE standard would have to be significantly reworked.

[ Parent ]

Sun's Intellectual Property (5.00 / 1) (#28)
by Carnage4Life on Mon Sep 24, 2001 at 03:10:18 PM EST

Is there an error in that logic? I had been sitting, thinking of ways that .NET would not kill the JVM ('cause I know I'd probably switch if implementations become good), and basically it comes down to how much more crossplatform the JVM is. If .NET was also crossplatform, then that would knock down the JVM's technical advantages.

Perhaps there is something you know about Microsoft's intentions that would keep this from happening? I don't see Java and C# being mutually exclusive, just JVM and .NET IL. The J2EE standard would have to be significantly reworked.


I can't see any reason why Microsoft would be against a Java port to .NET or Mono but can see a lot of reasons why Sun wouldn't like it. Since Java isn't an open standard and also contains lots of Sun patents and trademarks I'm sure they could make life tough for an incompatible .NET port if they wanted to.

[ Parent ]
Virtual Fireside Chat With Miguel De Icaza | 30 comments (21 topical, 9 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!