The Mono Project: You Might Expect the Unexpected (Linux Journal)
The Mono Project: You Might Expect the Unexpected (Linux Journal)
Posted Oct 3, 2007 12:03 UTC (Wed) by chrislee (subscriber, #4460)In reply to: The Mono Project: You Might Expect the Unexpected (Linux Journal) by sylware
Parent article: The Mono Project: You Might Expect the Unexpected (Linux Journal)
I've done many projects over the past couple of decades in C, C++, Java, Python, Perl, Scheme, and dabbled in Ada, Haskell, Common Lisp, and other languages. I recently wrote a program in Mono/C#, and it was a terrific experience. Compared to C, Mono is bloated. Compared to Python, etc..., it doesn't seem bloated at all. I felt the libraries are better design than Java's, and I really love the new aspects of the language that are informed by functional programming.
I find really discouraging the nasty comments left about Mono at lwn and elsewhere, with lots of innuendo about patent problems, etc... (which I'm still waiting to see anyone address with specificity).
Please, if you have specific, substantiated concerns about Mono (legal, resource usage, etc...), I'd love to see them discussed and learn about them. Otherwise, please try to be more informed before posting, or think some more before engaging in FUD about a free software project.
Posted Oct 3, 2007 13:26 UTC (Wed)
by sylware (guest, #35259)
[Link] (1 responses)
Python/Ruby/Lua/Javascript... are dynamic, C#/Java are statically compiled, one of the reasons which make them already obsolete.
Posted Oct 4, 2007 16:56 UTC (Thu)
by butlerm (subscriber, #13312)
[Link]
Posted Oct 3, 2007 16:29 UTC (Wed)
by tony (guest, #3654)
[Link] (3 responses)
But, the few quibbles about the language aside, C# isn't a bad language. It has the conciseness of Java, the power of VB, and the execution speed of Python. As you point out, the libraries are cleaner than the Java equivelents.
Rather, the problem is in control.
As long as Microsoft is in control, the platform *will* be used against competitors. Microsoft has never *once* implemented a protocol without proprietary extensions aimed at lock-in. Not once. If they do that with truly open standards, what do you expect them to do with a de facto standard they control?
Make no mistake. This is a simply another attempt to gain control of the web, such as they tried with ActiveX. This attempt is better planned, building on the mistakes of ActiveX and their attempt to usurp control of Java.
Keep in mind the tale of the scorpion and the frog. (http://allaboutfrogs.org/stories/scorpion.html)
It's just Microsoft's nature.
Posted Oct 3, 2007 17:45 UTC (Wed)
by chrislee (subscriber, #4460)
[Link] (2 responses)
Could you link to these? I'm curious.
> But, the few quibbles about the language aside, C# isn't a bad language. It has the conciseness of Java, the power of VB, and the execution speed of Python.
Not to get into a protracted argument, but I don't think this is true. I find Java's verbosity has a lot to do with its 'Object fundamentalism', and explicit typing. C#'s lambda expressions short circuit a lot of this in my experience, and implicit typing solves much more, to make it concise enough for me. Haskell, for instance, is much better, but C# isn't bad for a typed language. Performance isn't like Python at all (http://shootout.alioth.debian.org/gp4/benchmark.php?test=..., do you have a better reference?). Also, I find startup time of the Mono VM is not a problem, as I worried about after using other VMs in the past. The power I missed when using Java was mostly functional programming constructs, but things are better in C#.
> Rather, the problem is in control.
In design of the language, VM, and libraries, I think MS has done well. If they wander off the reservation for some reason, I don't feel obligated to follow. I'm not running any of their code.
Posted Oct 3, 2007 18:57 UTC (Wed)
by tony (guest, #3654)
[Link] (1 responses)
That's poor design: a race condition *built into the language.*
The generics is more of a personal thing. I find when I profile C# code, bits written using generics are slower than bits written without. I've seen other people mention this (specifically in reference to JIT efficiency), but I can't find them after spending 30 seconds on Google.
As for my other points: that was a joke. I don't think it's that far off base, but it's still just a joke.
As far as the control:
You can choose Mono all you like. The masses will not, as long as it is not 100% compatible with .Net. And so web designers and application writers alike will target .Net, not Mono. And no matter how good Mono may be, any issues when using the web will result in users ditching non-MS operating systems in favor of MS-Windows.
Your personal choice has nothing to do with it. It is all about Microsoft trying once again to gain control of the web, to make sure that Linux or OSX don't work the same as MS-Windows when interacting with the web. It's about gutting "Web 2.0," and other emerging buzzwords.
What's the point of having a decent .Net implementation if nobody uses it?
As long as Microsoft has the upper hand, they will use it to our disadvantage. The worst part of Mono isn't that it's a direct implementation of .Net; it's that *we're giving Microsoft the upper hand,* knowing full well that Microsoft has no desire to co-exist.
.Net/Mono is a big wooden horse, and we're not even rapping the sides to see if it's hollow.
Posted Oct 12, 2007 9:29 UTC (Fri)
by llupus (guest, #20164)
[Link]
There is no such race condition built into the language, read the standard, it is available for free from ECMA.
"Compared to Python, etc..., it doesn't seem bloated at all"The Mono Project: You Might Expect the Unexpected (Linux Journal)
As long as you don't care about a 10x performance penalty...Performance
There are technical problems with C#, .Net, and Mono. First, there is the problem with a race condition when calling a delegate that could've easily been avoided. Then there's the performance problems with generics.Concerns
> There are technical problems with C#, .Net, and Mono. First, there is the problem with a race condition when calling a delegate that could've easily been avoided. Then there's the performance problems with generics.Concerns
The delegates problem is simple: between testing the existence of a delegate, and invoking a delegate (two lines of code), a second thread can remove the last item of that delegate, resulting in a NULL exception. So, to get around that, you have to create a mutex specifically for delegate access and create methods for adding or removing items from a delegate. Or, you can catch the exception and deal with it, taking the try/catch performance hit, and generally disposing of the exception anyway.More control
The delegates problem is simple: between testing the existence of a delegate, and invoking a delegate (two lines of code), a second thread can remove the last item of that delegate, resulting in a NULL exception.
[...]
That's poor design: a race condition *built into the language.*
More control