GNOME Platform Stormclouds

Posted Mar 25, 2004 3:32 UTC (Thu) by kyle_hayes (guest, #7904) [Link]

Posted Mar 25, 2004 3:53 UTC (Thu) by jmalcolm (guest, #8876) [Link]

I realize that this still means using the CLR as a base but it seems to be more of a middle ground than having to choose or reject Java wholesale. It also seems like this would offer the largest possible library set.

Does anybody that better understands the issues have a comment?

Posted Mar 25, 2004 7:38 UTC (Thu) by remijnj (guest, #5838) [Link]

$ java -version
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

Posted Mar 25, 2004 10:14 UTC (Thu) by dale77 (guest, #1490) [Link]

Dale

Posted Mar 25, 2004 12:51 UTC (Thu) by dcoutts (guest, #5387) [Link]

That introduces the issue of only one-way reusability; apps in any language can use the base libs but an app in one language cannot reuse an app/component written in another language. For that we use a bonobo/DCOP/DBUS style component protocol.

That still leaves the problem that reusable libraries would not be able to be written in a high level language; that is libs with a more fine grained interface than high level 'components' (which only really work well if they have coarse interfaces). However that would probably be an acceptable tradeoff for the next few years, since the pressure for high level languages is really due to the pain of writing complex *apps* in C.

Besides, integrating different languages at a finegrained level is still an unsolved problem, the CLR doesn't even do it except for C#-like languages due to the semantic mismatch between different languages. It'll be interesting to see if parrot can do it ok for Python/Perl/Ruby.

Posted Mar 25, 2004 14:41 UTC (Thu) by rwmj (subscriber, #5474) [Link]

I find it interesting that by developing Mono the free software community is actively and quickly embracing and extending a Microsoft standard. Way to go!

Nevertheless, my own personal choice for a language would be Objective CAML. It's as fast as C, and uses type inference, so you get static typing without all the hassle of having to defining every variable's type (as in Java, C, etc. ...). And of course it has garbage collection, LISP macros, data matching and all the features you'd want in a modern language (and won't find in Java or C#).

Rich.

Posted Mar 25, 2004 16:20 UTC (Thu) by jeremiah (subscriber, #1221) [Link]

It's got to be nerve racking for them.

Posted Mar 25, 2004 16:38 UTC (Thu) by mly (guest, #2171) [Link]

It obviously depends on what kind of code I'm writing, and in what stage of development I'm in, but I think that I generally have an edit - test cycle in Python which is much shorter than my edit - compile cycle in C, and much, much shorter than the edit - compile - link - test cycle in C. The reason for this is that you typically have to write five or ten times more in C than in Python to achieve the same result. Testing as often in C as I do in Python would be impossible, particularly in a large system: I've been involved in C++ projects where an application took an hour to build... In Python, this is not an issue at all.

In general I think Guido van Rossum has been very successful in creating a language which is helpful to the programmer in a positive way, making it easy to do things right, rather than trying to make it hard to do bad things. In C, you must often do potentially dangerous things such as playing with pointers and type casting, because the safer way of working is too limited. There are also a number of well known gotchas in C syntax that have been solved in Python, e.g. "if x = 0" is a SyntaxError in Python.

You may be wondering why languages such as Python, Perl or Ruby aren't in consideration here. Havoc's paper doesn't do much to explain why languages such as these won't be used for writing system components, because the audience that he wrote it for probably take that as a given.

Might this possibly be a mistake?

Dave Camp's one-liner in this blog post probably explains the thoughs of most developers on this issue: I have a soft spot in my heart for Python (although I have a softer spot for static type checking).

I think this is mainly a matter of getting used to another way of programming. This might be a hurdle in itself, but it's maybe more a learning issue than a technical issue. Besides, there are tools such as PyChecker and PyLint that can take the role of the compiler. It's my impression after many years of using both C and Python that Python programs typically contain much fewer bugs than C programs, and that it's far easier to find and correct them.

Automated testing can address some of these issues, but a certain type of C programmer might have trouble sleeping at night after shipping a large Python application, with the expectation of receiving bug reports containing NameErrors.

I think most programmers sleep even worse when they have shipped C applications, with the expectation of receiving bug reports containing core dumps--and maybe even worse: security holes due to buffer overflows etc. There aren't a lot of reliable studies on the subject, but I've never seen any study suggesting that C programs contain less bugs than Python programs. I've seen some study that suggest the opposite. The problem with Python is not that Python programs are so buggy. Not at all.

Python certainly doesn't fit in all situations, but for a system like GNOME, I think the reliance on an external interpreter and the inability to build native machine code executables seem like small problems. Making source code or easilly decompiled byte code available to end users doesn't seem to be a problem in GNOME either. Considering the wide use of Python in the Linux community, and how easy it is to learn, I don't think that lack of skilled python programmers or lack of "support" are issues either.

The only non-religious problem I see with adapting something like Python for GNOME is performance. If Moore's law and novelties such as pyrex and psyco doesn't fix this, Python has always been able to cooperate nicely with C++ and C... That should also be helpful in a transition period. But I guess it's still possible that performance issues in Python would be a real problem for GNOME. I appreciate that performance is a big issue in GNOME.

Of course, if we'd switch from C to Python to get rid of C's problems with memory management etc, and end up writing parts in C anyway for performance reasons, you might feel that little is gained, but typically, the bottlenecks in programs are small. Instead of 10000 lines of C code for a particular program, you might end up with 2000 lines of Python and 500 lines of C. It's much easier to maintain 2500 lines than 10000, and all the risks of C, with memory leaks etc are roughly reduced by 95% if there is 95% less C code.

Perhaps a two language solution with Python and C is the easiest way to go forward from where GNOME stands today?

Maybe Java has improved a lot since I last looked at it, but it certainly used to be a major resource hog, and Java applications that I run regularly in Windows, such as IBM's DB2 ControlCenter are so slow and memory hungry that they are almost useless.

My experience is that Python programs are significantly shorter than Java programs, and much shorter than C programs, and at the same time clearer and easier to understand. A large part of the code that I would write myself in C, is already written by someone smarter in well tested C if I use Python. In a way, writing Python can be seen as a very clever way of reusing well written and tested C code. (After all, the classic Python implementation was started almost 15 years ago, and it's certainly not been allowed to rot.)

Somehow...I have problems envisioning something that Microsoft came up with as a solution for GNOME... I'm really ignorant on the issue, but I somehow suspect that C# for Linux might backfire in a nasty way. I'd just wait for some Microsoft C# patent to emerge as GNOME had turned into a real Windows contender. Of all aspects of Linux, it's the rise of a more polished desktop "experience" that is most likely to have an impact on Windows users. I'm sure MS would do everything in their power to stop Windows from being replaced by GNOME/Linux as the leading desktop OS, and Bill Gates have explained publically that he'll use the legal system to go after Linux if he can, and he's doing it right now by funding Caldera/SCO. Don't think it'll stop there. No, I don't think Mono will make the programmer sleep any better. :(

If you really think you need static typing and memory management, you should perhaps look at Eiffel or OCaml? Although I guess OCaml's inferred typing won't stop you from mistyping a variable name...

Posted Mar 26, 2004 7:50 UTC (Fri) by skybrian (subscriber, #365) [Link]

How could it be done? Since Java bytecodes are pretty much a subset of C# bytecodes, the
source language probably would look more like Java. But it would have to be a strictly defined
subset of both Java and C#. It would be best if there were a compiler specifically designed to
target multiple VM's and flag non-portable output, sort of a gcc for virtual machines.

Posted Mar 26, 2004 12:20 UTC (Fri) by massimiliano (subscriber, #3048) [Link]

Many of the previous comments are correct, but seem to miss one main point...

The issue here is not "let's write GNOME applications in Java/C#/ Perl/Python/Ruby". This is something that can be easily done now, with any of those languages.

The issue is "let's integrate a virtual machine in the GNOME system libraries, so that GNOME reusable components can be written in a language that is more abstract/expressive/safe/productive than C".

The issues about the type safety of languages, IMHO, should be looked at from this perspective.

In some cases it is perfectly appropriate developing an application in a language that is not statically type safe, while in other cases it is better to have a type safe language. Each application developer can pick his own choice, and be happy with it. It can be also perfectly acceptable to have different VMs supporting different languages for different applications.

On the other hand, for reusable components, the requirements are more stringent. Moreover, if you want to have true reusable components, ease of interoperability with other technologies is a must.

What Microsoft is doing internally, with .NET, is replacing COM and DCOM as a technologies for writing components with a more modern way of doing things (.NET assemblies and remoting). They will have the advantage of a very coherent system when the migration is completed (longhorn), and a very easy and incremental migration path for ISVs in the meanwhile.

If I got it correctly, it is because he was seeing this potential in the .NET standard that Miguel started the mono project; he tought that those benefits would apply to a free platform (GNU/Linux/GNOME) as well.

In my opinion, for individual applications the problem of "standardizing on one VM" is not an issue. Each application writer picks his own choice, and everything works anyway, just like we are doing now.

It is when you want to have a coherent system, and reap the benefits of a more modern platform also at the system component level, that you need to pick a choice globally to avoid fragmentation.

At this point, the only options are Parrot, Java and mono (for the sake of completeness, also portable .net, but this counts as a .NET reimplementation like mono). Everybody has his opinion on the subject... for me, Parrot is not ready, and Java is not free enough. Besides, .NET is very, very well tought out, and generally technically superior.

Posted Mar 26, 2004 16:33 UTC (Fri) by tgriggs (guest, #1670) [Link]