A new release of the Mono runtime and SDK is available for UNIX and Windows. Packages for various distributions are also available from our download page. Many new things have been improved, implemented, fixed, and tuned from the last release. The team at Ximian has been working on three areas to pass the tests provided by the SourceGear team. Elsewhere, dotGNU has made big progress.
Mono 0.25 Released
2003-06-27 Mono 36 Comments
With things moving from just pure stock implementation of features, to locking them down for robustness and reliability, things can only get better.
This is the project that allows me to feel pretty comfortable using C# as my primary language without worrying about other platforms being excluded. Anything that keeps me from having to use Java is a plus.
“Anything that keeps me from having to use Java is a plus.”
what a stupid comment. mono is not cross platform compatible. certainly not a replacement for java.
as long as it runs on windows, linux, macos, it is pretty much multi-platform on a majority of desktops.
can java compares its crossplatform with kermit or zip/unzip ?
It is kind of cross platform, however, I do see where you are coming from. What would be nice is if Trolltech made their qt version available under the same conditions as their *NIX and MacOS versions then the mono versions, both Windows and *NIX can use qt as the widget set.
As for Java, I would love to see SUN losen up the licensing on their java so that FreeBSD can release a binary version without needing to jump through 100s of hoops and handing over 1000s.
“as long as it runs on windows, linux, macos, it is pretty much multi-platform on a majority of desktops.”
it is running only on linux. mono is a .net-like implementation. not a .net implementation.
“can java compares its crossplatform with kermit or zip/unzip ?”
no. it also cannot compare with refrigerators.
>it is running only on linux. mono is a .net-like >implementation. not a .net implementation.
you can find a windows version on their download page, mono is not limited to linux
It also runs on FreeBSD as well. There is also a move to get it to run on Solaris and MacOS X.
Maybe instead of being so bloody negative, how about look at the positive aspects of it. If they can embrace and extend a Microsoft idea and turn it into something REALLY cool, why stop them?
Why does everyone seem to forget that M$ has indicated that they hold numerouse patents on .NET and they may use them in the future. For all intents and purposes developing .NET applications is Windows only affair. No self-respecting business will develop a .Net application and plan on delivering it on Linux using Mono. For the time being, they are happy to allow Mono to operate since it helps them fight Java. However, if Mono threatens Microsoft I am sure they will squash Mono in a second.
Develop on .Net at your own risk?
I don’t consider MS a threat here. A law suite would just give Mono a 100 times more more publicity than what they now have and a whole lot of anti-competitive counter-accusations against MS.
However, using Mono to develop new C# or .NET applications really makes little sense. What Mono is useful for, is moving VB.NET applications away from the MS Windows platform to cheaper alternatives.
i’m not bloody negative. i didn’t say it is useless. mono can be useful, especially in language research etc. i said, it cannot be competitor to java in its current form.
C# is a relief for Java developer as well as it is for Java final users…
If dotGNU succeeds, it might nicely create a LAMP.NET environment. 🙂
Haha, write once, test every everywhere and where ever it goes, it is slow.
you ignorant fool
“Anything that keeps me from having to use Java is a plus.”
what a stupid comment. mono is not cross platform compatible. certainly not a replacement for java.
I feel the same as the original poster. After 6 years of Java almost anything feels refreshing…
I believe it only x-platform IF you use GTK as well. Certainly NOT x-platform in the Java meaning of the word.
I thought Microsoft had a patent on the Windows.Forms API. In that case, how can the dotGNU people have their implementation? Their API would have to be significantly different to prevent it being in violation of MS’s patent. I think being able to patent an API is the silliest idea I’ve heard. Is this not why Mono developer GTK sharp?
“I believe it only x-platform IF you use GTK as well. Certainly NOT x-platform in the Java meaning of the word.”
I was under the impression that the fact it used GTK was hidden by the containing System.Windows.Forms in the same way on windows that they are wrappers around Win32 calls, and not a new API to learn.
Ah I found this…
“Gtk# based: This effort will build a subset of Windows.Forms that uses Gtk#. This gives a better integration with the desktop, but will not be completely compatible with the Windows edition. In particular code that uses P/Invoke to call into Win32 or overwrite the Wndproc method to achieve special effects will not work.”
I would assume that overriding WndProc is a fairly platform specific thing to do, although the fact that it exists in itself means there was no attempt at platform independance. I’ve done it myself (only once) because there was no alternative though.
Java and .NET really aren’t competition as they are targeting different markets. .NET is predominately CLIENT based, sure there are things like ASP.NET and ADO, but from what I understand, the real crown jewel of .NET is WinForms.
Java on the other hand sits handily in both the high-end enterprise server market with J2EE (way too much money and time has been invested in this for Java to disapear from this segment for a while) and on the opposite extreme: the embedded market. Almost every major cell phone manufacturer now supports Java, it also becoming a large presence in TV set top boxes. (It is a little known fact that TV set top boxes is what Java was designed for in the first place.) However, when it comes to desktop clients, it has been relatively week, with even Java applets fading away. The latest incarnations of Swing are starting to turn the tide on this, but it will no doubt be an uphill battle. People still associate desktop Java with slow, despite remarkable advances in JITting and other performance enhancements.
Anyway, the two only overlap in two areas from what I can see at this time ASP/JSP and desktop clients. With ASP/JSP, it seems to be tipped toward Java a little, and with desktop clients, I’d say the scales are currently tipped toward .NET
The interesting thing, is that the two aren’t really mutually exclusive, what’s to prevent a .NET client app from talking to a Java server app? I think we can expect just that kind of configuration in the coming years, especially with “web services” and SOAP being very popular, and both frameworks containing robust support for such technologies.
Anything that keeps me from having to use Java is a plus.
I’m just curious. Is that opinion based on technical merits or just on prejudice?
The reason I ask is that I use both languages extensively and in all honesty, they are extremely similar both in functionality and in syntax. How anyone could detest one and have a horny infatuation with the other one is beyond my comprehension; unless the reasoning is purely political.
Mono can run on multiple platforms, but I don’t think it is ready to be run on ANY platform in a production environment yet. It’s only a 0.25 release. It’s infancy still makes it largly irrelevant in my opinion. This will of course change.
Don’t get me wrong. I think C# is a great language and look forward to using Mono in a production environment once it is more mature. In the mean time, I do a lot of C# programming for Windows and Java, Python, PHP, C/C++, etc. programming everywhere else.
Another thing, I think C#’s abilities on the server side are lacking. ASP.NET is just gay. Java, is the better choice there regardless of Mono’s maturity, in my opinion.
I wish people would use the best tools for the job instead of populating their Utility Belts based on politics and corporate spats.
I understand and I certainly wouldn’t call it production ready.
Regarding Winforms, they are being implemented via the winelib where as gtk will have a wrapper called gtk#. The reason for GTK# is because it provides a famila API for those who are used to using GTK, secondly the speed of winelib development is pretty slow meaning one would wait a very long time if the whole project hinged on one factor, and thirdly from what i have heard GTK# is much nicely toolkit to write code for than winforms.
Ontop of that, one has to also take in account the fact that SWT has already been ported to mono and that sharp develop is being ported to SWT which, once ready, give mono a nice IDE for development.
Regarding the sharedsource version of the .NET, had they been truely committed to expanding the adoption of .NET on other platforms, they would never had licensed it under a more draconian license than the GPL. Had they put their money where their mouth is they would have licensed it under X11/MIT (like the mono libraries are).
If anyone does remember Microsoft praised the BSD license to the hills, yet, we don’t see them using it for one of their pet projects.
Is anyone else having problems installing the RPMs for redhat 9.0 … dependecy on PERL-Lib etc…
Uh, STB’s were not ‘made for Java’. For one, flash memory is an expensive commodity (if youre talking manufacturing quantities of millions), and in making disposable STB’s one wants to waste as little of it as possible. Not so if you have to install a JVM on each one.
In fact, Java is not found on many of them, nor is it deployed in large quantities anywhere. Sun tried 2 years ago to become a big player in the STB market with Java, using the token big splashes at NAB and CES. It popped and fizzled.
If you want to develop software for STBs you’re going to have to learn C/C++ and use the PowerTV or OpenTV platforms. Good luck finding a deployed Java STB platform. The availability of other middleware vs. Java makes it even tougher for them to make inroads into the STB market.
So we’re down to two options. Either you do ‘low-level’ code using C/C++ and one of a handful of APIS supported by multiple STB vendors, or you do ‘high-level’ scripts (JS, HTML, etc.) supported by the same vendors, or the ‘rest of them’ (Linux STBs, etc).
Things like this http://fusionauthority.com/Article.cfm?ArticleID=3087 are eating Java’s STB lunch.
Since when is C++ low level? Assuming a decent runtime environment (and the STL is a lot easier to shoehorn into an embedded platform than Java C++ is a higher level language than Java. Java is a pretty vanilla OOP language. C++ allows you to go a good bit beyond traditional OOP in the abstraction department. I’m using C++ right now for embedded development, and my guess is that C++’s “low-level” image comes from C programmers who thing they know C++ because they know what a class is!
Just a generalization
I wont even try to comment your statements because it’s such an unbelievable FUD.
C++ is a higher level language than Java.
Of course C++ is low level, lowest level OOP language can get. And C++ has twice that many feature than Java, as to language Java is subset of C++ so go troll elsewhere.
I think is what generally qualifies C++ as low level.
int main( int argc, char **argv)
string a = “Hello world”;
string *b = &a;
cout << *b << endl;
Since when does having twice as many features mean a language is lower level? Seems like the opposite would be true. But it is precisely because most of Java’s features are a subset of C++ that C++ is a higher level language than Java. Specifically, templates combined with operator overloading allow you a significant amount of abstraction power that you can’t get with Java and its much more straightforward design.
A low level programming language is mostly tied to a specific hardware. Assembly is the lowest you can get without programming in binary numbers. A program written in Assembly for Intel can not be ported to a PowerPC without completely re-writing the program for the PowerPC.
C/C++ is the next level up. You can still get to the metal with C/C++ even though you have some hardware abstraction capabilities.
Basic, Perl, Python, Ruby, Java are languages further up in the hardware abstraction ladder. With these languages you can generally create a program with out worrying what type of CPU is in the machine. The things you do have to worry about are whether the interpreter/VM is installed and if you used any system call features of the language.
A really high level language would be that a program created with the language could run on any device without modification.
Your definition is very simplistic. A more accurate definition of high-level languages takes into account the abstractive power offered by the language. For example, both Python and Java are high-level by your definition, but Java is actually a medium-level language compared to Python, or something like Lisp or Haskell or any of a number of very high-level languages. In terms of abstractive power, C++ is a notch above Java, because it can do pretty much everything that Java can, along with some things Java can’t.
That said, if you don’t write C code in C++, C++ can be almost as portable as Java. The CPU-specific features come into play when you do stuff like reinterpret_cast or hold pointers in integers, not really when you’re doing regular code.
If you REALLY have to go for this “managed interpreter” application craze currently being PUSHED ON US by the corps than at least use a language-interpreter that is open source and free like PYTHON and not controlled by people of questionable loyalty to ANYTHING but Satan and the buck Like M$ and Sun.
Mono is nothing but an M$ patent trap waiting to happen that will make SCO look like a sunday school picnick because Micro$oft in addition to being a monopoly is a SATANIC COMPANY!!! The original name “Palladium” for their future control everything technology PROVES this as does the REAL meaning of their “product activation” technology.
(I will have the elaboration of this posted on EVERY Micro$oft related post on this forum from now on out!)
The best way for Linux developers weather proprietary or free to go is with native code development with C/C++ or with FreePascal if you’re coming from a Windows/VB background and can not yet master the C/C++ language. I know that most Linux developers consider Pascal to be obsolete however I still consider FreePascal to be the best alternative to BASIC on Linux until one can master the basics of a programming language enough to graduate to C/C++
because it is easy for basic users to move to and it compiles to NATIVE CODE. I also believe that continuing with native code apps is in the best interest of Lunix because it will give a desided ADVANTAGE to Linux
in native app speed of execution over “managed app” bloat and slowness that will make it even MORE desirable for both business and home use as Windows continues to slide down the bugs, bloat, .NET “managed app” molassis pit.
As for software patents from both Micro$oft and others that
endanger Linux development I will soon be posting a plan to fight them that will include the idea of public domain BY LAW for all declared obsolete software and the STRATEGIC use of the GNU GPL/LGPL and a third license of my own design to both make Linux development more attractive to proprietary developers and discourage their retaining or taking out software patents. I will be licensing the open source libraries that I develop under this upcomming arrangement ans hope that other open source developers follow suit.
As far as I understood the distinction it’s basically something like imperative = low level and declarative = high level. Among the imperative languages the pure procedural would be lower level than the object oriented and among the declarative the functional would be lower than the logic based.
Considering the power introduced by the template mechanism in C++ I’d say it’s higher level than Java but still lower than functional languages. As I see it: C < Java < C++ < ML < Lisp < Prolog. It’s a matter of definition of course, so I guess there is no right or wrong here.
bytes256: It is a little known fact that TV set top boxes is what Java was designed for in the first place.
Kon: Uh, STB’s were not ‘made for Java’.
No, but Java was made for STB’s. The Oak language was originally a notation for a proposed set of embedded media-processing chips. An emulator for the instruction set of those chips became (after marketing renamed the language) the Java Virtual Machine.
Actually, the differences between the .NET IL and JVM instruction sets are based in this heritage: The JVM was designed to be implemented in hardware, IL to be JIT-compiled to other instruction sets. This is why Java was so slow at first – not now though, after years of hacking around the JVM model to figure out how to make it JIT efficiently.