|
Thanks to everyone who responded to my question. I am still a MONO outsider, but thanks to being pointed this direction by a fellow developer sharing the idea of the coming demise of Borland, I've had my eye on MONO since its emergence. I have poked my nose here now and then, and I usually try to learn all that I can from anyone working with MONO on any platform. The purpose of my question was both to gather critical career deciding information, and, if possible, to test (at least superficially) if there were any resistance to a proposal I would like to make. I thank everyone for the answers which were submitted, and hope I'll answer all replies sufficiently here. I will not take your valuable time with my own many reasons to hope it is finally the right time for an exodus from Microsoft. My story is probably shared many places, even if certain personal nightmares have been extreme. After all, the advent of .Net (together with disastrous, abusive Borland policy similar to what we expect from Microsoft), has just wiped out 12 years of intensive effort, and already I am quite unhappy with certain (especially performance) issues of .Net on Windows. Of course, coming from a C++Builder/Delphi background, I fully anticipated this from the additional environment and addition overhead. Nothing comes for free. But finding the severity of this performance step backward is not pleasant for me; and I do have an idea how I believe MONO can do much better. First of all, I too wholeheartedly support the open source operating system and development tools movements. I also salute the advent of C#, which largely meets my wish lists accumulated since the commercial availability of OOP tools. I am on the contrary relatively resistant to or skeptical of the implementation of COM/ActiveX across diverse unknown web applications. I believe it will be to the UNIX/Linux community's advantage if it rejects the whole body of .Net implementations that Microsoft is now concentrating on. What I would like to see is only approved executables running more or less permanently behind firewalls with only data transmitted between destinations, and with this processed however necessary by a minimal few plugins or built-in functions responsible for rendering. Especially if standards are agreed upon, this course also minimizes development (because we don't have to write rendering applications) while expediting ultimate performance (because only data traverses to the *existing*, ultimate application). In other words, I have thought from the beginning that the Microsoft philosophy is wrong. In fact knowing the weakness of accommodating unknown, interoperable objects well has permitted me on several systems to survive -- without ever deploying anti-viral ware -- literally probably more than a million Windows viruses, with none ever unleashing. The trick to this has been wholly disabling ActiveX -- whereas Microsoft's interests in .Net are making that more impossible every day. That much however is a small issue for me. I consider it no offense that others develop web applications with .Net components, believing to whatever degree satisfies them in available security; accepting the performance capabilities of this approach, and so forth. I wouldn't do that; and I wouldn't want to run a browser which supports the transmission, installation, and execution of any unknown executables myself, either. My Firefox installations for instance are always configured not to run _javascript_. Even as I occasionally approve some _javascript_ manually, I regularly object to much of its usage. It's plain unnecessary. But it is others' business if they do these things, and I do expect browsers to remain available which continue to provide means of eliminating potentially unwanted executability of any kind. The foreseeable problem we should consider nonetheless, is how dysfunctional these Microsoft "technologies" (approaches) will be on truly secure browsers of the future. This alone would discourage me from following that path of development. In my estimation therefore, it would be a resounding and extremely attractive reaction by the UNIX/Linux community if this seemingly extremely lax Microsoft philosophy met with wholesale rejection by everyone outside of Microsoft. This would send a message which itself could readily be interpreted by the suffering Microsoft masses to mean but one thing: Security? Or the wholesale lack thereof -- that is the question. Vocalizing this stark departure could be a final nail in the coffin (maybe an extra nail, aside the poor performance and extremely sad reliability of Vista). Security, optimal efficiency, and an enduring development path are principal reasons for this much of my proposition; but the most important aspects regard performance, and attracting potentially tremendously greater development activity from the Microsoft arena. First of all, the reasons I am here are easily summarized; and they are serious reasons. I cannot afford to compromise on them in any way if I do not have to; and in fact it is having to compromise which so far obstructs me from coming here. I would jump ship in half a heart beat however if MONO or any other tools took the form I am about to propose. In my quest to be able to go where I *really* want to go today (and wanted to go yesterday), I have a refined shopping list which I believe you will agree fits the bill better than Microsoft's approach. About myself, I will only say that I write 3rd party libraries, and have some hopefully important ones I would like to market, which I believe could change the landscape because they are a new, specialized kind of application prototype. I can't tell you more about that now, but I will try to summarize my issues so that you can respond to what I'm thinking as it may impact/benefit how you are using MONO now. Implemented as I intend, my proposal should negatively impact you in no way whatsoever, and positively impact your work in many important ways which I will leave to be obvious to you. Two points first; then my proposition: 1. I am substantially opposed to taking what seems to be a language leap backward to Objective-C. This isn't really that much of a big deal either, and this may ultimately be the way I elect to go. But if C# were the language of Cocoa, I would probably already be an OS X man, hopefully able to use C# as well to write Linux applications from the Mac. But there are greater reasons for my proposition than a C# Cocoa implementation itself would solve. 2. I come (at least since 1995) from a C++Builder/Delphi background, and believe I write code (for of course the things I do) that will run as fast as anyone's. In fact I regularly take rather extreme measures to achieve exceedingly fast execution. In developing 3rd party .Net libraries however, even with extreme designs for achieving optimal execution speed, I have found particularly that even relatively straightforward graphics processes are extremely poorly performant compared to the tools I recently left behind. In fact, certain things which are vital for me to do are already about to make me throw in the towel on .Net. In regard to this, I would like to submit: If the Microsoft platform is restricted to the present philosophies, and given the substantially inferior performance of Vista, I believe Microsoft can never thereafter compete with where I propose to go unless they adopt the same course. Moreover, I anticipate they will never do that, because it wholly conflicts with their restrictive, possessive business model. The last thing Microsoft has *ever* wanted is a two-way street to or from Microsoft. What I am about to propose therefore is such a 2-way street, but in particular, it would provide performance advantages far exceeding the potentials of the .Net implementation course Microsoft is wholly committed to. 3. So here is my proposition: What I don't understand is why MONO just *followed* Microsoft down the questionable path of Java. A principal purpose of .Net of course was to defeat Java because Microsoft was losing so many developers to Java, but not because Java was better than other object oriented alternatives such as Delphi or C++Builder. Of course, I readily concede that I believe it was a mistake to implement Delphi in Object Pascal. I would like to have seen Delphi retain the syntax of C. C# does this. Another reason I believe Microsoft followed Java is that Microsoft doesn't want to abandon it's greatest security risk -- ActiveX -- and, that because they will not do that, they will never understand how to build a secure OS. What sense does it make then for UNIX/Linux to follow this path, if it is even possible it opens the door to a diverse and prolific panorama of security issues all stemming from the unuseful/unnecessary exercise of making *unknown* objects capable of communicating with each other (often when they never have to), especially when this *also* (even in native compiled code) means a substantial step backward in performance? Adhering to a concept of transmitting only data between web applications wholly eliminates the need to follow the COM/ActiveX pattern. Moreover, eliminating this pattern was a substantial advantage of (pointer based) Delphi, which allowed Delphi to approximate the speed of native C++ executables and achieve ~ 7+ times the efficiency of earlier VB, which was COM based. Theoretically however, the C# (reference/handle based) approach is an equally advantageous way of building applications, if compiled into native executables. Assumably, abstracting support for the .Net libraries within an equivalent .Net environment running on Linux/UNIX is approximately the same thing as reorganizing that support so .Net code runs *NATIVE* on Linux/UNIX. In other words, the overhead of supporting native .Net executables running far faster than Windows counterparts running as IL is theoretically little different: Libraries, and their relationship to a compiler, are simply organized somewhat differently. Thus if engineers working with .Net implementations originally intended for Windows .Net could run the same code base, or even a restricted code base or roughly similar code base, as native executables on Linux/UNIX, obviously *that* is a place we *really* want to go today. Just something to think about, while millions of .Net developers can't even move to Vista without more problems than Win3.x. |
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
