tag:blogger.com,1999:blog-203063759820106893.post6011814930271075320..comments2023-03-25T08:30:26.602-04:00Comments on A Moment of Zen: Mono not Chasing Tail LightsJeffrey Stedfasthttp://www.blogger.com/profile/12271561115384429651noreply@blogger.comBlogger63125tag:blogger.com,1999:blog-203063759820106893.post-81061608671616334552010-04-22T23:50:45.799-04:002010-04-22T23:50:45.799-04:00V interesting
C++ and C are so unproductive...
I...V interesting <br /><br />C++ and C are so unproductive...<br />I have returned to Unix after a 10 year absense and was VERY disapointed with the lack of progress . It seems more difficult and painfull before while C# and windows is far easier. <br /><br />Anyway i was building a C# based OS form the ground up ( See Mosa /Cosmos) but am now using ucLinux and Mono and will convert drivers and services to C# ( even if just wrappers) . Note the key to this OS is NO C or C++ apps only typesafe and memory safe languages are useable in return there are significant benefits. <br /><br /><a href="http://www.shanghai-software.com/blog/category/23.aspx" rel="nofollow"> Mono based OS SOOOS</a><br /><br />To the person who said C# is tedious he must not have used C++ or Java. Though i agree it is tedious compared to afunctional language like oCaml but you CAN run F# under Mono.Unknownhttps://www.blogger.com/profile/02716067954664706530noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-28166154334555690502010-03-08T17:57:50.486-05:002010-03-08T17:57:50.486-05:00Alberto:
The problems had nothing to do with Gtk+...Alberto:<br /><br />The problems had nothing to do with Gtk+. They were just annoyances in the way C++ does things differently from C.<br /><br />As far as our successes... well, we've had well over 600,000 downloads of Moonlight alone in the past 3 months. There are top-selling video games written entirely in Mono (and more to come). Banshee is amazing. MonoDevelop is amazing. GNOME-Do is amazing. Tomboy is so good, people forked it just to do a line-by-line port to C++. MonoTouch is selling like hotcakes and a lot of iPhone apps are now written using it and it is in demand for Android as well.<br /><br />A lot of .NET apps written for Windows are also happily running on Linux thanks to Mono, you don't see these successes because often they are apps that are internal to companies and are not ever made public.<br /><br />I wish I could tell you all about the numerous things written in Mono that I'm sure you use every single day but don't realize it's written in Mono, but unfortunately we have agreements with those software and hardware vendors not to disclose that information.<br /><br />But even given just the publicly available information on what is written in Mono / using Mono, it's unbelievable that you don't see it as a success.Jeffrey Stedfasthttps://www.blogger.com/profile/12271561115384429651noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-62911342775717769842010-03-08T15:44:03.922-05:002010-03-08T15:44:03.922-05:00Hi, I'm not against mono, and I think you'...Hi, I'm not against mono, and I think you're doing a very good job, but I also think some more accurate statement would help your cause.<br /><br />- What were the problems in C++ you did not have in C? Were their related to GTK bindings? Because it would not be a surprise given the status of GTK code, which has nothing to do with C++ or whatever language, but with the quality of the toolkit.<br /><br />- "we are succeeding" seems a very strong statement. Succeeding in what? Where are the examples and the details? Any major project, not sponsored by Novell, switched to Mono and ported desktop applications to the linux desktop that previously were Windows only?Unknownhttps://www.blogger.com/profile/09977603983744700748noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-15741410123695256002009-09-29T13:10:27.296-04:002009-09-29T13:10:27.296-04:00I'm a Windows/Mainframe/Java guy who wanted to...I'm a Windows/Mainframe/Java guy who wanted to play around with C# & F# on his Mac. I am astounded at how great Mono is. Everything just works. Mono is a bridge from what I was doing to what I want to learn to do. Thanks.Greghttps://www.blogger.com/profile/16607807019287355365noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-56553338863862548292009-09-29T08:56:03.631-04:002009-09-29T08:56:03.631-04:00Stephen: C++ is so huge that it is impossible to k...Stephen: C++ is so huge that it is impossible to know it all. C is much much smaller and therefor much much easier to fully know the language.<br /><br />Many large scale projects that are written in C++ have rules about which parts of the C++ language spec you can use. Partially this is because of incompatibilities with certain compilers, but it's also because some aspects of the C++ language get very confusing very quickly.<br /><br />C# is starting to suffer from this problem a little too (imho), but not nearly as bad as C++ atm.<br /><br />Then you have subtle differences between C and C++ that makes things annoying for people with a C background (like myself and many other GNOME devs).<br /><br />If you are just writing your own little program in C++ and stick to the parts of C++ that you are comfortable with, it's fine. But as soon as you start getting a bunch of contributors all with varying degrees of understanding of the C++ language and all using random features of the language, you'll find the project's code to get very complicated to read and understand. At least that's been my experience.Jeffrey Stedfasthttps://www.blogger.com/profile/12271561115384429651noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-79509348836352261992009-09-29T06:06:55.802-04:002009-09-29T06:06:55.802-04:00I have nothing against C# (in fact, I spend more t...I have nothing against C# (in fact, I spend more than half my time at work coding with it), but I really fail to see how anybody could find C++ a 'pain in the ass' to work with... I prefer it, really - it's clean, efficient and fast, and the new TR1 extensions make it even easier than it used to be. That is, as long as you use nice APIs like Cairomm and Gtkmm - MFC and the like are really not fun to code with.Unknownhttps://www.blogger.com/profile/04654792323872100761noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-25833273069231280542009-09-28T23:06:03.326-04:002009-09-28T23:06:03.326-04:00Very cool article, thanks!Very cool article, thanks!John Currahhttps://www.blogger.com/profile/06080865181689496186noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-53959383768267103822009-09-28T18:23:48.867-04:002009-09-28T18:23:48.867-04:00*Is to use a single Mono VM and load each applicat...*Is to use a single Mono VM and load each application into an AppDomain (which is part of .NET) instead of running a new VM process per application. AFAIK, this should work.*<br /><br />Correct, but in this case you're effectively reinventing the wheel: the OS kernel is that piece who manages "application domains". As far as I know, Android works in a similar way - only one instance of customized Google JVM manages multiple Java applications.<br /><br />I am preaching for a good VM team to merge with Linux kernel to achieve precisely the same goal. This would trully be awesome: a garbage-collecting OS kernel with a built-in caching JIT compiler.<br /><br />This would give me ability to use modern languages and still adhere to UNIX philosophy of small, fast-launching, efficient specialized executables.<br /><br />I woudl *love* to hear from Miguel and Linus on this. I know it's easy for me to *want* things, but it's much harder for you guys to actually make it happen. Well, kidos for trying!Eugueny Kontsevoyhttps://www.blogger.com/profile/10637713202712446933noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-44223824552281790072009-09-28T18:13:32.212-04:002009-09-28T18:13:32.212-04:00Eugeney: Miguel (aka mdi) would know better, but I...Eugeney: Miguel (aka mdi) would know better, but I suspect that the way you can get around loading the same code/data 20 times (without the need for AOT) is to use a single Mono VM and load each application into an AppDomain (which is part of .NET) instead of running a new VM process per application.<br /><br />AFAIK, this should work.Jeffrey Stedfasthttps://www.blogger.com/profile/12271561115384429651noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-88081968063388174302009-09-28T18:11:41.394-04:002009-09-28T18:11:41.394-04:00Benoit: I no longer work on Evolution, but that so...Benoit: I no longer work on Evolution, but that sounds like a reasonable feature request that you should submit to GNOME's bugzilla if it's not already there.Jeffrey Stedfasthttps://www.blogger.com/profile/12271561115384429651noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-31844590012723933162009-09-28T17:38:25.327-04:002009-09-28T17:38:25.327-04:00Nice writeup, Sean
Hard to disagree with you anyw...Nice writeup, Sean<br /><br />Hard to disagree with you anywhere, great arguments!<br /><br />But on a practical note, I look at Tomboy, which I expect to launch instantly, but it doesn't. It does very little, it is by far the smallest application I am running (not counting Gnome panel applets),<br />yet it consumes more RAM than Gvim, Nautilus or even Evolution!<br /><br />The reason? Shared libraries. Tomboy is a mongrel here, excluded from the Gnome party. <br />All gnome apps (just like OSX Cocoa apps or Microsoft ones) happily reuse the same runtime, loading very little additional code, very quickly.<br /><br />Programs written in their own VMs feel *exactly* like that: like little virtual computers that you need to boot up prior to using. I have been waiting since 99 for this feeling to disappear, but somehow gigabytes of RAM and gigahertz do not help, with Java this feel of "booting" applications <br />only got worse over time.<br /><br />Do not get me wrong: I don't advocate going back to C/Glib. I spent nearly 10 years programming in C++/MFC on Windows. DO NOT WANT THAT. <br /><br />I am just publicly wondering how come VM implementors are so obsessed with producing "faster than C" benchmarks and fiercely defending their VMs and JIT compilers in regards to CPU performance, yet the question of "virtual computer feel" and outrageous RAM appetites comes up very rarely, yet this is by far #1 reason why VM-based software got stuck in datacenters.<br /><br />Why can't Linux memory manager be integrated with JVM or Mono VM? Why do we have two layers of "free/used" counters operating ignoring each other, when you can't even tell how much RAM you're using? <br />Seriously, RAM consumption measurement is something of a black art for no reason. And, again, it prevents VM-based processes from effectively sharing read-only memory pages. Imagine a Linux desktop with 20 processes written in "Mono Proper" - they'll all have their libraries hosted 20 times at different locations, re-filling CPU caches with exact same stuff - that's an example of systemic optimisation which screams <br />to be applied: when I launch a 2nd version of a Mono app it needs to start up in 0 (zero) time and eat close to 0 (zero) bytes of RAM for its code, <br />because it's already there.<br /><br />Language VMs should be implemented not by complier/library writers but by OS kernel developers.Eugueny Kontsevoyhttps://www.blogger.com/profile/10637713202712446933noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-83001414212135641772009-09-28T17:36:08.281-04:002009-09-28T17:36:08.281-04:00Minimize to tray, then? ;) Keep up the good workMinimize to tray, then? ;) Keep up the good workAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-73310185228182782222009-09-28T17:35:06.045-04:002009-09-28T17:35:06.045-04:00Benoit: there are no plans to rewrite Evolution in...Benoit: there are no plans to rewrite Evolution in Mono - it would be a huge (expensive) undertaking and likely not worth the effort.Jeffrey Stedfasthttps://www.blogger.com/profile/12271561115384429651noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-5581943947402538922009-09-28T17:32:41.783-04:002009-09-28T17:32:41.783-04:00Quick question about Evolution: are there plans to...Quick question about Evolution: are there plans to port and/or rewrite/redesign Evolution on top of Mono? Evolution is the competent Mail/Calendar/etc client in Linux land to me, but it simply feels HUGE and doesn't do a couple of things I'd like (minimize to tray!)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-43953434497509366652009-09-28T17:19:34.146-04:002009-09-28T17:19:34.146-04:00Sean: Thanks for your comments explaining what you...Sean: Thanks for your comments explaining what you meant.<br /><br />Awesome, awesome info.Jeffrey Stedfasthttps://www.blogger.com/profile/12271561115384429651noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-81693698937399343082009-09-28T17:15:29.140-04:002009-09-28T17:15:29.140-04:00shevegen: huh??? You do realize what he was saying...shevegen: huh??? You do realize what he was saying is that the Python language grows organically.<br /><br />That's not Python bashing. There are good and bad things about that.<br /><br />I swear, some people are *looking* for any excuse they can find to hate Mono and label people who like Mono as Python haters or something. This simply is not the case.Jeffrey Stedfasthttps://www.blogger.com/profile/12271561115384429651noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-76289517336799969512009-09-28T17:09:55.058-04:002009-09-28T17:09:55.058-04:00(continued -- I ramble, and the blog has a low pos...(continued -- I ramble, and the blog has a low post length limit)<br /><br />Elitists like to think of C and C++ as superior (or in many cases, they only think of C as superior) because it forces the programmer to think about every last little thing he does. Since the programmer has to hand write every damn tree or list or other data structure, the thought is that the programmer will make better choices and implement the proper data structures. This is total bullshit, of course. The programmers who can't figure out which pre-written data structure to use can't figure out which data structure to write by hand, and they're the same kinds of programmers that couldn't hand-write a decent implementation anyway.<br /><br />Most of those C/C++ performance fanatics out there don't know a fucking single thing about modern performance and optimization. I still run into a ton of people that actually preach "performance" tricks that HURT on modern computers far more than they help. I had a classmate who wrote pre-calculated tables of sines, cosines, and tangents, because hey that's how id did it when they made Wolfenstein run at amazing frame rates when Ultima Underworld still dragged ass on the same hardware. Lo and behold, though, a modern CPU can just calculate a sine faster than it can pull the value out of even L2 cache.<br /><br />Then of course people learn the "memory is slow" thing and start doing -everything- in the CPU and avoid memory use like the plague, and end up writing slower code.<br /><br />The real professionals -- the one who actually know what they're doing -- will all say the same thing: the compiler is smarter than you, the compiler can optimize better than you, and everything you think you know about performance is wrong. When you write "high performance" code in C/C++ you _have_ to profile the hell out of it, verify your assumptions, and then go back and fix most of your optimizations because most of them either don't help as much as you thought they did or actually hurt performance.<br /><br />A good VM takes that to the next level. Higher level languages allow the compiler to have more information and make more informed decisions. Good VMs can optimize at runtime with data that a C/C++ programmer can only have with countless hours of profiling and tweaking. Good VMs can optimize based on actual circumstance in ways that even the best profile-guarded optimization could never possibly do, e.g. optimize the code for the specific CPU architecture in use.<br /><br />It's the same as how modern GPUs work. Applications don't ship pre-compiled GPU machine code for their shaders. They ship raw shader source. The driver takes that source and can optimize it for the exact GPU hardware in use. Driver updates mean that the shaders can get faster without having to upgrade hardware and without having to recompile the whole game.<br /><br />That said, you can look back to toto's comments about tiny embedded real-time platforms. Those are entirely different beasts. You aren't even actually concerned about __performance__ on those machines. You're concerned about entirely different issues. Maximum code size. Latency. The fact that the platform doesn't even have a C# runtime support. Apples and oranges.<br /><br />Mono, C#, CLR, C, C++, Python... none of these are perfect. Every single platform has strengths and weaknesses. There are many contexts that I refuse to even think about using Mono. There are contexts where I think Python (a language I generally dislike) is most ideal. There are times I truly love working in C++ and times that I despise the language.<br /><br />Only an idiot hates a given tool for irrational reasons, but only an idiot senselessly advocates the use of a single tool for every circumstance.Seanhttps://www.blogger.com/profile/10334329646326596833noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-43846647627543454692009-09-28T17:06:55.653-04:002009-09-28T17:06:55.653-04:00Up until this very post here you wrote, I liked mo...Up until this very post here you wrote, I liked mono.<br /><br />But I saw that some other guy attacked python with "making shit up as it " goes while at the same time praising Mono.<br /><br />If this is the prevalent view of mono, then I can avoid it happily.shevyhttps://www.blogger.com/profile/09636171104216432368noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-19210288692137866372009-09-28T17:03:11.709-04:002009-09-28T17:03:11.709-04:00Jeffrey, look at this mess of comments. That'...Jeffrey, look at this mess of comments. That'll teach you to repost one of my half-drunken forum comments to your blog. ;) (Yeah, this is elanthis.)<br /><br />So far as toto's comments, I think you nailed most of it, but I feel like clarifying further. For the majority of use cases, VM technology is quickly approaching and will soon be surpassing C/C++ performance. "Performance" is not equivalent in all cases. I am starting work in the video game industry. We care about performance a lot. Take all the fancy algorithms the rest of CS community pats themselves on the back for pulling off, and do them all many thousands of time per frame at 60 frames per second. That's what we do.<br /><br />A lot of (irrational) game developers still use C exclusively because they're afraid of the overhead of C++ virtual function calls. These same dummies go and write their own tables of function pointers and think their implementation is magically faster than the C++ compiler's, naturally. Worst of all for both their employees and their end users, however, is that working in C almost forces you to concentrate on micro-optimizations instead of systemic optimizations.<br /><br />Well-written, high-performance, A-list game engines these days do so many "inefficient" things that make us old-school developers cringe (omg they're copying strings all over instead of using statically assigned numeric ids!?), and yet the modern game engines not only can do so much more than the old game engines, they are faster on modern hardware than the old game engines are on the same machines!<br /><br />That's where things like VMs and languages like C# come in. They're not there _quite_ yet, but they're close enough that you can get away with implementing an entire engine in C# and have it perform good enough for moderately graphics-intensive games. Give it a few more years when currently experimental technologies become mainstream, and a VM like the CLR will be able to generate JIT-compiled code that outperforms any possible AOT compiled code, because it will be able to do all those micro-optimizations for you on a whole-system level.<br /><br />Meanwhile, the developer is freed up to focus on system design and systemic performance, which produces overall more efficient engines.Seanhttps://www.blogger.com/profile/10334329646326596833noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-68986708743149937802009-09-28T16:46:47.784-04:002009-09-28T16:46:47.784-04:00TGM: it's not that Mono is not meant to *also*...TGM: it's not that Mono is not meant to *also* be compatible, it's just not the only purpose.<br /><br />Being compatible with Microsoft's implementation has many added benefits, but if Microsoft goes in a direction that we don't want to go, we won't follow.<br /><br />Windows.Forms is a meant as an aid to developers that want to get their Windows.Forms apps to run on multiple platforms.<br /><br />For developers writing new applications, we suggest using Gtk# or else a different UI for each platform.Jeffrey Stedfasthttps://www.blogger.com/profile/12271561115384429651noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-77013405426960305112009-09-28T14:45:30.535-04:002009-09-28T14:45:30.535-04:00If mono was never meant to be CLR compatible... Wh...If mono was never meant to be CLR compatible... Who wrote the winforms layer?<br /><br />That said I'm aware of the Gtk# components and will be watching the debate carefully, whilst learning c++ to sit next to my c# and python :)TGMhttps://www.blogger.com/profile/06100386595859765185noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-26744548186250435162009-09-28T12:56:25.687-04:002009-09-28T12:56:25.687-04:00For code sharing across multiple processes you nee...For code sharing across multiple processes you need to use Mono's AOT compilation.<br /><br />What this does is generate shareable code (it is pretty much a variation of ELF) that multiple processes can run.<br /><br />This is done doing:<br /><br />mono --aot foo.dll<br /><br />Miguel.mdihttps://www.blogger.com/profile/11428205606558379989noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-44662483618876705252009-09-28T12:55:03.069-04:002009-09-28T12:55:03.069-04:00The source of our disagreements (Richard and mysel...The source of our disagreements (Richard and myself) comes from his campaign to regain credit for Linux.<br /><br />It was OK for a while, until it completely dominated any of his actions.<br /><br />14 days before launching the Mono project, the board of directors of Ximian allowed me to talk to a few people in advance about our plans, only if they agreed to keep this a secret until the launch.<br /><br />Richard agreed to keep the announcement secret and to not talk about it until we had done our press release. <br /><br />But he did not keep his word. On Monday, our press release was going to come out at noon or so (a time that we had told everyone that had been pre-briefed).<br /><br />The FSF on the other hand decided to come out with its *own* press release announcing the launch of "GNU/Mono" and "DotGNU".<br /><br />A carefully planned press announcement was ruined by Richard's announcement.<br /><br />Hence any further communication with Richard from the Ximian board was suspended. The man could not be trusted to keep a secret even when he had agreed and he was too thirsty to stick "GNU" in front of any new projects.<br /><br />Since this incident I barely talked to Richard and dismissed his continuous requests to "contact XXX and tell him to say GNU/Linux instead of Linux".<br /><br />Ximian released the Connector in December, the board incident would not take place until February.<br /><br />Richard might want to rewrite history all he wants, but our communications effectively had ended after his actions with Mono.<br /><br />Miguel.mdihttps://www.blogger.com/profile/11428205606558379989noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-63189793121325458032009-09-28T12:50:18.998-04:002009-09-28T12:50:18.998-04:00One could make the argument that Stallman and the ...One could make the argument that Stallman and the GNU project were 'chasing the taillights' of the commercial Unix vendors of the time as well. I don't really see any difference and there's certainly nothing wrong with trying to provide a free implementation of a popular platform.Krishttps://www.blogger.com/profile/00057222251590200359noreply@blogger.comtag:blogger.com,1999:blog-203063759820106893.post-72576370873948830712009-09-28T11:45:56.849-04:002009-09-28T11:45:56.849-04:00C.T.: Well, yes, everything still gets translated ...C.T.: Well, yes, everything still gets translated into machine code in the end, but the problem is with dynamic code generation.<br /><br />The current natively compiled languages are not good at dynamically generating new code at runtime which is where the problem exists.Jeffrey Stedfasthttps://www.blogger.com/profile/12271561115384429651noreply@blogger.com