MonoDevelop vs. Xamarin Studio IDEs

[ciplogic]

I think we could argue whether the GC of Java and C# is a positive or not to kingdom come. Let us just let it rest by saying that it is a split decision.
Dynamic runtime with inline caching? Yeah, seen this argument before, and it probably helps performance of Java and C#. As you said though, if you really want performance, Qt and C++ is king, so I don't see it as a relevant argument in the big picture. Plugins go both ways. With Qt you easily hook into the KDE frameworks with things like kparts and dbus (assuming that you are OK with GPL of course, which I have a feeling you are not). I am a bit puzzled on the networking part, I have had no issues there. Use of sockets is very common and works fine in Qt, ref. http://www.qtforum.org/article/9/qt-...-tutorial.html Of course, you can always do the networking directly in C++ too, even on windows I believe C++ is even better supported by OS internals than C#. QtXml has worked out well for me, I have no idea what issues you have with it. Again, you can always do things directly in C++ if you need more flexibility than the Qt classes provide, but in my experience that is rarely an issue. (...)

.Net Remoting/WCF is the service I'm talking: the equivalents in Qt exist but are not as easy as .Net or Python world (to import for example a WSDL and proxies are generated automatically). In a similar note, the code to "dump" a class in Xml, is trivial, and takes a half of page of code because C# supports reflection, XElement and Linq (for example look into this link: http://blogs.microsoft.co.il/blogs/m...ting-data.aspx ).

I have no issues with Qt per-se, but the development cycle in C# is most of the times faster than the QMake cycle in Qt. If you can afford Resharper (or CodeRush) you will get static code analysis that warrants higher quality code.

About Qt and issues I faced:
- MSSQL uses a sub-par database driver (http://doc.qt.digia.com/stable/sql-driver.html)\
- also Qt is slower in calling signals than C# code and sometimes it has issues with thread safety: http://stackoverflow.com/questions/1...nd-performance
- if you use a Metacity Window Manager (at least in Qt 4.4 cycle) there were bugs in creating Windows. Qt was stested against KWM mostly (I had issues at my work regarding those issues)

About GC and if is to be desired: by default GC is a runtime service. It is similar with reflection. Are these features to be desired? If you don't use them, are not necessarily useful. If you are using them in an advanced way, you know that these features make your code maybe a bit slower (I say mostly about reflection, not about GC) but reduces the code of many algorithms. In fact GC can remove leaks in your code by running your program in stages (like the first step will process something in an intermediate representation, the second step takes this representation and does not reference the first). This can work with C++ "magic" like pools or such, but if you compare the code in C++ and C#, you will see that C# is certainly a better contender.

At the end, can you give a relevant case "when C++ saved you" because of its top-notch performance and C#/Mono would not bring this performance to you?

[Del_]

What Qt offers and Mono doesn't?
- if we talk about the runtime part, I can say that Mono offers more:
+ GC: simply means that you write simpler algorithms and you don't look for reference counted cycles
+ dynamic runtime with inline caching ( http://stackoverflow.com/a/7478557 ),
+ very easy to embed plugins (compare with the QtPlugin, or with dlopen/LoadLibrary mess),
+ a very easy way to do network remoting, Xml processing, class & fied annotations that can work with reflection to automate configuration in complex systems

I think we could argue whether the GC of Java and C# is a positive or not to kingdom come. Let us just let it rest by saying that it is a split decision.
Dynamic runtime with inline caching? Yeah, seen this argument before, and it probably helps performance of Java and C#. As you said though, if you really want performance, Qt and C++ is king, so I don't see it as a relevant argument in the big picture. Plugins go both ways. With Qt you easily hook into the KDE frameworks with things like kparts and dbus (assuming that you are OK with GPL of course, which I have a feeling you are not). I am a bit puzzled on the networking part, I have had no issues there. Use of sockets is very common and works fine in Qt, ref. http://www.qtforum.org/article/9/qt-...-tutorial.html Of course, you can always do the networking directly in C++ too, even on windows I believe C++ is even better supported by OS internals than C#. QtXml has worked out well for me, I have no idea what issues you have with it. Again, you can always do things directly in C++ if you need more flexibility than the Qt classes provide, but in my experience that is rarely an issue.

What Qt offers easily:
+ C++ integration with foreign codebases (that are old ones)
+ Two paradigms for controls: QWidget and Qml that are both working cross platform
+ arguably a bit better performance
PyQt offers most of Mono (excluding the toolkit part) with a performance hit if you don't use PyPy and no static checking (meanining performance hit and bugs in typing).

You are forgetting the wast value chain. Whenever I need something in Qt, somebody has already implemented it in KDE. The developer tools are top notch and work flawlessly on any platform. Generally speaking, if your coders are able, C++ is a safe bet. It can do anything competitively.

So Mono can be a Python like experience with a close(r) to C++ performance and with the choice to pick either dynamic (for weird runtime stuff) or fast static typing.

Something like that, but keep in mind that the Mono value chain is getting seriously crippled these days. You are loosing platform support for developers tools, and the most important platforms are getting proprietary with hefty licensing terms. This is OK for a company with large budgets, but it will chase away the small guys. It is the route of short term maximizing income. A trajectory that often has a less favorable outcome. Who is the main sponsors of Xamarin these days?

- Xamarin's policies: they support first the platforms that are paying money. In the same time though, they support Linux out of the box, and contributions in a generational GC are working both for phones (which are sensible on long GC pauses) and for desktops. As I'm an ex-Qt developer, I know that QtScript (which later was included as WebKit's JSC inside Qml) was a commercial product. (I talk for years 2005-2009). There were other integrations that Trollteck provide (like Visual Studio integration or QtJambi) that they were JUST for paid versions. How is one different for the other?

I have no problem with VS plugins costing money, I see that as a good way to get funding. VS is a proprietary product anyway, why shouldn't the plugin be proprietary? Complaining over this makes no sense to me. While linux certainly also drive commercial customers for Qt, do not underestimate the value of a vibrant community. An error I believe Xamarin is doing these days. Trolltech, Nokia and Digia are making mistakes, but as already mentioned, Qt is a very open project today and has been moving in the right direction. This thread is about Xamarin changing direction for the worse, into directions Qt never went. Xamarin's current policy does not align with Trolltech, Nokia nor Digia on Qt. If you are a Mono developer, you should be very concerned. If I were you, I would do what I could to make Xamarin change course. Just as licensing controversies over Qt has helped Qt staying on the right course. I see this as a very critical time for Xamarin. There has been controversies over Mono sure, but generally speaking I believe the open community welcomes projects like Wine and Mono, I certainly have, and I gladly spend my time helping Wine improve.

[ciplogic]

Qt, and if you don't need the performance or scale of a C++ project you can successfully do quick and dirty Qt+Python. I invest heavily in Qt, but do not dare to touch Mono. I have no disrespect for people who choose differently. I am grateful for the existence of Samba, Mono, NTFS-3G. When Miguel rejoiced by the hostile take over Microsoft did over Nokia (simply because it would force the world to embrace Silverlight), it made me sick to my stomach. If I misread the statements from Miguel at that time, then please correct me. Right now my thoughts and deepest sympathy goes out to the thousands of fins that lost their jobs because some investors wanted to secure their Microsoft stocks. Witnessing the ooxml tragedy play out in ISO made me want to cry. I really do appreciate the efforts from Calligra and LibreOffice in supporting ooxml though, deeply grateful. Xamarin leaving linux out in the cold for Android and IOS development, the very same platform that their existence was based on until quite recently. That makes me very very angry. Am I wrong in expecting a certain decency from a company?

What Qt offers and Mono doesn't?
- if we talk about the runtime part, I can say that Mono offers more:
+ GC: simply means that you write simpler algorithms and you don't look for reference counted cycles
+ dynamic runtime with inline caching ( http://stackoverflow.com/a/7478557 ),
+ very easy to embed plugins (compare with the QtPlugin, or with dlopen/LoadLibrary mess),
+ a very easy way to do network remoting, Xml processing, class & fied annotations that can work with reflection to automate configuration in complex systems
What Qt offers easily:
+ C++ integration with foreign codebases (that are old ones)
+ Two paradigms for controls: QWidget and Qml that are both working cross platform
+ arguably a bit better performance
PyQt offers most of Mono (excluding the toolkit part) with a performance hit if you don't use PyPy and no static checking (meanining performance hit and bugs in typing).

So Mono can be a Python like experience with a close(r) to C++ performance and with the choice to pick either dynamic (for weird runtime stuff) or fast static typing.

There are two more parts we may argue about:
- Miguel's statements: I'm not a pro-Miguel (or anti-Miguel) and I think that Office part he may be wrong. Anyway, this doesn't nullify his contributions to Midnight Commander, Gnumeric, Gnome (1 & 2), Mono or Novell. I use LibreOffice and I think that ODF is a better format per-se as it was done in a public way and forced MS Office to support it out of the box
- Xamarin's policies: they support first the platforms that are paying money. In the same time though, they support Linux out of the box, and contributions in a generational GC are working both for phones (which are sensible on long GC pauses) and for desktops. As I'm an ex-Qt developer, I know that QtScript (which later was included as WebKit's JSC inside Qml) was a commercial product. (I talk for years 2005-2009). There were other integrations that Trollteck provide (like Visual Studio integration or QtJambi) that they were JUST for paid versions. How is one different for the other?

Qt was more expensive than Visual Studio for a long time (it was like 1000 dollars, the lowest end edition) when if you want a one platform in Xamarin case, you pay "just" 400 dollars.

So to sum it up:
- Mono offers things that are productive enough to be used in Linux
- Miguel statements are his ones, and some of them are certainly wrong
- Xamarin policies aligns with Digia, Nokia or TrollTech as good/evil

[brosis]

directhex
ciplogic
jayrulez*

are pro-MS trojan infection in this forum.
Dear freedom lovers, don't argue with people who have no brains, its similar to arguing with a black hole.
Instead do what you usually do - ignore them, their platform, their products and their owners.

* new on the list.

Del_, Pawlerson, you are great guys.

[Del_]

So frankly: which solution do you consider is comparable in your development experience to MonoDevelop/C#?

Qt, and if you don't need the performance or scale of a C++ project you can successfully do quick and dirty Qt+Python. I invest heavily in Qt, but do not dare to touch Mono. I have no disrespect for people who choose differently. I am grateful for the existence of Samba, Mono, NTFS-3G. When Miguel rejoiced by the hostile take over Microsoft did over Nokia (simply because it would force the world to embrace Silverlight), it made me sick to my stomach. If I misread the statements from Miguel at that time, then please correct me. Right now my thoughts and deepest sympathy goes out to the thousands of fins that lost their jobs because some investors wanted to secure their Microsoft stocks. Witnessing the ooxml tragedy play out in ISO made me want to cry. I really do appreciate the efforts from Calligra and LibreOffice in supporting ooxml though, deeply grateful. Xamarin leaving linux out in the cold for Android and IOS development, the very same platform that their existence was based on until quite recently. That makes me very very angry. Am I wrong in expecting a certain decency from a company?

[ciplogic]

You're making me even more sad, because you're comparing mono to webkit and thus your comment makes no sense. Write webkit equivalent in mono or make it run on OpenCL and you're comment is against you. Btw. what my native broweser will use? Some monokit?

Seems that you're trolling. But it seems that you can agree that Apple can enforce patents (and they did it in the last 5 years against a Linux/Android for trivial patents in case of one company: HTC).

So, what it happens if a company implements Mono.SIMD and this company will submit into Mono, and later it retract it or is patent encumbered. Will stop you using Mono!? In which way? But the difference is that if this company is Xamarin, I don't know a situation when Xamarin to attack with patents. But comparing with Apple, we know that Apple had a bad track record about patents.

If your comment is about: which browser will be used on the phone? Safari (WebKit) on iOS, Chrome (or Mozilla's) on Android, WebKit or IExplore. Mono does not provide a browser control, but offers a way to embed it. Apple can block other browsers in iOS, but it cannot block (at least in current state) a compiled LLVM runtime. Kapish?

A runtime (like Mono) is in risks of patents as WebKit is. But Mono is a clean-room implementation of an open specification, so practically, it has less risks compared with a majoritary browser toolkit (I talk here about WebKit) to be destroyed by a patent war. Yes, I am sure that some patents can disable minimal functionality in Mono if some companies will want to attack Mono, but many parts of Mono (the important ones) are as immune to patents as Java or .Net is.

If WebKit will have a future clause that cannot be mixed with GPL projects supposedly, KDE will suffer much more than Mono projects will if Mono will have the same clause, and the reason is: .Net is open spec, and there are at least 2 implementations that support varies degrees of this specification: DotGNU and LLVM VmKit.

In rest, what can I say, this is my last response to people that do make storm in a teapot, with no valid arguments, no clean-cut parlance, and a form of zealotism. I am curious for our own Linux/GPL or whatever kind of freedom you think you represent, to live to your values and to show that these make Linux worth while. Like: you may say: Vala offers C# features and a Banshee implemented in Vala will start faster, run better... and right after you will show your project that does this. Talkers are everywere... people that do the work are hard to find. And after you work with Vala, let's say for 3 hours a day, you will maybe see that it doesn't worth 4 years of your life to clone a project in it and get back to common sense.

I need C# because my free time (and my working time too) is precious, I'm paid to deliver, and when I'm not paid, I want to deliever. Phylosophy and crazy people that believe that planets will align in December 21st will not my software work. So frankly: which solution do you consider is comparable in your development experience to MonoDevelop/C#?

[directhex]

I don't care and this doesn't matter. They get more attention and credit mostly goes to M$. Why do you expect I'll support anti Linux competition? It's dumb stupid. I recommend you to go to M$ and tell them they should drop c# crap and use Qt.

You're a moron.

I mean, I'd love to give a more detailed response than that, but you're literally too stupid to reason with.

Ridicule is the only weapon which can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them

[jayrulez]

No, we don't need this. If you don't know which companies are anti Linux then get out.



MS, because it brings MS tech which should be obvious. Why would MS pay Icaza to work on anti MS project that supports MS competition?



Wrong, strawman. When someone is using Samba he's forced to do so, because of MS.



It's c# that comes from MS. Furthermore, Icaza's MS jerk.



Said the guy who don't has a clue.

You're an idiot. Idiots cannot be reasoned with. Hence, I won't be wasting my time by replying to you from here on.

First, we would need a clear definition of "anti Linux companies".

No, we don't need this. If you don't know which companies are anti Linux then get out.

Does MONO serve MS or rather Linux?

MS, because it brings MS tech which should be obvious. Why would MS pay Icaza to work on anti MS project that supports MS competition?

Using Samba proliferates the use of MS APIs as much as Mono does.

Wrong, strawman. When someone is using Samba he's forced to do so, because of MS.

Mono does not come from MS or Apple either.

It's c# that comes from MS. Furthermore, Icaza's MS jerk.

Your statements are neither consistent nor coherent.

Said the guy who don't has a clue.

[Luke_Wolf]

The monodroid part (the old package) is not so actively developed (because is the wrapping part, that once done correctly you don't have to tune it over and over):
https://github.com/mono/monodroid-bindings
The runtime is still the same:
https://github.com/mono/mono

(there is nothing fancy in Android's port of Mono, look for user: spouliot that commits really often in MonoTouch or Mono for Android related fixes in the public repository)

As for actively maintained, I think it isn't. In fact for Google's NaCl, Mono port is really not such of a port, but are instructions how to patch Mono source and to do a cross-compile. Who knows, maybe Xamarin will offer someday a Mono for NaCl

well unfortunately it looks like the make file is broken, as it throws out an error about there being no rule to make "/src/Android.Support.V4.Content/CursorLoader.cs" which is needed by the bindings... so whatever, I'll stick to purely Qt for Android stuff for the time being then, and play around with C# for desktop applications and such...