Following Paul Ferrill’s article “What is Mono and why should you care?” on DevChannel.org, find an all-around Linux article by Dee-Ann LeBlanc “And Then There’s Mono“, while yesterday the LUGRadio had a show dedicated to the controversial nature of Mono.
Articles and Shows on Mono
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
i ran a .NET app made in windows…it ran on linux…but it didn’t work…
Windows Forms won’t be fully implimented for a while.
I know Mono and .Net use a VM as does Java.
But it has yet to become clear to me what the magic is about Mono and .Net. I know they both use a VM as does Java. No magic there.
Can someone – preferably an expert – please summaries what the magic is as compared to other environments/languages? Thank you in advance.
Seriously – I think your question is way too broad and subjective to be answered in any way useful.
The VM of .NET is a much better design than the java VM.
It supports some things that are very important for performance and that java has not, such as value types.
It is also a true cross-language VM. For example it has a tailcall instruction to better support functional languages.
It also supports pointers in unsafe mode for low level stuff. So you could write device drivers in unsafe .NET without much problems.
…its 45ish minutes into the “radio shadow” that they discuss Mono.
The CLR was designed intentionally allow multiple languages and alot of extra “goodies.” Language agonistic, in other words – syntax bedamned, because as long as it compiles down to IL…
The problem with JVM is that the virtual machine was designed around Java, which makes every other language that compiles to it “Java-ee.”
The magic of Mono is that it is both a managed platform and language agonistic, so there is no more need to generate “language bindings” and then “language wrappers” on top of those bindings – you get everything ‘automagically’ just by having a language that compiles down to .NET bytecode.
Ever been on a mailing list where they’re trying to generate Gnome-specific bindings in time for the next Gnome point release? Not pretty…
There’s also a ton of other goodies, value types, real generics, etc…
Hopefully this will lead to binary compatibility between Windows and Linux. I doubt it, but one can always hope.
if you had a .net app that you used everyday wouldnt it be better compiled? so wouldnt it be cooler if the program was distributed as bytecode like java but the first time its used it would be compiled into machine code for that platform/os?
(i hate limewire because its so slow)
> if you had a .net app that you used everyday wouldnt it be
> better compiled? so wouldnt it be cooler if the program was
> distributed as bytecode like java but the first time its
> used it would be compiled into machine code for that
> platform/os?
>
You can compile MSIL bytecode to native code at installation time. It is called ahead of time (AOT) compilation. Both microsofts .NET and mono support it. You can specify which assemblies are precompiled in the installer.
True. But you don’t need to – Microsoft (and Mono’s, I think) keep a cached copy of the compiled application, so after your first run, it really doesn’t matter anymore.
Sweet!
I was a VB dev. for 6 years, and c dev for 3 years when MS introduced .NET have made some tests for my ready apps to upgrade, after that I prefered to swich from MS platforms to python and wxpython.
I do not understand why spend lot of human and money resources for an unknown platform future , intead there is a lot of work of what already have, like perl , python and others that need these resources to go ahead.
unknown platform future?
microsoft is BIG – .net/mono/c# will be used no matter what.
mono is in beta – it seems to me that if m$ fails and nobody uses .net then mono is still a stand alone linux technology that could be used
also i dont know if wx is backed by any corporation but novell is backing mono and m$ is backing .net. plus one of the rumour sites said the next ver of Quark *may* use mono for its base for both win and mac versions
People shouldn’t compare python to Java or .NET, as it is not the same thing. Sure it’s a bytecode compiled language, run by an interpreter (and/or JIT Compiler, im not sure with python). But, in the case of Java, it is not a secure or strongly typed language. It is very much like ordinary shell scripting languages where variables are declared when you use them, and types are determined when variables are assigned. This means less compile time errors are picked up, and so it’s easy to shoot yourself in the foot.
I’m studying the JVM as part of my PhD, and as much as I would like to like Java, I really can’t. It’s just so clunky, and the API is married to the JVM too closely (e.g. weak/phantom references, and some other things I forget now)…
A couple of things I’ve always hated about programming in Java are: Lack of Enumerated Types, and lack of a standard preprocessor. I love the C preprocessor. I end up writing everything in C because it’s just so comfortable and flexible (esp. in regards to preprocessor trickery and compiling debug versions, etc, just by changing some compiler flags).
Writing stuff in Java would probably help my understanding of the language, but I just find it so painful.
[quote]
True. But you don’t need to – Microsoft (and Mono’s, I think) keep a cached copy of the compiled application, so after your first run, it really doesn’t matter anymore.
[/quote]
Any proofs for your claim? AFAIK MS .NET doesn’t. If you want a native image of your assembly you have to use ngen.exe. This will compile the byte code to native code and store the image. The next time the assembly is used it is checked whether a native image for that special assembly (version etc.) is available. If you call Mono with –aot it creates a shared library for the .exe.
If you’re running mod_mono , please take it off the internet , coz I already managed to trash my apache with a couple of kiddie scripts floating around .. One guy has published a set of vulnerabilities of mono (include buffer overflows, mutability of strings, private member access etc..) I’m just waiting to see if the Mono website gets trashed or not … The only consolation is that I’ve not been able to get a root exploit … but I’m not sure.
But this is just like MS , release often, release early …and release buggy … Only that it’s from Novell.
http://65.248.4.192/~t3rmin4t0r/mono-problems.tgz contained a set of those crashes (it BSOD’d my win2k box … damn) .. at least was there a couple of months ago …. (it was “claimed” in that file that these problems was reported to mono in October 2003 … and was not fixed ?). [strangely this same guy ported MyXaml to linux ???]
My project has almost dropped the idea of using Mono to host our stuff , though we’re still debating on whether Apache + mod_mono compared to IIS + ASP.net has less problems or not.
What part of BETA didn’t you understand?
People shouldn’t compare python to Java or .NET, as it is not the same thing. Sure it’s a bytecode compiled language, run by an interpreter (and/or JIT Compiler, im not sure with python). But, in the case of Java, it is not a secure or strongly typed language. It is very much like ordinary shell scripting languages where variables are declared when you use them, and types are determined when variables are assigned. This means less compile time errors are picked up, and so it’s easy to shoot yourself in the foot.
Do you know unit testings?
Get your facts straight. Python is strongly typed
From Dive into Python ( http://diveintopython.org/ ):
statically typed language
A language in which types are fixed at compile time. Most statically typed languages enforce this by requiring you to declare all variables with their datatypes before using them. Java and C are statically typed languages.
dynamically typed language
A language in which types are discovered at execution time; the opposite of statically typed. VBScript and Python are dynamically typed, because they figure out what type a variable is when you first assign it a value.
strongly typed language
A language in which types are always enforced. Java and Python are strongly typed. If you have an integer, you can’t treat it like a string without explicitly converting it.
weakly typed language,
A language in which types may be ignored; the opposite of strongly typed. VBScript is weakly typed. In VBScript, you can concatenate the string ’12’ and the integer 3 to get the string ‘123’, then treat that as the integer 123, all without any explicit conversion.
So Python is both dynamically typed (because it doesn’t use explicit datatype declarations) and strongly typed (because once a variable has a datatype, it actually matters).
What part of BETA didn’t you understand?
If the claims this guy is doing are right, this looks more like pre-alpha kind of errors than beta errors. Unless Mono is planning to have a very long beta cycle.
What part of BETA didn’t you understand?
It seems as though this is alpha software, not a candidate for beta testing. Perhaps mod_mono shouldn’t have been released as part of the Mono beta?
strongly typed language
A language in which types are always enforced. Java and Python are strongly typed. If you have an integer, you can’t treat it like a string without explicitly converting it.
But in python you can assign a number to a variable (var = 5) and later assign a string to the same variable (var = “string”)
And a fuction like
def function(variable)
accept any type
python dont look very strongly typed
whith unit testings who needs strongly/statically typed garbage?
>> python dont look very strongly typed
Then you still don’t understand what that term means. Re-read the above definitions.
After recently rediscovering gcj I’m back to using Java.
Java is such a nice pleasant language to use (especially for “non-programming experts” — folks who are experts in *other* fields but still write some software). What GNU/Linux needs is for these folks to be writing their apps for *Linux*, not for “Windows-but-should-run-on-Linux” (as would likely end up being the case with Mono/C#/.Net).
Being able to compile down to machine code (via gcj) is just what Java has always needed. To put the icing on the cake, both gcj and Classpath are official GNU projects.
Really, I don’t know why the Mono folks aren’t working on gcj/Classpath instead. Why play catch-up with MS, risk possible latent patent issues, while at the same time give folks another reason to just write their software on Windows and hope it runs on Linux? Instead, just help the gcj/Classpath folks implement the remaining Java classes that users most need, and you’re good to go.
There are many Java programmers are out there (also folks like geologists, chemists and physicists who write some Java to solve their problems) who’d *love* to write real ahead-of-time compiled desktop apps. I think once gcj gets Swing implemented, you’re gonna see some pretty serious s**t.
“for an unknown platform future”
3 year’s ago this would be a valid statement, today it’s ridiculous and makes me wonder if somebody can really be that ignorant or maybe tries only to spread the usual fud in the hopes there are people dumb enought to believe it.
Now if only Ximian would fix Mono to run on FreeBSD -current (I seem to recall the problem being related to the garbage collector) and make Mono Debugger run on other implemetations than NPTL.
“AFAIK MS .NET doesn’t.”
You know what? You’re absolutely right! Apparently it was a rumor or disinformation that someone started a long time ago, and the meme spread and eventually infiltrated a bunch of (poorly written) research papers, blogs, newsgroups. The CLR-programmers, the one that work on the VM, they keep refuting it everytime it comes up in the *.clr newsgroup!
Man, the Internet can be a very dangerous thing…
…although it begs the question, why not keep a cached copy of the executable?! I mean, its inefficient to keep JITing over and over and over if the executable hasn’t changed a lick, nor the hardware…
/me digs around to see if Mono does this.
Java is alright. We’ve decided on java/GCJ/swt for some management and reporting tools that we’re going to be writing. Eclipse is a joy to work with. We needed crossplatform and evaluated mono, but two main things convinced us to go with Java. First, gtk#. gtk+ is alright as a c-based toolkit but our group isn’t big gtk# fans. And gtk+ has always had issues on windows anyway. Secondly, even when Mono 1.0 does come out this summer it’s still going to be beta software. 1.1 will probably be a better candidate for production work. And not as important, but still an issue, there’s no good crossplatform IDEs for .NET yet. You’ve got Sharpdevelop, Borland, and VS.NET for windows, but Monodevelop is nowhere close to being usable in a production environment.
That said, java has issues of its own. As others have pointed out, the jvm was built around java the language and even though other languages have targetted bytecode it’s still not as nice as MSIL. There’s some syntatic sugar that make c#, imo, a better language than java.
The good news for us is that with IKVM we can use java with mono at some later point if we decide to. I hear it’s even running eclipse on top of mono, which is pretty impressive.
um.. no.. the VM of .net takes up alot more resources than of Java…. the people who usually perfer .net over java are those of windows-loving developers that do not understand java nor are serious programmers in java.
Also, mono isn’t much useful right now.. maybe eventually.. outstanding progress though.
Although the name of the project Mono originates from the Spanish for “monkey” (and you remember that Ximian’s logo was a monkey) — it’s interesting enough to note that “mono” in Japanese means “object”.
AFAIK MS .NET doesn’t. If you want a native image of your assembly you have to use ngen.exe. This will compile the byte code to native code and store the image. The next time the assembly is used it is checked whether a native image for that special assembly (version etc.) is available. If you call Mono with –aot it creates a shared library for the .exe.
Good God! You look at this dog’s breakfast and you wonder what the point of managed code is. Managed code just seems to be a way of not trusting the programmer, and basically, not trusting anything, and it seems to be one of things that sounds cool but you look at it and realise that there’s actually no point.
The fact is that a Common Language Runtime Environment has just been a, rather successful, smokescreen by Microsoft to completely take over Java in terms of mind share. Believe me, the Common Language Runtime will not be the ECMA standard – it will be Windows itself!
Managed code on Windows is a myth. A lot of MS .Net binaries on Windows are not compiled purely to the CLR – they are a mix of CLR/x86/COM code. There may be a number of reasons for this, mostly historical, but Microsoft have basically admitted that a lot of applications cannot be compiled purely to the CLR. This may be Microsoft tying those applications to Windows, but a CLR environment is quite clearly not going to be a universal way of developing software and Microsoft will always have that natively compiled option. What’s more is that this will be completely transparent to the developer; hey, this is Windows we’re talking about here! This is something Miguel de Icaza and Mono seem to have completely misunderstood.
Taking this into account, you might as well just have natively compiled code, but surround it with good, productive development tools and a good environment to run within. Oh wait…
Managed code and Sandboxing sucks until yours is the program that has the buffer overflow that allows the virus to format the hard-drive on someone’s harddrive.
Better get to checking those bounds!
is this what you guys are talking about?
“On the initial call to the method, the stub passes control to the JIT compiler, which converts the MSIL for that method into native code and modifies the stub to direct execution to the location of the native code. Subsequent calls of the JIT-compiled method proceed directly to the native code that was previously generated, reducing the time it takes to JIT-compile and run the code.”
<a href=”http://msdn.microsoft.com/library/en-us/cpguide/html/cpconjitcompil…
Sort’ve. I was under the impression (I read it in what I now know to be several ‘flawed’ research papers) that after first-run the program, after being JITed and stored in the memory cache, was copied to a cache on the hard-drive so no further JITing would be needed the second, third, etc, consecutive run, man. It sounds like a sane thing to do, too, which is why I never questioned it.
Wouldn’t storing to the hard disk (in many situations) be slower than just running the jit again? I’m just thinking out loud here but, couldn’t storing this to the hd pose a new type of security risk – unverifiable execution? I always thought like you, probably because I read it somewhere in some article or paper, that code, where appropriate was jit’ed or pulled from a cache. Also, the loading of assemblies that are actually used/executed was a nice [different] feature. There has obviously been a lot of thought that went into making and executing programs as efficient as possible. I’ve been looking for how mono does it, but haven’t turned up much yet. I’m assuming that they followed this lead but this isn’t based on any hard data – just a guess. Mono developers are in a great position to build on Microsoft’s idea to create even more efficient executables (just as Microsoft did for all the technologies that they borrowed to create the first .net implementation).
Anyhow, to the original question I think: it would seem that bits of code can get loaded into a cache automatically as it is consumed by the application or you can force big chunks and assemblies be cached explicitly depending on your needs.
@David – so don’t use .net. You seem to have a lot to say without actually saying much.
um.. no.. the VM of .net takes up alot more resources than of Java….
Proof, anyone? I love these content-free posts /sarcasm
the people who usually perfer .net over java are those of windows-loving developers that do not understand java nor are serious programmers in java.
Said a guy who probably earns his living write Java code and fears the spread of .NET.
Also, mono isn’t much useful right now.. maybe eventually.. outstanding progress though.
Again, proof?!? Sheez. Why bother posting if you can’t even bother supporting any of your ridiculous statements?
Good God! You look at this dog’s breakfast and you wonder what the point of managed code is. Managed code just seems to be a way of not trusting the programmer, and basically, not trusting anything, and it seems to be one of things that sounds cool but you look at it and realise that there’s actually no point.
Uh, yeah, there are numerous points to using Java or .NET: Managed code is simply faster and easier to write in. It provides greater portability, vastly improved security over native apps, easier deployment, better compatibility, etc, etc. While these things may not mean much to you, the cost savings will be impossible for businesses — the ones who employ most developers — to ignore. Plus, why should a programming environment trust your code? Many people write crappy, sloppy code. If I were a VM, I’d definitely want to sandbox the hell out of your code.
The fact is that a Common Language Runtime Environment has just been a, rather successful, smokescreen by Microsoft to completely take over Java in terms of mind share. Believe me, the Common Language Runtime will not be the ECMA standard – it will be Windows itself!
Who cares. You’ve said nothing to counter the “build-a-better-mousetrap-and-they-will-buy-it” argument.
Managed code on Windows is a myth. A lot of MS .Net binaries on Windows are not compiled purely to the CLR – they are a mix of CLR/x86/COM code. There may be a number of reasons for this, mostly historical, but Microsoft have basically admitted that a lot of applications cannot be compiled purely to the CLR. This may be Microsoft tying those applications to Windows, but a CLR environment is quite clearly not going to be a universal way of developing software and Microsoft will always have that natively compiled option. What’s more is that this will be completely transparent to the developer; hey, this is Windows we’re talking about here! This is something Miguel de Icaza and Mono seem to have completely misunderstood.
Again, so what. One of the major points of going to the CLR is that it allows you to mark code which calls into native code as “unsafe”. Code which arrives from an untrusted zone is not even permitted to execute unsafe code. This security model is automatically imposed on every class that’s used. The days of attacking MS with low-hanging buffer overflows and privilege escalation fruit are coming to a close. Your code? Hardly. C/C++ code is traditionally riddled with security issues.
Taking this into account, you might as well just have natively compiled code, but surround it with good, productive development tools and a good environment to run within. Oh wait…
No, totally wrong. I’d advise you to spend a little time in a Fortune 100 company and absorb what they’re doing with Java and .NET. Natively-compiled languages are on the decline. The CS departments in most universities no longer teach C or C++. They teach Java and/or C#. Over time, what will happen is that C/C++ developers are going to become marginalized. Based on your comments, you probably won’t accept this reality. So be it. I will make more money, while guys like you try to keep up with your native code.
Instead of mindlessly repeating JVM is Java-centeric and every JVM language is Java-like, try Jython, Jacl, and Kawa. They are *not* Java-like. They are *not* crippled. They are really another fine implementation of Python, Tcl, and Scheme.
Wouldn’t storing to the hard disk (in many situations) be slower than just running the jit again?
No. There’s nothing which says you have to write it immediately. This could be done asynchronously.
I’m just thinking out loud here but, couldn’t storing this to the hd pose a new type of security risk – unverifiable execution?
No. .NET has a feature called protected storage. The files are not accessible through the native filesystem — nor can they be accessed by apps without sufficient privileges.
No. There’s nothing which says you have to write it immediately. This could be done asynchronously.
Interesting, but I meant loading it back into memory to use again – not loading to the hd for storage.
Uh, yeah, there are numerous points to using Java or .NET: Managed code is simply faster and easier to write in. It provides greater portability, vastly improved security over native apps, easier deployment, better compatibility, etc, etc.
Blah, blah blah, hype, hype, hype. Sorry, but you’re going to have to create some concrete examples. The fact is that I can do exactly the same things with natively compiled code – with none of the hassle. I would never say that Java has greater portability, deployment and compatibility (just try updating your runtime environment) and .Net is still unproven. The better security argument means nothing as well. You’ve just pulled this out of a Java/.Net article.
While these things may not mean much to you, the cost savings will be impossible for businesses — the ones who employ most developers — to ignore.
You’re mistaking a CLR environment for good productive developer tools and a good surrounding infrastructure and desktop environment to design and run applications within. These are the things that matter. Managed code with a runtime environment means absolutely nothing.
Plus, why should a programming environment trust your code? Many people write crappy, sloppy code.
Nice. So we give terrible programmers an environment in which to write terrible code and say “It’s OK. You have a CLR to run it in!”. This is a very, very poor excuse for Mono and the CLR. I’d rather focus on the development tools and the surrounding infrastructure in which a natively compiled application will run to encourage the programmer to get things right. You can place exactly the same security controls and restrictions on code and still focus on making sure that the programmer is productive. A CLR environment is not going to do that for you. Repeat after me: The CLR and hype != better applications, better code and better productivity.
Who cares. You’ve said nothing to counter the “build-a-better-mousetrap-and-they-will-buy-it” argument.
Hmmm, nice cop out. My point is that the supposed interoperability with Windows will be non-existant as the ECMA standard takes less of a centre-stage. Windows will be the .Net runtime environment, as I’m looking at this from a Mono perspective.
Again, so what. One of the major points of going to the CLR is that it allows you to mark code which calls into native code as “unsafe”.
I was looking at this from the point of view of Mono, and that in many cases your applications will not be managed code at all. Please read the articles.
Code which arrives from an untrusted zone is not even permitted to execute unsafe code.
This is what ActiveX was supposed to do
.
The days of attacking MS with low-hanging buffer overflows and privilege escalation fruit are coming to a close. Your code? Hardly. C/C++ code is traditionally riddled with security issues.
What on Earth do you think that .Net, the CLR and Windows technologies are written in? Clue; they’re not written in C#. If people think this is going to mean the end of many exploits then they’re going to be very disappointed. My code? Using a good set of programming tools, a good environment/OS (which is your runtime environment) and a good toolkit allows me to be very productive and I do not need any of the supposed benefits of managed code? Why? Because there aren’t any. After all, I’m still writing an application that is going to be doing the same thing.
Quite why we need the overhead of a CLR is anyone’s guess. It, of course, has many cross-platform possibilities, but the notion that somehow it is going to make my code more secure, allow me to write sloppy, terrible code and be more productive is just plain ludicrous.
This is a typical, ignorant Windows programmer response that you will read in every silly Windows publication the length and breadth of every country in the world. Not all Windows programmers are like this, but unfortunately, enough of them are.
No, totally wrong. I’d advise you to spend a little time in a Fortune 100 company and absorb what they’re doing with Java and .NET.
Oh dear, oh dear. I’d advise you to actually visit a Fortune 1000 company and look at what they are doing. The vast majority of their critical IT infrastructures still depend on 30 year old mainframes, and the vast majority of their desktop applications are VB/COM based that, in some cases, stretch back to Windows 3.1 days. This will remain so for some considerable time because no one is going to re-write them. Fortune 1000 companies do not use the latest in desktop technology, they don’t use the latest hardware and they don’t use the latest bit of technology with a lot of media hype behind it. Why? Because they can’t focus on re-writing everything just because someone like you comes along and tells them the way that things are going.
The CS departments in most universities no longer teach C or C++.
Mmm, no – many are still teaching these languages because they are still very widespread. There are still millions of Visual C++ and embedded applications out there that still need to be maintained, and guess what? No one is going to re-write them in C# and .Net
.
Anyway, you’re thinking about pleb first-year students. Yes, many are teaching Java/C# to these people. But, you’re buying into the hype of the languages – it is still just programming, and it doesn’t matter what language you start off with. Besides, using C# as a language does not necessarily mean that you will be using a CLR environment – C# is merely a language.
Over time, what will happen is that C/C++ developers are going to become marginalized.
There are still a lot of C/C++ applications out there that no one is going to re-write. Besides, don’t you know that C++ is still a development option in Windows programming? Why? Because for a lot of applications native code is still vital.
Based on your comments, you probably won’t accept this reality. So be it. I will make more money, while guys like you try to keep up with your native code.
As usual, people like me will let you take the hype as far as it will go and then watch you fall as the hype fails to deliver. We’ve been through this with Java, you know?
I will continue to use good, productive programming tools that enable me to write efficient code, and use a good environment (permissions, Unix/Linux desktop environment) and toolkit run it in that can do everything (and a heck of a lot more) a CLR environment is supposed to offer me.
I never cease to be amazed by how much people by into this hype without looking at what they can do today.
“I never cease to be amazed by how much people by into this hype without looking at what they can do today.”
It’s easier with “1”‘s and “0”‘s. Buy a car, one can see the upsides, and downsides. Buy a box of bits, and you really have to test thoroughly, to say what you’ve purchased. And both are defended because of the “I made a good decision, darn it”. Psychology 101.
Blah, blah blah, hype, hype, hype. Sorry, but you’re going to have to create some concrete examples. The fact is that I can do exactly the same things with natively compiled code – with none of the hassle. I would never say that Java has greater portability, deployment and compatibility (just try updating your runtime environment) and .Net is still unproven. The better security argument means nothing as well. You’ve just pulled this out of a Java/.Net article.
Hardly. Here’s a concrete example for you. Go to monster, dice, or any of the employment websites and do a search for Java/.NET jobs — and then do a search for C/C++ jobs. I think you’re in for a surprise. This isn’t hype. It’s real. Companies are using Java/.NET because it costs them less to write, deploy, and support managed apps.
You’re mistaking a CLR environment for good productive developer tools and a good surrounding infrastructure and desktop environment to design and run applications within. These are the things that matter. Managed code with a runtime environment means absolutely nothing.
All I know is that I can code circles around you, if you’re writing C/C++ apps. So go ahead and fiddle around in your IDE, if it makes you happy. Meanwhile, I’ll be cashing checks.
Nice. So we give terrible programmers an environment in which to write terrible code and say “It’s OK. You have a CLR to run it in!”. This is a very, very poor excuse for Mono and the CLR. I’d rather focus on the development tools and the surrounding infrastructure in which a natively compiled application will run to encourage the programmer to get things right.
That’s not what I said. Try Logic 101. VM-based apps are sandboxed. If they have bugs, they don’t crash the machine. They don’t violate fundamental system security. When YOUR native apps fail, you might as well dump the system in a FedEx mailer and send it to Russia or China.
Hmmm, nice cop out. My point is that the supposed interoperability with Windows will be non-existant as the ECMA standard takes less of a centre-stage. Windows will be the .Net runtime environment, as I’m looking at this from a Mono perspective.
Again, so what. THis isn’t a negative, as far as I can tell. Mono doesn’t need to be completely interoperable with whatever Microsoft does to be useful.
I was looking at this from the point of view of Mono, and that in many cases your applications will not be managed code at all. Please read the articles.
Wow. You’re making me choose between totally native and partially native. And this distinction is important because…?
What on Earth do you think that .Net, the CLR and Windows technologies are written in? Clue; they’re not written in C#. If people think this is going to mean the end of many exploits then they’re going to be very disappointed.
Read for comprehension. I didn’t say the end of exploits. What I said was that low-hanging fruit (buffer overflows, etc) are going to be eliminated because of the VM sandboxing.
My code? Using a good set of programming tools, a good environment/OS (which is your runtime environment) and a good toolkit allows me to be very productive and I do not need any of the supposed benefits of managed code? Why? Because there aren’t any. After all, I’m still writing an application that is going to be doing the same thing.
Your code will be more buggy, hands-down. It’s the nature of C/C++ apps.
Quite why we need the overhead of a CLR is anyone’s guess. It, of course, has many cross-platform possibilities, but the notion that somehow it is going to make my code more secure, allow me to write sloppy, terrible code and be more productive is just plain ludicrous.
Because everyone knows how well writing native apps has been for virus-writers, after all… /SARCASM
This is a typical, ignorant Windows programmer response that you will read in every silly Windows publication the length and breadth of every country in the world. Not all Windows programmers are like this, but unfortunately, enough of them are.
And this is the typical, ignorant Luddite programmer response from somebody who is resisting the pull of reality.
Oh dear, oh dear. I’d advise you to actually visit a Fortune 1000 company and look at what they are doing. The vast majority of their critical IT infrastructures still depend on 30 year old mainframes, and the vast majority of their desktop applications are VB/COM based that, in some cases, stretch back to Windows 3.1 days.
Too late. I work for one. We’re using our fair share of mainframes and legacy stuff — but the glue that binds much of it together is Java and .NET. If you aren’t using this stuff, you might as well put your resume in the circular file. You’ll be flipping burgers before you know it. Me? Cashing checks.
Mmm, no – many are still teaching these languages because they are still very widespread. There are still millions of Visual C++ and embedded applications out there that still need to be maintained, and guess what? No one is going to re-write them in C# and .Net
.
Wishful thinking. Go ahead. Contact some of the top CS schools in the country. I think you’re in for a surprise. They teach Java. Not C/C++.
There are still a lot of C/C++ applications out there that no one is going to re-write. Besides, don’t you know that C++ is still a development option in Windows programming? Why? Because for a lot of applications native code is still vital.
Fine. So you’re going to become known as “Maintenance Boy”. Enjoy your new title.
As usual, people like me will let you take the hype as far as it will go and then watch you fall as the hype fails to deliver. We’ve been through this with Java, you know?
Except Java delivers.
I will continue to use good, productive programming tools that enable me to write efficient code, and use a good environment (permissions, Unix/Linux desktop environment) and toolkit run it in that can do everything (and a heck of a lot more) a CLR environment is supposed to offer me. I never cease to be amazed by how much people by into this hype without looking at what they can do today.
Here’s a tip. I won’t even charge you for it. I don’t expect you to listen. Which is fine. Java and .NET are the predominant way that apps will be written in the next decade. Nearly all apps will be run within VMs — bytecode interpretation or emulation.
Another obvious trend. Programming is fast becoming a commodity, with jobs shipped overseas to guys who can turn cranks for a lot less $$$ than you and me. I could care less. I’m nearing retirement at the ripe old age of 40, with 20 years of C/C++ coding under my belt. I’m a convert to Java and .NET because I’ve seen what they can do, and I know that they deliver on their promises. Mono is just icing on the cake because it ensures that competition will prevail. If you get nothing else from this discussion, try learning a little instead of leaning so heavily on your over-inflated ego. You’ll be better off, in the long run.
There are still a lot of C/C++ applications out there that no one is going to re-write.
If you think that’s a good reason to keep saying “no no no” instead of keep up with the technology evolution, fine for me. There is too much competition for the good jobs anyway…
And then again, the Cobol guys at the back of the cafeteria are nice folks, as long as you like their fuzball tournments (they hate Playstation or XBox you see…)
“If you think that’s a good reason to keep saying “no no no” instead of keep up with the technology evolution, fine for me. There is too much competition for the good jobs anyway… ”
I think that what you’re forgetting isn’t that the programmer is saying “no no”, but their bosses. Please feel free to go into the mainframe room and start rewriting the code. You’ll find that there’s competition for your job, and it will not be the good kind (for you).
Technology’s nice (from the geek perspective). But from the business perspective it’s just another cost to add. So everyone’s going to have to give better reasons than “it’s kool”, or “because MS says so”.
Go to monster, dice, or any of the employment websites and do a search for Java/.NET jobs — and then do a search for C/C++ jobs.
That always happens with what people think are fashions. Pointing me to job sites doesn’t tell me what managed code can do, or what the supposed advantages are. Besides, most of these are agency jobs that in all probability don’t exist, just to make the situation look good. How old are you?
All I know is that I can code circles around you, if you’re writing C/C++ apps. So go ahead and fiddle around in your IDE, if it makes you happy. Meanwhile, I’ll be cashing checks.
Using a good C++ toolkit like Qt? Hardly.
VM-based apps are sandboxed. If they have bugs, they don’t crash the machine. They don’t violate fundamental system security. When YOUR native apps fail, you might as well dump the system in a FedEx mailer and send it to Russia or China.
Mmm, right. And you think sandboxing will save you? If you are using different components (especially within the OS), your application will still have an affect on them no matter what. Sandboxing will not save you here. Having a good desktop environment to run it within and good OS security very well might.
Wow. You’re making me choose between totally native and partially native. And this distinction is important because…?
You’re the one hyping managed code – not me.
Read for comprehension. I didn’t say the end of exploits. What I said was that low-hanging fruit (buffer overflows, etc) are going to be eliminated because of the VM sandboxing.
You think that if it gives you comfort
. It may well do in some circumstances, but not everything can run within a VM environment and it is only secure as the surrounding software – something you should have learnt with Windows.
Your code will be more buggy, hands-down. It’s the nature of C/C++ apps.
With a toolkit like Qt? Hardly.
Because everyone knows how well writing native apps has been for virus-writers, after all…
I think you’ll find that’s down to Windows security – or lack of it. The vast majority of viruses are scripts not native apps, which shows how little you do know. Even then, any native or sandboxed apps are only as secure as the security philosophy around them.
And this is the typical, ignorant Luddite programmer response from somebody who is resisting the pull of reality.
Ditto. Your understanding of viruses and security is a dead giveaway.
Too late. I work for one. We’re using our fair share of mainframes and legacy stuff — but the glue that binds much of it together is Java and .NET.
You don’t work in (or have ever been near) a large company. These companies have infrastructure that just cannot be replced on a whim. Some future stuff may well be .Net, as it is the programming architecture on Windows, but it is not going to replace all of the existing apps – there’s just too much critical stuff being used. Sorry!
If you aren’t using this stuff, you might as well put your resume in the circular file. You’ll be flipping burgers before you know it. Me? Cashing checks.
Yer, whatever. Given your understanding of Windows security and viruses, I’m extremely surprised you get anything done at all.
Wishful thinking. Go ahead. Contact some of the top CS schools in the country. I think you’re in for a surprise. They teach Java. Not C/C++.
It really doesn’t matter what they teach as a first language. Universities will still teach C++ because there are still tens of millions of C++ apps. You’re not quite grasping the fact that no one is going to re-write everything in .Net or Java.
Fine. So you’re going to become known as “Maintenance Boy”. Enjoy your new title.
That’s the reality in big organisations. Very little new stuff is being written. If you want to sift through tens of millions of lines of code, re-writing and doing maintenance then fine.
Except Java delivers.
Java has serious performance issues on clients which everyone knows about.
Which is fine. Java and .NET are the predominant way that apps will be written in the next decade. Nearly all apps will be run within VMs — bytecode interpretation or emulation.
Look – Java has been around for the best part of ten years. .Net has been around for four. Telling people that they are the future is a bit late now. .Net will be the pre-dominant way for future apps because it is tied to Windows, but that doesn’t alter the many millions that are already doing their job and won’t be re-written.
Most people twenty years younger than you have grown out of the “everything will be re-written in language X” phase. Why? Because it hasn’t happened.
I’m nearing retirement at the ripe old age of 40, with 20 years of C/C++ coding under my belt.
You ain’t been using a good enough toolkit, and you really should be old enough to know better. The virus comments were very bad – are you not familiar with how viruses work on Windows?
Mono is just icing on the cake because it ensures that competition will prevail.
Without some sort of Microsoft interoperability, then no, competition will not prevail. Windows is the dominant platform.
If you get nothing else from this discussion, try learning a little instead of leaning so heavily on your over-inflated ego. You’ll be better off, in the long run.
Ditto. You can talk about Java and .Net until you’re blue in the face, but the reality in the vast majority of organisations is a great deal more mundane. I would have thought that you may have realised that, but I never cease to be amazed.
And then again, the Cobol guys at the back of the cafeteria are nice folks, as long as you like their fuzball tournments (they hate Playstation or XBox you see…)
The Cobol guys keep your organization afloat and keep you in a job.