Page 17 of 32 FirstFirst ... 7151617181927 ... LastLast
Results 161 to 170 of 315

Thread: Why Mono Is Desirable For Linux

  1. #161
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by n3wu53r View Post
    Good for you! Ignore all the bullshit here. This is common on phoronix.
    But don't only develop on Mono. It is never good to rely on one language/framework.
    Also, have you tried C++ with Qt?
    You're incoherent:
    It is never good to rely on one language/framework.
    Also, have you tried C++ with Qt?
    Is it Qt a framework?
    According to Nokia (http://qt.nokia.com/ ) Qt is "Cross Platform Application and UI Framework"
    Does it need mostly C++ to work with Qt? Signals and Slots do not use Meta-Object-Compiler which is relying a lot of macro expansion. UI Compiler generates C++ code, isn't it? QMake itself make you more stuck on Qt world if you work with QTest and Tulip, its STL replacement.
    Which framework stuck you to work if you want to work with C#? WinForms? Why not using GTK#? ADO.NET? ADO is on top of many connectors including ODBC, native connectors. On top of it you can use Linq for SQL and/or Entity. You can even wrap the MySql or Postgress C API and make your own connectors. You can port even Sqlite in C#.
    Seems that your hate makes you out of touch of richness of .Net and Mono world, isn't it?
    Not sure if it's really on par with MonoDevelop (I haven't used either), but I've heard good things about Anjuta: http://projects.gnome.org/anjuta/
    Yes, I think that the closest to MonoDevelop is Anjuta. It is like MonoDevelop some years ago (features that Anjuta is missing are "little things" like refactors, database connectors, unit test suite integration, yet it has a great feature, namely the profiler). As for myself, maybe because As for me, the closest to VS, the best C/C++ IDE (that is not stuck with Qt) in Linux is Eclipse with CDT (which as the "rename refactoring") but CDT stagnated for many years, and this made it a bit outdated. I will try to give to Anjuta another shot, just for its' support for Vala.
    Last edited by ciplogic; 09-17-2012 at 12:30 PM.

  2. #162
    Join Date
    Jun 2009
    Posts
    1,168

    Default

    Quote Originally Posted by ciplogic View Post
    Is it Qt a framework?
    According to Nokia (http://qt.nokia.com/ ) Qt is "Cross Platform Application and UI Framework"
    Does it need mostly C++ to work with Qt? Signals and Slots do not use Meta-Object-Compiler which is relying a lot of macro expansion. UI Compiler generates C++ code, isn't it? QMake itself make you more stuck on Qt world if you work with QTest and Tulip, it's STL replacement.
    1.) QMake is just a Meta-Object expander and in no way restrict you to use only Qt, it only affect Qt MetaObjects nothing else
    2.) it works with C++/Python/Ada/mono[not sure is out of the box]/perl/ruby and many more http://en.wikipedia.org/wiki/Qt_%28f...rk%29#Bindings
    3.) it has bindings with a freaking lot of libraries too
    4.) the ui generator convert UI code[xml like] into bare Qt C++ and you can even generate it on console and just paste the code if you want
    5.) you can still use STL if you wish, this is C++ not mono LOL, infact many Kde apps use Boost alongside Qt
    6.) Qt render natively on each Os API it supports aero/gdi, X11/egl/Gl, Cocoa, etc
    7.) Qt is modular meaining you can use Qt Core and Qt GUI if you want to but instead of use QtSQL you can use postgresql C++ api directly if you wish to do so

  3. #163
    Join Date
    Oct 2011
    Posts
    225

    Default

    Quote Originally Posted by ciplogic View Post
    You're incoherent:

    Is it Qt a framework?
    According to Nokia (http://qt.nokia.com/ ) Qt is "Cross Platform Application and UI Framework"
    Does it need mostly C++ to work with Qt? Signals and Slots do not use Meta-Object-Compiler which is relying a lot of macro expansion. UI Compiler generates C++ code, isn't it? QMake itself make you more stuck on Qt world if you work with QTest and Tulip, its STL replacement.
    Which framework stuck you to work if you want to work with C#? WinForms? Why not using GTK#? ADO.NET? ADO is on top of many connectors including ODBC, native connectors. On top of it you can use Linq for SQL and/or Entity. You can even wrap the MySql or Postgress C API and make your own connectors. You can port even Sqlite in C#.
    Seems that your hate makes you out of touch of richness of .Net and Mono world, isn't it?
    You misunderstand.

    Did you not see my quote? I was responding to his statement about C and C++.
    but maintenance of code for every platform will take too much time and resources.
    I was asking if he tried Qt, because it helps a lot with that problem on C/C++.
    I never said he should replace mono with Qt.

    I fail to see how qmake sticks you to Qt. You can easily use cmake. Actually look at KDE. It's written with Qt but never uses qmake.

    You are comparing Qt to C#. Comparing a framework to a language. You should compare Qt to .NET and pure C++ to pure C#.

    I said it was never good to only rely on just one language too. You should know multiple things. This applies to Qt as well as Mono/C#/.NET



    Yes, I think that the closest to MonoDevelop is Anjuta. It is like MonoDevelop some years ago (features that Anjuta is missing are "little things" like refactors, database connectors, unit test suite integration, yet it has a great feature, namely the profiler). As for myself, maybe because As for me, the closest to VS, the best C/C++ IDE (that is not stuck with Qt) in Linux is Eclipse with CDT (which as the "rename refactoring") but CDT stagnated for many years, and this made it a bit outdated. I will try to give to Anjuta another shot, just for its' support for Vala.
    What do you mean best IDE that is not stuck with Qt. I use Qt Creator for non-qt stuff all the time. I don't even use qmake either, I use cmake.

    I ound CDT was really bloated and Code::Blocks and QtCreator better.

  4. #164
    Join Date
    Jun 2009
    Posts
    1,168

    Default

    Quote Originally Posted by n3wu53r View Post
    I said it was never good to only rely on just one language too. You should know multiple things. This applies to Qt as well as Mono/C#/.NET




    What do you mean best IDE that is not stuck with Qt. I use Qt Creator for non-qt stuff all the time. I don't even use qmake either, I use cmake.

    I ound CDT was really bloated and Code::Blocks and QtCreator better.
    he seems desperate to make mono/.NET to look like the holy grail of computing no matter how much FUD he has to spread

  5. #165
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by jrch2k8 View Post
    he seems desperate to make mono/.NET to look like the holy grail of computing no matter how much FUD he has to spread
    Hopefully you noticed that there was no FUD given by both directhex or myself. If we did, where? We did not define strawman arguments against Python (saying things like: "are you still using this thing with a global lock interpreter?") and the discussion was focused on the point.
    Also, hopefully you noticed that most Mono/.Net related people are more pragmatic. I was discussing using Mono with Gtk#, so I considered a proper user interface for Linux desktop, and at least in my experience, I noticed that it was a decent IDE for working with it. Also, I did not say by default anything against Qt, it was against the claim: use no Framework! then: Use Qt! (which is a framework)
    Holy grail of development? Nah! Most Mono "supporters" want Mono because they love C#. Vala people did too! They want it on Linux because they like the idea of Linux but they don't like Linux development per-se as tools. Some of people (myself included, I was a 2 years Qt/C++ developers, a lot more C++ without Qt) had experiences which were suboptimal on C++ side. We were there, we notice the good parts and the downfalls. I did not see any C# guy saying (regardless of their experience) any FUD about C++, wasn't it? Was I saying about Google GCC conspiracy that they want that Go succeeds, when key developers are paid by Google? Or maybe that Apple cares more about ObjectiveC than on C++, so C++ is a corporate driven dead end?
    Adding conspiracies is really easy, say a thing in a 60% true manner, and the last 40 % make it like if it would happen, will break all your future.
    If you noticed, I worked with C++/Eclipse CDT (most of my Linux experience, also a bit with KDevelop 3, in its glory time), I really got tired with gdb, with template errors, with code completion, leaks and so on that do not work.
    C# experience is obviously better, try it! It works similar with a Python one, but it runs faster.
    Qt experience is also good one, yet I found some bugs with it: at least in my real life experience with Qt 4.1-4.5 had bugs with XFCE window manager, which had to be patched (in a project I was working with) as it did not respond correctly with Realize event. It also had a bit worse layout engine than Gtk. QML has a good one, but at the time when I was a C++ developer it was not the case. Qt when worked, it was working better, but when it wasn't, everything was a mess. I also noticed that Qt got better with the latest releases, but still if the discussion was open, GtkMM gave to me a better experience (based on bugs in real and complex software) than Qt.
    At the end, all I wanted to say is this:
    - people that left C# for C++ or Python, I know why they did it. Also the ones that leave C++ for C#, I understand them too. I don't find it constructive for Linux software in general to miss any of the developers. Linux needs software: because users need software! Python software, C++ software, C# software, Ruby one, FreePascal/Lazarus one, and all others. If you restrict one platform, you reduce your changes to take an user will use Linux that will use that specific that is not ported, and the developer is afraid to port it on Linux, because it will be bullied later! Developers need tools and frameworks to be creative!
    - if you know that a tool is better as performance, memory footprint, and you want that, (re)write the tool to make a better world, if you think that your notes program is better served without Mono. If it will be better, why not? But don't be religious about it! Imagine in reverse, that you made other tool in Python, and some Mono fanatic will rewrite it in C#. Doesn't it sound insane to you?
    Last edited by ciplogic; 09-17-2012 at 04:20 PM.

  6. #166
    Join Date
    Jun 2010
    Posts
    219

    Default

    I was in a similar position to the first reply on this thread:
    This article is so backwards it blows my mind... I started out as a C# developer in the .NET 1.1(if I remember correctly) days. At one point, I realized that Windows was a sinking ship, and decided to learn Linux. Naturally, migrating my C# skills directly to Linux via Mono seemed like the thing to do. WRONG.
    .NET is a memory hog. We were deploying desktop monitoring software on a bunch of school workstations and mid sized dicts/arrays (~3000 elements) would instantly blow up the VM. The application development is so fast (not in a good way) that little to no attention is paid to the optimization of data structures. Everything is an expensively large object, and there's little you can do about this beyond capturing your constructor input and reproducing it when you actually need the data.


    Mono, is, was, and always will be a turd.
    The problem with Mono is, it doesn't really solve any problems, and that goes back to its roots: .NET. Anyone targeting .NET for anything more than a CLI frontend is either a naive startup, a masochist, an incompetent, or otherwise ignorant non-developer. Sure you get faster development, but that comes at a cost, the same cost as any other language where you skip the memory and performance optimization except you CANNOT FIX IT. "From zero lines to complete application in 20 minutes!" We all know where that goes!

    Second, the .NET API was never designed to be a multi-platform vehicle. It was designed specifically for Windows (hell- it wasn't even designed to carry Windows to other architectures, where it would potentially have real utility today), and thus any implementations of it have to map concepts that don't necessarily apply to other operating systems. It's always been designed, since day one, to get the developer hooked-on-Windows(TM) and stuck-on-x86. Anyone here care to dispute how much easier it is to port TO Windows than away from it? I think even the trolls know better!

    I won't even go over ASP.NET... Sure. Keep promising us that the patent trolls will never come, and that even if they come it wont matter. .NET is losing relevance, Windows is losing relevance, Microsoft is losing relevance. Until C# (and its mindshare) detaches itself from Microsoft and gives itself a Constitution / Bill of Rights it will never take off as a multiplatform language in any form.

    After giving up on Mono, I moved to C/C++ and Qt, and discovered that it is a comparable solution to .NET. Eventually I moved more towards writing web code in Python/Django, and desktop apps in Python/PyQT, and whenever I need extreme performance, I just port functionality to C and call it from Python. Vastly superior to C# on Windows or Linux.
    I think (we all) found a better solutions in Python, Ruby, PHP, C++ and multiplatform toolkits like Qt.

  7. #167
    Join Date
    Jun 2009
    Posts
    1,168

    Default

    [QUOTE=ciplogic;287439]I did not say by default anything against Qt, it was against the claim: use no Framework! then: Use Qt! (which is a framework)

    I really got tired with gdb, with template errors, with code completion, leaks and so on that do not work.

    C# experience is obviously better, try it! It works similar with a Python one, but it runs faster.

    Linux needs software: because users need software! Python software, C++ software, C# software, Ruby one, FreePascal/Lazarus one, and all others. If you restrict one platform, you reduce your changes to take an user will use /QUOTE]

    1.) ok can be interpreted that way, my bad
    2.) mmm that is typical from anyone that learned C++ in the old times or have too much time useing to high level language[not offending just saying is a common phenomenom], using modern techniques like pointer list is really rare to have memory leaks or null pointers, int he case of templates is common from C ppl that are used to massively long code chunks and very complex types[ struct inside an struct inside another struct that take structs as items which are nested struct] in C++ [any OOL] the smaller the better and the closer to the real types the better and in the case of high level language [it happens me sometime when i spent too much on python for example] is that you get sloppy with your classes cuz forgot C++ don't have garbage collector[take some sigsegv to come back to reality jajaja]
    3.) i did try it and never liked it and i don't considere it a good place to waste to time first cuz i don't like C# syntax that much and is a second class citizen compared to his big brother, miss multiplataform capabilities[sparc ARM power systems], in low power devices behave erraticaly for my needs, not easy to integrate in the web side of things[compared to php/python/perl] and i hate the garbage collector. For linux i trully believe a better solution would be python over LLVM, since python has a massive collection of API/bindings and massively tested and used from scripting to web services[same as perl <-- another good candidate].

    im not saying Mono should not be used since i can understand that if you already have a .NET app is easier to use just mono and get on with it and i don't discuss it can even be faster than in windows[i doubt it but feel free to prove me wrong], what im saying mono has no future as linux enviroment since is an alien enviroment born in windows when we have AAA+ tools like python and perl that just could use some pimp at VM level [llvm]to be as fast or faster than mono minimzing or killing any existant need for mono beyond a .NET runtime that run on linux.
    4.) very controversial since linux don't need 1 billion pieces of software in every fast food language out there like .NET, what we need is an standard project using common set of tools[c++,qt/gtk,pyhton for scripting comobo for example] and ppl in 10 different project that do the same crap to get togheter and make a damn good one, for example but well this is one of those topics where no one is right cuz depend too much of everyone POV

  8. #168
    Join Date
    Oct 2011
    Posts
    225

    Default

    Quote Originally Posted by ciplogic View Post
    use no Framework! then: Use Qt! (which is a framework)
    Bullshit.
    I never claimed that.

    I said do not rely on ONE framework ONLY as then you will be screwed if it goes away.

  9. #169
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by jrch2k8 View Post
    3.) i did try it and never liked it and i don't considere it a good place to waste to time first cuz i don't like C# syntax that much and is a second class citizen compared to his big brother, miss multiplataform capabilities[sparc ARM power systems], in low power devices behave erraticaly for my needs, not easy to integrate in the web side of things[compared to php/python/perl] and i hate the garbage collector. For linux i trully believe a better solution would be python over LLVM, since python has a massive collection of API/bindings and massively tested and used from scripting to web services[same as perl <-- another good candidate].

    im not saying Mono should not be used since i can understand that if you already have a .NET app is easier to use just mono and get on with it and i don't discuss it can even be faster than in windows[i doubt it but feel free to prove me wrong], what im saying mono has no future as linux enviroment since is an alien enviroment born in windows when we have AAA+ tools like python and perl that just could use some pimp at VM level [llvm]to be as fast or faster than mono minimzing or killing any existant need for mono beyond a .NET runtime that run on linux.
    4.) very controversial since linux don't need 1 billion pieces of software in every fast food language out there like .NET, what we need is an standard project using common set of tools[c++,qt/gtk,pyhton for scripting comobo for example] and ppl in 10 different project that do the same crap to get togheter and make a damn good one, for example but well this is one of those topics where no one is right cuz depend too much of everyone POV
    As for point 1 we both agree, and as point 2 is related with my life experience with C++, of course I agree that some people had another, where in a real project, people were more conscious, and leaks or a better environment to develop in.
    As my preference of C# maybe went in the time that C++ was for me a disappointment, going to your point 3, I can agree that C++ has some things that are better than in C#. The idea that templates are fully state machines so they really can compile formulae at compile time. I know that C# cannot do that. In this way is much powerful than generics. Also some symbols can be solved at linktime, so you can find some symbols "magically" as they are compiled for example as resources in a more transparent way than C# way. As resources, I don't only mean files, but also some code that you can run at startup, without being invoked lazily (the .Net behavior differs for this reason on singleton instantiation).
    At the end, why is an alien to Linux platform? I found that Mono in itself is a bit slower on math computations than .Net (by a little, if you don't use LLVM), but it integrates nicely with Gtk# (2.xx for now). I mean is better than for example GJS integration, or Python integration. Let me elaborate: if you call any method in Cairo, or OpenGL, if is mapped to a C type, most likely there is no copying or boxing/unboxing of the methods, so the performance penalty is certainly much smaller than any other mainstream language you can develop in Gnome (I include here: Python, Java, Ruby, JavaScript), isn't it?
    Point 4 I think makes no sense. If we would remove Mono and C#/VB.Net and some other .Net language supported (like my preference for Boo), there would still remain a lot of paradigms that are accessible in Linux. Emacs and Gimp use Lisp for 2 decades (at least), Haskell, Java languages (like Clojure or Scala), some research languages, Tex, all GCC ones (Go is the new kid in the block).
    Even C++ is multiparadigm, but if you work with Qt, you will likely work with the extension of Qt (signals+slots), JavaScript, QML, if you integrate QWebKit you will need to know Javascript, CSS, HTML5, maybe WebGL, and so forth, to not say anything about DDL/SQL.
    Languages will always appear, and what matters (in my opinion) is the mature implementation that a developer can target. As for me MonoDevelop offers some of the tooling (for Mono world), and also the closest sibling had virtually no traction (Java + Gtk) in Gnome desktop.
    There are languages which are really close(r) in Linux world: Ruby and Python, both in paradigms and in power (excluding that Ruby is slower ) but I do find that there is no need to remove one of them to "consolidate" Linux's web development platform.
    Python with LLVM better than Mono? Performance wise? Or at which level? Mono also have huge libraries, even you fully exclude the "Windows.Forms" support. From the REPL evaluator, that makes it close to Python (in dynamic ways), Xml processing, database processing, network, remote access, reflection etc. You can really find libraries for almost everything. Like in Python (or Ruby GEMs for that matter). What you can do in Mono is that you can write all your code using "dynamic" keyword, and if you need a higher performance you can put here and there some type annotations, and you bring performance in much closer terms with C/C++.

  10. #170
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by n3wu53r View Post
    Bullshit.
    I never claimed that.

    I said do not rely on ONE framework ONLY as then you will be screwed if it goes away.
    Let's reclaim your quote, shall we?
    Good for you! Ignore all the bullshit here. This is common on phoronix.
    But don't only develop on Mono. It is never good to rely on one language/framework.
    It logically follows that Mono is the one language/platforms, isn't it? If not, you should put at least in a separate paragraph, isn't so?
    If your behind logic is that you're screwed if the one platform goes away, I can say to you at least 4 projects having various levels of supporting the CLR virtual machine (all are here):
    - Microsoft
    - Mono
    - DotGNU
    - VMKit, a project of LLVM
    So, in case a nuclear bomb hit Redmond (never hope it happens) and because of that they attack with patents and kill Xamarin as a bussiness, there will be two half-baked implementations of CLR/.Net
    In balance, let's take Qt, how many vendors support it?
    - it was Nokia
    - it is Digia now
    What if Digia discontinue Qt, how many alternative Qt implementations do you have?
    Based on raw numbers, I will pick Mono and .Net over Qt, seems much more safer, isn't so?
    Edit: Some clarification: I mean that you can develop more safer if are more implementations. And as Mono is supported itself in more platforms, if a platform is blocked (for example Android, or Mono itself, you will not lose all your code tomorrow), you have just likely to rewrite UI code. If Mono will be stuck, you still will have the some code alive. Qt offers even less warranties, excluding you target Nokia's Symbian or Meego, I don't see any other target where Qt keeps you safe(r) to sleep than Mono and his support as .Net. And eventually DotGNU and VMKit will still give a chance to use your code even if both Microsoft and Xamarin would disappear (if it would be still some interest in C# in 20 years from now)
    Last edited by ciplogic; 09-17-2012 at 08:58 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •