Mono 0.19 is released. Release notes, screenshots. GTK# 0.7 is also released.
Mono 0.19 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Mono 0.19 is released. Release notes, screenshots. GTK# 0.7 is also released.
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
It’s great to hear that they are making such fast progress! MacOS X support is now included, and they are working on VB support. Keep up the good work!
The font’s in all the screen shots look great. How are fonts rendered under Mono? Is font rendering platform independent?
Those screenshots use gtk#, based on gtk+ 2. It uses xft for rendering on unix.
This is exciting. There is a good release pace and a clear vision of what Mono will be at 1.0. Should only be about a year or two more. Very fast progress.
>> The font’s in all the screen shots look great. How are fonts rendered under Mono? Is font rendering platform independent?
Like said above, the fonts on unix are just handled by Fontconfig/Xft2/Freetype.
On Windows they’re rendered using the standard Windows font renderer (afaik).
No doubt the font rendering is passed to the underlying OS by each .NET implementation, so Mono will pass to X11/Freetype.
I don’t mean to start a war but what arethe advantages of c# over c++ for development on Unix type systems. I mean you pretty much recompile them for your architecure without changes on’t you. There must be something else that warrants the effort.
Also is this going to give Gnome an advantage over KDE in the long run?
It means that once you are able to run Windows .NET applications on mono/X11 they will probably look more like GNOME applications that KDE (except if you are running RedHat 😉
Although the implementation of Windows.Forms will be based on WineLib rather than the gtk# bindings.
Recompilation shouldn’t be required.
Advantage? Dangerous question.
Robert
“Also is this going to give Gnome an advantage over KDE in the long run?”
In a word No.
I’m really impressed with what Ximian has done so far, I just hope they can get Windows.Forms implemented in a sane manner.
That platano app is VERY attractive.
Is this supposed to be the default interface for applications written in mono (or gtk# or whatever I’m supposed to call it)? Forgive me if this question is worded in a way that it can’t really be answered. I’m not a programmer.
One more dumb question. Is the purpose of mono supposed to be so that programs that are written in it can be run on .NET and vice versa?
Darren
Not a good comparison. Try C# verse Java, they are the same language except C# doesn’t support Unicode source and adds a few new items (namely un-safe pointers and unsigned data types).
Its a much cleaner language then C++: no macros, no conditional compiling, no name spaces, and everything is an object. Name spaces are removed by everything being an object: std::printf() becomes system.printf() because the system object provides the printf() command.
Joe P,
You can include conditional compilation preprocessor directives in c#. Just check this out.
http://www.csharphelp.com/archives/archive36.html
I could write almost as nasty code in C# as C++.
The best part is the default support of signals. It’s *very* nice abstraction over function pointers.
Operator overloadig – not much needs to be said there.
Automatic getter/setter methods.
All in all C# is a very, very nice language.
Compared to it, Java seems like an ugly hack…
>>> Andrew wrote:
“[…] what arethe advantages of c# over c++ for development on Unix type systems.”
It is not so much about languages but about runtime systems. Mono wants to be an open source CLI with language support not only for C# but for most programming languages (I am sure C++ will be added some day). The development model is similar to the Java one. Standardized class libraries and safety are the most valuable advantages IMHO.
“Also is this going to give Gnome an advantage over KDE in the long run?”
I don’t think so. Mono is desktop environment agnostic. The GUI part of applications can be written in GTK# or Qt# or in the future maybe in Windows.Forms. KDE will certainly develop KDE# if Mono is a success and then we are in the same situation as of today–developers choose what they like some will favour GTK# others Qt#.
But if Mono is well integrated into GNOME and if Mono becomes a popular runtime target, then it might be more comfortable to choose GNOME over KDE. However there are to many ‘ifs’ and ‘thens’ in this speculation.
>>> Joe P wrote:
“Its a much cleaner language then C++: no macros, no conditional compiling, no name spaces, and everything is an object.”
C# provides namespaces and conditional compiling. “Everything is an object” is certainly no virtue by itself and hardly says anything important in relation to these particular languages.
> Also is this going to give Gnome an
> advantage over KDE in the long run?
I think it does. Linking is more flexible and library
versioning is properly done. That way the project will
be more easy to maintain across platforms. The build
process will be a lot more simple than in KDE.
You’re likely to get only one package instead of different
packages for each version of each didtribution.
Where? I saw nothing about it on the pages posted, but perhaps I’m blind. Do I have to compile from sources for OS X?
> Also is this going to give Gnome an advantage over KDE in the long run?
I agree with jeti that apps with the “Gnome feel” will have a strong advantage over KDE apps if Mono succeeds. My guess is that there will be no such thing as QT#. QT is only GPLed for Linux. Trolltech still has control of QT for non-Linux platforms and it charges for it. Unless that changes, I doubt we’ll see many QT# apps for mono if a QT# is ever even written.
I thought there already was a Qt#.
The best part is the default support of signals. It’s *very* nice abstraction over function pointers.
If you’re comparing C# to Java you should compare delegates to interfaces, not to function pointers. What do delegates give you over interfaces? Not much, except an insigificant savings of a few bytes of code. Java has anonymous inner classes, which are better than delegates because they allow you to define Observers in the place they are assigned and even allow you to use local variables from outside the class (although true closures would be even better).
Operator overloadig – not much needs to be said there.
How about that the cases where operating overloading makes code easier to read are rare, and the cases where it is abused by programmers trying to be clever abound? Would you rather read code that looks like this:
connection–;
or like this:
connection.disconnect();
Operating overloading was left out of Java for a reason.
Automatic getter/setter methods.
Which break the Principle of Uniformity. One of things that made C great was the syntactical separation of functions and variables. A good IDE will generate accessor methods for you anyway, so there’s not even any tradeoff.
All in all C# is a very, very nice language.
Compared to it, Java seems like an ugly hack…
No, C# is Java with a few shallow features. There are lots of things that could make a language better than Java, but the C# designers chose only the most insignificant ones to implement. Some C# features are nice, like explicit overriding, but C# just lacks real innovation in an area that’s ripe for it.
How much preprocessor is available, like especially macros,defines, #,## etc.
I have to say I tried getting into Java for writing compilers & graphics SW. I use macros to essentially extend the C language to the domain I am working in. The macros essentially inline alot of hidden code that makes writing parsers a snap since then the code pretty much follows the EBNF of the language I am parsing. Many of the recursive descent fn()s esp in expressions are almost one liners.
I know this is considered taboo in Java, I know that in Java I would be forced to inline the code myself or use explicit fn() etc. And I also know the result would be many times slower, and I care about that.
One thing I liked was that somebody once wrote a Java preprocessor (Jpp?) to give Java most of what C++ has, damn the Java police.
So will C# get this or will I get flamed?
Anybody who thinks that operator overloading doesn’t help make code more readable in MANY situations, apparently never did any math intensive coding in Java. Sure it can be abused, but that is no reason to leave it out of the language. Nobody is forced to use it.
-G
Because the Java designers were weenies who left out every feature that could possibly be abused by a stoned VB reject?
Seriously, though, Java went too far in disabling certain programming models. For something that’s supposed to be a “platform” (the whole VM and class library) it forces you too much into a single programming paradigm. I don’t want to have to switch languages (or deal with JNI/CNI bullshit) just because one tiny part of my code needs a construct that doesn’t fit into Java’s OO dogma. In this respect, C# makes much more sense. The default programming model discourages unsafe code, but the option is there if you need it. And if I make even a mildly non-negative comment about anything that came out of MS, you know I’m serious…
> Phuqker : I thought there already was a Qt#.
Do you have a link? I think there’s only GTK# AFAIK.
Anybody who thinks that operator overloading doesn’t help make code more readable in MANY situations, apparently never did any math intensive coding in Java. Sure it can be abused, but that is no reason to leave it out of the language. Nobody is forced to use it.
But a lot of people are forced to read and maintain code they didn’t write, and having to maintain code with gratuitous operator overloading just sucks. C# doesn’t even set a good example for programmers, overloading += for Combine in delegates.
Yes, overloaded operators are nice for matrices and complex numbers, but those things could easily be done in a special API out of the hands of normal programmers. Unless you’re writing a math library, you don’t need operator overloading, so don’t have it.
> Where? I saw nothing about it on the pages posted, but perhaps I’m blind. Do I
> have to compile from sources for OS X?
A quote from the release notes:
Paolo integrated John Duncan’s and Benjamin Reed patches to make Mono run on MacOS X out of the box.
> How about that the cases where operating overloading makes code easier to
> read are rare, and the cases where it is abused by programmers trying to
> be clever abound?
That is an excellent example of a poor rationale: cut useful language features just because some idiot could misuse them. When creating a language one must assume that the programmers who will use that language understand the consequences of what they are doing. In other words they must be competent. It is one thing to leave out language features that could be accidentally misused by competent programmers, but it is quite another to remove features that could be misused by incompetent programmers. If we did the latter, there would be no useful programming languages.
> Operating overloading was left out of Java for a reason.
Same with multiple inheritance. It is very frustrating to have to work with stupid, incompetent programmers who have no idea how to use language features properly. Why, I was shocked when I heard that Sun allowed Java programmers to create new objects. What would happen if one of them created too many objects at one time? The program could crash for lack of memory! Oh, the horror!
And did you know that Java will have both operator overloading and pointer arithmetic in its next version?
> No, C# is Java with a few shallow features.
Both of them are just simplified versions of C++ with a few shallow features.
> There are lots of things that could make a language better than Java, but
> the C# designers chose only the most insignificant ones to implement. Some C#
> features are nice, like explicit overriding, but C# just lacks real innovation
> in an area that’s ripe for it.
If you could add a feature to a language like C#, what would it be?
> But a lot of people are forced to read and maintain code they didn’t write,
> and having to maintain code with gratuitous operator overloading just sucks.
> C# doesn’t even set a good example for programmers, overloading += for
> Combine in delegates.
Working with idiots is a very demanding job, but I do not think that making operator overloading illegal would fix the situation. They would just find somewhere else to display their idiocy by making the code more unmaintainable.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the Universe is winning. – Rich Cook
Sadly, the same can be said of development tools.
> Yes, overloaded operators are nice for matrices and complex numbers, but
> those things could easily be done in a special API out of the hands of normal
> programmers. Unless you’re writing a math library, you don’t need operator
> overloading, so don’t have it.
No, I disagree. If it will be clear to many people what the overloaded operators mean, chances are that they could be used to good effect. The operators that you see in math textbooks were defined by mathematicians for their own purposes. Why is it wrong for us to do the same?
http://qtcsharp.sourceforge.net/
Thanks for the details.
I was comparing c++ vs c# because Michael de Icaza (sp?) was saying that regardless of compatibility with windows they wanted a nice platform for developing applications.
If Java is better than c++ for this why didn’t they just develop GTK+ bindings for java which I think Sun is doing now, and then work with the guys developing gcj for the GNU compiler.
Thanks again,
Thanks. Really enjoyed reading your observations. Stuff I read makes more sense now. I was reading on the mono site about support for VB.
It is one thing to leave out language features that could be accidentally misused by competent programmers, but it is quite another to remove features that could be misused by incompetent programmers. If we did the latter, there would be no useful programming languages.
A language can’t have every feature that would useful in every situation. There has to be a line drawn between essential and superfluous features. IMO, operator overloading isn’t enough of a benefit to justify its inevitable abuse.
If you could add a feature to a language like C#, what would it be?
I would like constructors to be virtual (able return an instance of one of their subclasses), and I would like closures.
Also, and these aren’t features per se, but I think null should be an object (a Singleton) and there should be different operators for object identity and value equality, or object identity could just be a method of Object (this would remove the problems with auto-boxing and value classes).
Anyway, new design paradigms like Aspect Oriented Programming show that there’s plenty of space for real innovation in OO languages, but C# incorporates nothing of this sort.
And did you know that Java will have both operator overloading and pointer arithmetic in its next version?
lies
I bet that Miguel could get Mono to replace the Gnome API like he had origionaly wanted to do. I don’t find anything wrond with that as long as you can still write Cand C++ apps that are not dependent on the C# byte code like VC++.NET is.
“Would you rather read code that looks like this:
connection–;
or like this:
connection.disconnect();”
Let it my decision, not a language limitation.
“Automatic getter/setter methods.
Which break the Principle of Uniformity. One of things that made C great was the syntactical separation of functions and variables.”
It is very nice theory but the properties are very useful in RAD environments like Borland’s Object Pascal and Visual Basic. IMHO not a bad idea if your object can do anything when the value of property changed. Typically if you changed the colour of the panel the panel must repaint. You can write setColor and getColor functions but the color property imho far better.
No language actually needs properties. But as LC was saying, they’re incredibly useful in a RAD environment. I don’t think they do a hell of a lot for the code per se, but what they allow you to do is more tightly map the public interface of a component or control to the property inspector of the tool.
Purists would say you shouldn’t design a language to anticipate the tool, but in practice the views of the purists often leave much to be desired.
Custom attributes are probably my favorite .NET feature, and they work along with properties to better integrate the language and the IDE. (Of course, custom attributes can do a whole lot more than that.)
I think C# is a nice little language. It’s no Dylan, which I adore. (And Dylan has little need for custom attributes with its hygienic macro system.) But C# gets the job done.
I have always felt that Java added way too much. To me, having to declare that a type will be an int or a char in an interpreted language seems silly – on top this the ints and chars are not objects in an object oriented language. I do know that there are OO versions of these, but having an Integer object and an integer type is confusing and messy.
There are a whole bunch of little things like this that bother me about Java, and I have read the reasons why Java was designed the way it was.
I like Java, and I really do not think that in all it is an ugly hack. It is easy to critisize it, especially since other languages like Python, Ruby, and C# have been able to improve on it in many ways. I also avoid Java, coding in it for a few years and learning to love these new OO languages.
“Would you rather read code that looks like this:
connection–;
or like this:
connection.disconnect();”
Would you rather read code that looks like this:
v_rot = T*v;
or like this:
v_rot = T.multiply(v);
In fact, I want more operators; I want to be able to define my own so I can have inner and outer products, for instance.
Now there’s a language. It even has operator overloading!!!
> A language can’t have every feature that would useful in every situation. There has to be a line drawn between essential
> and superfluous features. IMO, operator overloading isn’t enough of a benefit to justify its inevitable abuse.
I did not say that a language could have every feature that would be useful in every situation. I merely stated that it is wrong to punish competent programmers for the sake of the intellectually challenged.
> I would like constructors to be virtual (able return an instance of one of their subclasses),
Virtual constructors seem like a misfeature. In the first place it does not make any sense; one simply cannot have polymorphic behavior from nonexistant objects. In the second place it seems like a very bad design to me; why burden a class with both whatever it was designed to encapsulate in the first place and also some kind of embedded class factory functionality. I would much rather have a good, clean, reusable object factory than have to embed that type of code in “virtual” constructors.
> and I would like closures.
Closures sound like a design nightmare. Being bound to the lexical scope in which they were defined would make them highly dependent on the local variable names chosen by the programmer. If the local variable name changes, the closure breaks, and if the closure is changed, it will break other functions which still use the old name and which were used with that same closure. It would be much cleaner to simply return the value and have the calling function pass that value to a regular function implementing the behavior you intended to implement as a closure.
> Anyway, new design paradigms like Aspect Oriented Programming show that there’s plenty of space for real innovation in
> OO languages, but C# incorporates nothing of this sort.
Yes, I fully agree that there is much room for innovation. Aspects seem to be very promising although from what I have seen of them I do not think that they warrant being called a new paradigm any more than we need Garbage Collection Oriented Programming. 😉
> lies
It was stated quite plainly in the Mono 0.18 thread by a Java programmer who calls himself CroanoN. He kept saying something about a “Tiger release” of Java having these features.
> It is very nice theory but the properties are very useful in RAD environments like Borland’s Object Pascal and Visual
> Basic. IMHO not a bad idea if your object can do anything when the value of property changed. Typically if you changed
> the colour of the panel the panel must repaint. You can write setColor and getColor functions but the color property
> imho far better.
They look like a mess, and they are of little use. Writing code that differs only in case is a very bad idea, and yet this is exactly what properties seem to encourage.
> Purists would say you shouldn’t design a language to anticipate the tool, but in practice the views of the purists often
> leave much to be desired.
Amen to that! Languages are tools for doing hard work, so they should be practical.
That’s just a GTK2 theme, H2O i think or a derivative. GTK# apps are of course themable. You can have all GTK2 apps look like that.
>> I do know that there are OO versions of these, but having
>> an Integer object and an integer type is confusing and messy.
Yep. It’s hard to wrap that properly and Java has gone the
easy way. You don’t have this problem in C#.
Virtual constructors seem like a misfeature. In the first place it does not make any sense; one simply cannot have polymorphic behavior from nonexistant objects. In the second place it seems like a very bad design to me; why burden a class with both whatever it was designed to encapsulate in the first place and also some kind of embedded class factory functionality. I would much rather have a good, clean, reusable object factory than have to embed that type of code in “virtual” constructors.
Virtual constructors are not polymorphic constructors (which would indeed make no sense). They simply allow a constructor to return a subtype of itself. It’s the same as a static Factory Method essentially, and it would allow any constructor to change its return type to a possible subtype without having to change its interface. It doesn’t have to be a burden on constructors that don’t need it.
Closures sound like a design nightmare. Being bound to the lexical scope in which they were defined would make them highly dependent on the local variable names chosen by the programmer. If the local variable name changes, the closure breaks, and if the closure is changed, it will break other functions which still use the old name and which were used with that same closure. It would be much cleaner to simply return the value and have the calling function pass that value to a regular function implementing the behavior you intended to implement as a closure.
I’m not sure what you mean by closures making local variable names break other functions. Closures could just be anonymous classes that don’t require its local variables to be made final (by allocating them to the heap instead of the stack). Closures would save you from having to change local variables to member variables when they don’t really belong as member variables. Closures allow for kinds of idiom that are more object oriented but just aren’t practical otherwise, for example, Internal Iterators to traverse collections.
>> Where? I saw nothing about it on the pages posted, but perhaps I’m blind. Do I
>> have to compile from sources for OS X?
>A quote from the release notes:
>Paolo integrated John Duncan’s and Benjamin Reed patches to >make Mono run on MacOS X out of the box.
Yes, you have to build from source, the trouble is that the whole thing is written in C# and requires a C# compiler. Any one know if portable.NET’s compiler works on OSX.
The QT# link is http://qtcsharp.sourceforge.net/
http://qtcsharp.sourceforge.net/
ethzero: Virtual constructors are not polymorphic constructors (which would indeed make no sense). They simply allow a constructor to return a subtype of itself. It’s the same as a static Factory Method essentially, and it would allow any constructor to change its return type to a possible subtype without having to change its interface.
1. Constructors do not have return types.
2. Even if a constructor returned the object it constructed, the return types would have to be a reference to the base class for safety.
3. Why invent a language feature that can be implemented more cleanly in the language?
ethzero: It doesn’t have to be a burden on constructors that don’t need it.
No, but it is still a bad design decision. In implementing a virtual constructor you would be embedding code inside the class that could have been written generically outside the class.
ethzero: I’m not sure what you mean by closures making local variable names break other functions.
Closures directly access local variables outside the function by name. If the local variable’s name changes, the closure breaks. If the closure is fixed, then any other functions also used with the closure will break. The only solution to this would be to allow the closure to define its own names for those local variables, but then the closure would just be a function.
ethzero: Closures could just be anonymous classes that don’t require its local variables to be made final (by allocating them to the heap instead of the stack).
I am sure it would be possible, but that still does not fix the name dependencies.
ethzero: Closures would save you from having to change local variables to member variables when they don’t really belong as member variables. Closures allow for kinds of idiom that are more object oriented but just aren’t practical otherwise, for example, Internal Iterators to traverse collections.
All of these things could also be done – and are being done – with functors. The C++ standard library is full of them. Check out SGI’s STL reference for more information.
the compiler is platform-independent. It can be simply copied to mac os x.
1. Constructors do not have return types.
2. Even if a constructor returned the object it constructed, the return types would have to be a reference to the base class for safety.
3. Why invent a language feature that can be implemented more cleanly in the language?
Ok, a virtual constructor isn’t really a constructor, it’s virtually a constructor. Maybe that’s a bad thing to call it (i didn’t invent the term), but a virtual constructor is really just a Factory Method. And sorry if i’m using the word “constructor” loosely. I was suggesting a feature that might blur the distinction between them from the perspective of a programmer.
But to see how they would be useful: Imagine you’re writing library and you have a public constructor to create an object used externally. Now you decide you want to be able to vary the behavior of that object at runtime by returning an instance of a subclass of that object, so you have to change the API of your library to use a factory and break all the code that calls the constructor directly. If all “constructors” were already factories, you could simply change the implementation of that constructor and it would just work. I don’t see any downside …
You could achieve this in a language just by making the default constructor private and not allowing it to be overloaded, forcing static methods to be defined instead of constructors to return new objects.
If the closure is fixed, then any other functions also used with the closure will break.
I think you’re confused. From the perspective of a function that gets passed a closure the closure is just an object. It can’t see the local variables from the scope where the closure was defined. If you change a local variable name you only have to change the references to that variable from within the block of code delimited by its scope, closures or not.
All of these things could also be done – and are being done – with functors. The C++ standard library is full of them. Check out SGI’s STL reference for more information.
Functors are the same thing as closures. They’re also called blocks in Smalltalk. But neither Java or C# have them (although anonymous classes in Java are pretty close).