Submitted by The first major effect of Attachmate buying Novell (and thus, SUSE) has come into, uh, effect. Novell, of course, is the birth place of Mono, the open source implementation of Microsoft’s .NET framework. Reports indicate Mono developers have been fired as part of the streamlining process, but according to Attachmate’s CEO, they weren’t fired because of Mono.
At this point, it’s unclear as to if everyone has been fired, or only a few. Michael Larabel reports that 30 Mono developers have been let go, but I’m not exactly sure how many developers were actually working on Mono in the first place for Novell. While it’s tempting to assume that Attachmate is letting these people go because it doesn’t see a future in Mono, reality is a little different. Attachmate CEO Jeff Hawn has told InternetNews that it’s all part of a reorganisation.
“We have re-established Nuremburg as the headquarters of our SUSE business unit and the prioritization and resourcing of certain development efforts – including Mono – will now be determined by the business unit leaders there,” he said, “This change led to the release of some US based employees today. As previously stated, all technology roadmaps remain intact with resources being added to those in a manner commensurate with customer demand.”
In other words, it’s not that Attachmate sees no value in Mono – it’s that it sees no value in having developers in the United States while the SUSE business’ headquarters are located in Germany. Hawn provides no insight into how many employees have been let go, and it would seem that no Mono developers have been let go in Europe – if there even are Mono developers to be let go here.
Mono, of course, has always been a controversial project. It implements several technologies patented by Microsoft, and as such, has been shunned by many Linux distributions. I personally used to have ‘don’t worry, be happy’ approach to Mono, but since the recent patent litigation explosion, I’ve become a lot more cynical regarding the project. It would be understandable if Attachmate wanted to kill their involvement with Mono out of fear of possible patent litigation, but it would seem that isn’t the case at this point.
So, I’ve read this now on a couple news sites…
It sounds like only the U.S. Mono devs were let go?
That means they’re not ending Mono, but they’re moving the project out of the U.S. and will likely hire new resources elsewhere to work on it?
SUSE’s going back to Nuremburg, perhaps they’re moving the Mono development there
Probably, Mono and Moonlight are not being used much by Linux enterprise server service.
I like know on how much Mono has implemented with respected to .NET 4.0 and Moonlight has implemented SilverLight 4.
Can we watch Netflix movies with Moonlight ? If not Moonlight community should address those shortcomings first !!
I’ve tried Moonlight, and never got it to work properly with anything (except maybe some tests designed specifically for it). It’s a waste of time.
Of course, whenever stating something based on the past, the future comes around swiftly and ruins everything. I visited a page with a Silverlight video today, and Moonlight asked to download some codecs from Microsoft, which it then did and asked me to reload the page. Video played back smoothly. Then tested a different page, and it worked fine there as well. In fullscreen, it’s much, much smoother than Flash on my computer (which is to say that Flash is still utter shit for video on Linux).
Regarding netflix, one can hardly blame them for not implementing proprietary microsoft drm.
Microsoft will never allow moonlight to work with netflix and microsoft drm
Back to Mexico for Miguel de Icaza.
Are you kidding? (though your message can be extremely innocent [if you are a mexican guy], it can also be extremely xenophobic).
I think that if Miguel de Icaza would be fired, he would be hired the next day or he would have a lot of job offers in his mailbox.
Miguel can return to Mexico, but he can stay in the US, move to Europe or Asia or wherever he wants to be.
The article says that it’s possible that Miguel might get picked up by Microsoft. Admittedly, the author has no way of knowing. But it’s not too far of a reach to say that Miguel has always dreamed of working for Microsoft. We should be happy for him should his dream come true… even if it did take a lot of undercover work on his part, infiltrating the OSS community, and all that.
I’m with you on that
Yankee go home.
http://www.zdnet.com/blog/open-source/is-mono-dead-is-novell-dying/…
“We have re-established Nuremburg as the headquarters of our SUSE business unit and the prioritization and resourcing of certain development efforts – including Mono – will now be determined by the business unit leaders there,” he said…
So then… it’s a “Nuremburg trial” of sorts?
Thanks folks, I’ll be here all week!
You don’t need to worry about MS patents and Mono. Novell signed an agreement with Microsoft a few years ago which grants them the right to use MS patents.
… which is of possible use to people who are running SLED. No-one else, however, is covered by that agreement.
You do not need to worry about MS patents on C# or the CLR but not because of that agreement. Novell has specifically stated in the past that the patent deal had nothing to do with Mono.
However, the Microsoft Community Promise (MCP), the fact that the .NET micro edition is open source, the fact that several Microsoft technologies have been released under the Apache 2.0 license, and other reasons do mean that you do not need to worry about C# or CLR patents.
ADO.NET and some parts of ASP.NET could keep you up at night if you are truly paranoid. But if that is the case, I do not know how you could use anything else without cold sweats either.
This is problematic both for Microsoft and for the Linux desktop.
Microsoft need multi OS support for .NET (as Anders is saying “Reach is King”).
For Linux development it leaves C++ as the only real development environment, and that sucks.
Linux desktop RIP.
It’s less problematic for Linux than it is for Microsoft. It’s not like there are that many desktop apps being written in .NET anyway. But when it comes to Web application development in the enterprise (which is where most enterprise software development takes place these days), it’s more problematic for Microsoft than for Linux.
Java is winning the Enterprise Web app war over .NET by quite a wide margin specifically because it doesn’t lock users into Windows. As a Web application developer for the vertical market, if there is any chance that any of my customers might want to run their own instance of the app on their own servers in their own rack, rather than let us host it for them, I’m always going to use Java instead of .NET. Why? Simple. I’m not going to risk losing a million dollar contract because the customer’s infrastructure is Linux based, and so they have to choose a competitor’s product just because my .NET product won’t work on their Linux servers.
Never underestimate the value of being able to tell a potential customer “Yes, it works, and is supported on your existing server infrastructure. And that is true whether your infrastructure is based on Windows Server, Linux, Solaris, AIX, HP-UX, or even Mac OS X Server.”
If Microsoft wants .NET to effectively compete with Java in the enterprise space, .NET has to have very good, and supported cross platform implementations that are 100% compatible with .NET running on Windows. It really is that simple.
In some ways, .NET is nicer than Java. ASP.NET web forms are really slick for example. But I still won’t use it for most of my products because it locks my customers into Windows Server, and doesn’t give them the freedom of running the app on whatever Server OS they use in their organization.
Edited 2011-05-05 16:20 UTC
The same argument applies on the desktop itself as well as on the server. If one writes a desktop client application in a cross-platform framework, such as Qt/Java or Qt/Python for example, then it can easily be made so that it runs on Windows, Linux or Mac desktops.
ASP (or the original Java JSP) is old tech. Try Google Web Toolkit (GWT) which allows use of Java both on client and server side. Lightyears ahead.
Microsoft’s equivalent of GWT is called “Project Volta” but that appears to have stalled.
Don’t need .NET on Linux (or any other platform). Java does the trick, is GPL Free (beer & liberty), has more jobs, more libraries, more platforms, multiple vendors, and wider reach.
If you like C# then it was derived (and enhanced) from Java (via the intermediate language “Cool”). They are pretty similar (and their very base libraries too, given their common lineage). There are plenty of folk who whinge about language constructs in C# that are missing in Java but they miss the point that Java is deliberately simple by design – so that less skilled programmers can use it as well as very skilled developers.
That’s really an issue of personal taste. A lot of people don’t like marking up their UI in code. And if you have a web design team that is used to using tools like Dreamweaver, you can completely forget about GWT.
@Pantheraleo:
Google Web Toolkit can produce layouts in code or declaratively using its ‘UI Binder’ technology. Plus, the overall layout is achieved using CSS.
Might be worth you checking out Google Web Toolkit again, since your info is out of date. Especially since GWT is evolving at a fast rate (it ought to be, the might of Google is developing it).
Edited 2011-05-06 03:42 UTC
I’ve looked it recently. Didn’t realize you could develop UIs outside of code now.
But I stll have other problems with it. It’s component set is very primitive for example. Granted, there are third party add-ons to solve that, such as SmartGWT.
The other problem I have with it is that for very large projects, the compile / test cycle becomes somewhat unmanageable.
Once you have your GWT-RPC calls sorted out you generally don’t restart anything. Instead you refresh the browser and the what looks to be incrementally-compiled Javascript gets loaded. So generally you just do browser page refreshes to see the latest changes you have made.
From your objections it sounds like you haven’t tried GWT yet – it ain’t perfect by any means, but it is pretty good and betterer than the ‘old’ (lol) style way of working with raw Javascript libraries (where you worry about browser differences a lot), and page-oriented systems (soooo inflexible from the user’s point of view).
Edited 2011-05-06 04:06 UTC
Once you have your GWT-RPC calls sorted out you generally don’t restart anything. Instead you refresh the browser and the what looks to be incrementally-compiled Javascript gets loaded. So generally you just do browser page refreshes to see the latest changes you have made.
I have tried it. And I didn’t care for it much. Compile / test cycles were too long on large apps, The Eclipse plugin was unstable and buggy. And when something does go wrong in the generated Javascript, debugging it can be a nightmare from hell sometimes.
I also think GWT exposes too much of my application’s business logic to the client.
Edited 2011-05-06 04:18 UTC
Only if you design it badly. The business logic should be on the server, with display logic on the client. Validation happens both on client and server. You can never trust clients!
Yeah, definitely validation has to happen in both cases. But in some cases, a lot of business logic is pushed onto the client in GWT in order to save AJAX calls to the server. For example, some complex calculation that needs to be done while the user is entering a form and used as the data for another field might be done on the client to avoid an AJAX call, and then redone on the server when the form is actually submitted to make sure the calculation was done correctly, and that the user is not trying to pass bad data to you.
Although that can provide an improved user experience, it can also expose some of your business logic algorithms to the client, which you might want to do.
And no, I don’t work with raw javascript libraries that much. My preferred solution right now is JSF2 / Facelets with a decent component library such as PrimeFaces or OpenFaces, combined with Spring for dependency injection, controller, and persistence management.
Arrgh! JSF(1) was simply awful. I’ve not tried JSF2 though.
JSF(1) was awful, yes. Everyone universally hated it. you might want to look at JSF2 and Facelets though, either with Java EE 6 or Spring. It’s vastly improved.
And why don’t hire Microsoft the Mono-developer like de Icaza?
If a platformindependent OpenSource .NET is good for Microsoft, why then comes it from HelixCode/Ximian/Novell/Attachmate/SuSE and not from Microsoft itself?
Mono is OpenSource, so Microsoft can still support and improve it.
Don’t be silly. The majority of Gnome/GTK apps are developed in C or Python. And there are other languages that are used – Ruby, Perl, Vala, etc.
It’s just not C# or C++.
Au contraire, Qt has bindings for: C, C++, D, Python, Ruby, Java, Pascal, Perl, PHP, QML, Tcl, Haskell, Lisp, R, Ada and Lua.
http://en.wikipedia.org/wiki/Qt_%28framework%29#Bindings
Qt is cross-platform, is licesnsed under LGPL so it has a linking exception, and it has a powerful development environment.
http://en.wikipedia.org/wiki/Qt_%28framework%29#Tools
http://en.wikipedia.org/wiki/Qt_Creator
Even though it does support C#, AFAIK there are very few programs written in Qt/C#, probably because the plethora of other options are better.
If one wants to write a cross-platform application these days, using Qt is by far the best option.
Enjoy.
Using .NET will constrict your application to just the Windows market.
Edited 2011-05-05 23:15 UTC
People are focusing on .Net patents but are missing far bigger and far more obvious problems with Mono.
The truth is, Microsoft is a Mono’s ally. Mono helps them pushing .Net to the world. Of course they only want Mono as a crippled implementation of .Net. Always one or two major revisions behind, missing important pieces etc. Then Microsoft is ahead and the rest of the world is playing catch-up. Guess what platform will people use for serious work with .Net. Guess what platform will people use for the web if Silverlight becomes popular.
Patents could (and would) become a problem if somehow Mono has managed to threaten the leader position of the official .Net implementation. That, however, is very unlikely.
It’s not like Mono is bad for the OS world – it’s a great compatibility framework. Just like Wine it helps to lower entry barriers, make application porting easier etc. It’s a vanishing niche, though. On one hand there are cross-platform toolkits out there available to anyone who cares about portability, on the other there is the web, which thanks to great work of Firefox guys became almost platform agnostic.
That’s the strategy they have been using up until now, yes. but it really hasn’t worked out very well. Because what is actually going on, is people are just avoiding .NET and using Java instead. Java is around twice as popular in the enterprise world right now as .NET. And Java is actually gaining market-share, where as .NET has lost some market-share over the last two years. Of course, the high cost of entry to .NET doesn’t help either (Windows server license costs, Visual Studio, which runs around $4,000 per developer for a version that has all the capabilities that a $599 Java IDE has, etc).
Of course, it may not matter what Microsoft does from this point on, when it comes to enterprise software development. That ship may have already sailed with Java having too much of a dominant position already, and companies already too invested in their Java platforms to switch to .NET now.
There are a lot of companies using .NET of course, but compared to Java, .NET’s market-share is fairly small. If .NET wants any chance at all of catching Java, they are going to have to have an up to date implementation for Linux that is 100% compliant with the Windows implementation, is officially supported, and releases in parallel with the Windows version. Yes, as one other commenter pointed out, Microsoft probably should hire the now out of work Mono developers to produce an official port of .NET for Linux.
Edited 2011-05-05 18:19 UTC
If they really laid-off 30 Mono devs in the US, I would be surprised not to see them re-appear as an independent company.
Miguel has stated going independent as a possibility in the past (cannot remember the link). There is a lot of commercial activity around Mono at this point (Unity, Codice, Second Life, MonoTouch, MonoDroid). I am sure that most Mono users would rather get their product from Miguel and his teach than some unknown group in Germany.
MonoTouch is effectively dead. Apple killed it when they changed their iPhone developer license agreement so that you can only use C and Objective C with Apple native APIs if you want your app in the app store.
I don’t know of anyone that is actively using MonoDroid.
Codice? It took a fair amount of googling for me to even figure out what Codice was. I finally figured out it’s a proprietary version control system. Really? When there are so many great FOSS choices out there? People are going to use a proprietary one? Maybe on Windows they will. But Linux users aren’t going to use a proprietary version control system. Not when there are so many really good free and open source ones available.
Unity might be the only one you mentioned that I would agree with you is generating any significant interest.
Side note: I predict the makers of Unity are going to claim trademark infringement against Canonical for trademark infringement and demand they change the name of their new desktop interface “Unity” and demand that they change the name. It’s already causing significant confusion where when most people hear “Unity” in the context of a software product, they think of Ubuntu. Not a game development system.
Edited 2011-05-05 19:43 UTC
Apple Backed away from that restriction around august-sept of last year. There is no restriction on what language you can use to develop an iOS app. Apple found out that a large amount of development houses are using crossplatform toolchains to build some of iOS’s very popular titles. MonoTouch is a great way to leverage C# on the iOS mobile platform…as well as build a base for crossplatform apps (via MonoDroid/MonoTouch/WindowsPhone/etc)
MonoDroid has just been released. Its too early to assess its adoption. I used MonoDroid during their long pre-release testing period. Its also pretty darn nice for leveraging C# knowledge and developing some pretty slick Android Apps. Apple’s fear of apps not taking advantage of native features is a non-starter.
Didn’t know Apple had backed off of that. That’s good to hear at least.
Unfortunately, Mono is also a non-starter if they can’t keep up with Microsoft and release new versions in parallel, as well as guarantee compatibility with the Microsoft implementation of .NET.
I really hope that Microsoft does hire the Mono dev team. But I doubt it will happen.
Edited 2011-05-05 20:00 UTC
Hardly…
Most software these days can be built to .NET Framework 2.0 compatibility. There have only been a few things added since then (and 3.0/3.5 are basically the 2.0 framework with extra assemblies).
.NET Framework 4.0 is required for some of the hot new Silverlight stuff – but unless you need that, Mono can likely still run most of the .NET software out there. Any developer who targets the 4.0 framework needlessly is probably shooting himself in the foot.
Update: Existing compatibility is key, however…
Edited 2011-05-06 00:06 UTC
Sure, and some of them are major. LINQ for Entities being an example. To the best of my knowledge, Mono doesn’t even have a stable implementation of LINQ for SQL yet (just a preview version), but LINQ for SQL is already deprecated in Microsoft’s .NET implementation in favor of LINQ for Entities. I’m pretty sure graphing was also added in 3.5 and probably doesn’t work in Mono.
Also, ASP.NET 3.5 added quite a few new advanced AJAX backed controls that presumably may or may not work on Mono.
Also, when a customer signs a million dollar contract for an application with me, any technology that does not have guaranteed compatibility is a non-starter for me. That’s why all companies producing their own versions of Java have to have their Java implementation pass the extremely rigorous compatibility test suite before they are allowed to call their product Java. With Mono, however, I really have no guarantees of compatibility with .NET. And that’s a non-starter on a million dollar contract.
Also, if we bring desktop apps into the equation, I wouldn’t exactly consider WPF to be a minor feature.
Edited 2011-05-06 01:05 UTC
You would be hard pressed to find anything on ASP.NET that does not work on Mono. The actual ASP.NET MVC 2 code is even distributed with Mono now. The Razor view engine (MVC 3) is not open source but I am serving ASP.NET (using Razor but do not tell) apps served off both OS X and Linux.
Mono supports .NET 4 applications. Perhaps not every API at this point but it supports everything I have tried.
Mono prioritises development and 100% feature parity with every Microsoft library is not really a goal. If you are developing for Mono it is not a real constraint.
So yes, LINQ-to-SQL was not a priority. Good call it turns out as even Microsoft is dropping it as you say. LINQ itself has been supported forever, including LINQ-to-XML.
Of course, you have been able to use real ORMs like NHibernate for years on Mono. By releasing Entity Framework, Microsoft is just trying to catch up with what is possible using these other solutions so it is really no hardship not to have them. How big a priority should LINQ-to-Entities support be if every Mono developer is already using something else?
So too with Windows Presentation Foundation. Mono supports GTK# as it’s core cross-platform GUI solution. There are several large, complex GUI apps using GTK# to support Linux, Mac, and Windows.
It is also the position of the Mono team that quality apps should code the GUI native for each platform. That is why they have MonoTouch for iOS, Mono for Android, and MonoMac for native Cocoa desktop apps. Guess what the native GUI toolkit is for Windows: WPF. Windows Forms is supported cross platform on Mono and some apps do use them. PlasticSCM is a Windows Forms GUI for example.
Not having WPF on Linux is not a big deal for Mono developers. Spending time on WPF is not only not a priority but in fact against the philosophy of the Mono community. Why are you not instead saying that .NET is failing way behind because it does not even support MonoMac GUI apps? It is simply your bias that Mono is nothing but a Microsoft compatibility library.
WCF could be considered another example. The Mono support is way behind Windows. Of course, ServiceStack works just fine. The Mono team did not really pay any attention to WCF until they decided they needed it for Silverlight (Moonlight). It has come along quite nicely since then.
Mono is an extremely capable platform and the core is extremely compatible. Some of the add-on bits do lag but the only people that care are those that want to use nothing but Microsoft tech and then whine about it not being portable. Who cares?
Edited 2011-05-06 03:45 UTC
If LINQ to Entity is not supported on Mono, than I’d say there’s actually a lot of modern ASP.NET stuff that won’t work on Mono.
Also, again, I doubt the graphing API works, since it relies on GDI+, which is probably not implemented in Mono.
The “Do not tell part” suggests to me that you are doing it in violation of one or more licenses. If that is the case, than it is not an option for me. As a commercial company with major clients that could get audited at anytime for software license compliance, I have to keep things on the up and up.
Again, that’s a non-starter for me. If it is not 100% compatible, I can’t risk it. Not with the kind of contracts I serve.
Which isn’t as stable as Hibernate for Java yet. And if I’m going to use Mono, but rely on ports of a bunch of popular Java libraries to work around the fact that half the .NET features are missing, then why not just use Java in the first place?
Sorry, but GTK is a joke on Windows and Mac. I have bug reports on file for the Windows port of GTK that are 4 years old and haven’t even been assigned to anyone. And when it comes to Mac, the native Aqua port is not production ready. The only production ready port requires X-Windows and produces a very non-native experience. That’s a non-starter for most Mac users.
I use a lot more features than just the core. And extremely compatible != 100% compatible. And unless it is 100% compatible, I’m not going to risk it. Again, this is where Java clearly wins. Java is 100% compatible on all platforms that it runs on.
Again, if you can’t use the Microsoft tech, it seems to negate the whole point of using .NET in the first place. When it comes to Linux, Java is a far more mature and stable platform. And it is 100% compatible on every platform it runs on. And if you are going to resort to ports of Java libraries on .NET (such as nHibernate) to make up for the missing functionality, then why not just use Java in the first place?
Any developer who targets .NET at all is probably shooting himself in the foot. The only platform for which .NET applications can be developed without risk is Windows. All existing Mono applications (for Linux) call components of .NET which lie outside of the ECMA parts, and therefore they lie outside of Microsoft’s Community Promise (which only applies to C# and CLI, not to all of .NET).
Any developer who targets multiple platforms should avoid .NET entirely (if you must use C#, use it within the Qt framework, not Mono). Doing so is the only way to put down the footgun.
Edited 2011-05-06 01:10 UTC
I so do not agree with this. Any application that must run on different OS’es must have the UI and interaction designed for each specific OS or risk sucking big time.
While QT is ok on KDE, halfway decent on Windows XP it does not look ok on OSX or modern windows and usually the apps only has good integration with the OS on one single platform.
Mono is targeting a situation where you write a different UI for each OS so that iOS, OSX, Android, Windows, Web, Gnome and KDE each has a separate UI that is tailored for that OS and environment.
http://en.wikipedia.org/wiki/File:Smplayer-vista.png
http://en.wikipedia.org/wiki/File:VirtualBox326.png
http://en.wikipedia.org/wiki/File:DAZ_Studio_1715_screenshot.png
http://en.wikipedia.org/wiki/File:Clementine_0.6_in_Windows.png
http://en.wikipedia.org/wiki/File:Scribus-1.3-Linux.png
http://en.wikipedia.org/wiki/File:Texmakertop.png
The applications look similar under different environments, and are no more “alien-looking” than other applications built for the one environment but using different toolkits.
Qt SDK 1.1, targetting Qt 4.7, has been released, BTW.
http://www.h-online.com/open/news/item/Nokia-releases-Qt-SDK-1-1-12…
Enjoy.
Edited 2011-05-06 03:17 UTC
That might have been true at one time, but it isn’t anymore. Neither Microsoft or Apple follow their own HIG guidelines anymore. Just look at the difference between say, Microsoft Word, and Microsoft Internet Explorer. Neither one has a menu bar anymore, and the interfaces are totally different from each other.
But also, lets face it. The desktop application, with few exceptions, is dead. That makes the whole discussion about Qt vs. GTK vs. WPF vs. Windows Forms vs. Cocoa basically irrelevant. How many people even use a thick email client anymore for example? I know I don’t. I just run GMail in a browser tab with desktop integration turned on so Chrome notifies me with a little popup in the bottom right corner when I have new email.
How many people still run thick personal information managers anymore? I don’t. It’s all in Google calendar.
These days, software runs on the server. And has a client front end written in JavaScript or Flash. And when it comes to writing server side software, I just don’t feel Mono is ready for production use unless you are writing a “toy application” where down time and bugs in the framework are acceptable.
If you are going to program in .NET, and you are doing serious work where downtime and instability means lots of lost money and potential lost customers, then realistically, right now, you are locking yourself into deploying on the Windows platform. That’s perfectly fine, if you are creating a 100% SAAS model where you will always host the application yourself, and you will always have control over the servers they are deployed on, and you are willing to commit to deploying on Windows servers.
But in my case for example, I have some customers that due to the nature of their data, absolutely have to deploy the software on their own internal servers. Letting me host the app for them is not an option. And because of that, I need to ensure my application is compatible with their platform. I can’t do that with .NET
Several years ago, I worked for a company that had decided to develop and deploy on the .NET platform. They had exactly that situation come along. A company wanted to buy our software, because it was the best in the industry by far. But their own policy prohibited them from deploying server side applications on Windows. The company I worked for ended up basically doing a re-write of the application in Java just so it could get this customer. In fact, that is why I was hired there. To rewrite their .NET application in Java.
I learned a valuable lesson from that experience. And that is why today, I will never write anything in .NET unless I am 100% sure it will only be hosted on a Windows server, and there’s no chance a customer might come along who needs to deploy it on a non-Windows platform.
Don’t get me wrong, I like .NET, and it has a lot going for it. I will use it sometimes when I can. But if there is any doubt about whether the application will ever need to be deployed on any platform other than Windows, than I won’t use it.
Edited 2011-05-06 03:36 UTC
Or kill .Net and go with mono. For me it makes sense.
Apple never actually put the proposed language into practice. No app has ever been rejected from the App store for using Mono. Both MonoTouch and Unity are used for best selling titles on the App store. I have a MonoTouch app myself.
My point was not that any given software (like PlasticSCM) is mainstream or even that you should use it. My point is that Mono is being used as the foundation for a significant amount of commercial activity.
It looks like I will not get to test my theory yet though that Miguel and company would simply setup shop on their own. If you look at the commits in the Mono Git repo, you will notice that several Novell employees (including Miguel himself) have made commits since this article was written. Some (the same as did before) continue to use their novell.com email addresses to do so.
I strongly suspect that the rumour mill simply has it wrong on this one.
They probably were not laid off instantly, and they are probably finishing up any remaining outstanding work they had to do at Novell before they leave. I doubt the rumor is wrong. I think it’s more of an issue of Attachmate was nice enough to give them notice that they were getting laid off. Rather than just have them show up at work one day and then tell them to clean out their desk and go home because they don’t work there anymore.
Normally when a company lays off an employee (or multiple), those employees are paid up until the next cycle but they are not expected to continue working until then.
Would *you* continue to do work for a company that just laid you off? I doubt it.
In my opinion, Attachmate now should get rid of all patent-infested code, drop all compatibility with .NET, take different laguage – Go, Python or Scala or … and create fully open sourced competitor for Java and .NET platforms. Also making it primary programming platform for Linux systems.
Qt and C++ are already there
C++? You’re joking, right? And Qt? Qt is in Nokia’s hands, and Nokia is in Microsoft hands. I wish You good luck with Qt.
Btw. Who is using a programming language without garbage collector these days?
“Btw. Who is using a programming language without garbage collector these days?”
http://www2.research.att.com/~bs/applications.html
Huge list, and only partial at that.
And to be fair, C++ is mostly used for system level stuff, or commercial shrink wrapped stuff, or games, or anything speed dependent.
Your statement actually applies to either web, or internal corporate apps.
From the list: “All major Adobe applications are developed in C++”.
Yep. And Adobe applications such as Flash and Acrobat are plagued with security problems. They are probably one the biggest security nightmares that sys-admins have to deal with. Of course the security issues wit C++ when writing network applications are one of the main reasons it’s falling out of favor in environments where applications are exposed to untrusted users.
The speed advantage of C++ has largely disappeared with modern optimizing JIT engines like Java and .NET have.
That’s certainly true. But internal corporate apps and Web apps are where the vast majority of development happens these days. Most desktop / shrink wrapped applications, with the exception of games, are basically legacy software these days. There’s not a whole lot of new desktop software development going on other than updates to legacy applications such as MS Office. And of course, if Google has their way, even MS Office will go the way of the dinosaur in favor of Google Apps.
When was the last time you used a thick client encylopedia? or thick client mapping program for example? Or hell, do you even use a thick client email program anymore? I don’t I just constantly have a browser tab open with GMail running in it.
Edited 2011-05-06 17:25 UTC
There are still advantages in memory footprint, program startup time and predictability.
True, but memory footprint is also less relevant these days, given that RAM is so cheap these days that the average system comes with more of it than most people ever use. Startup time has also been reduced quite a bit with recent version of the VM. It’s still longer than most C++ programs of course, but startup time is an insignificant percentage of the total time spent using the program. And for server applications, startup time is basically irrelevant.
Predictable? Can you elaborate on what you mean by predictable? I’d say Java is more predictable than C++. The Java VM makes many guarantees that will hold true, no matter what platform is involved. Also, because of Java’s security model, the JVM makes several guarantees about program behavior that C++ does not make. If you try to write past the ends of an array in Java, the result is a predictable ArrayIndexOutOfBoundsException. If you try to write past the ends of an array in C or C++ (assuming just vanilla C style array), the result is unpredictable, and could range from a segmentation fault crash, to corrupting other data in the application, to a security hole if someone can use it to execute arbitrary code. By those kinds of metrics, Java is far more predictable than C++. You must mean something else by the word “predictable?”
Edited 2011-05-09 17:31 UTC
Scala isn’t a competitor to Java. It’s a language written for the Java virtual machine. So it basically runs on Java.
Any why should they reinvent the wheel? They should just adopt Java, which is fully open source now as it is licensed under the GPL. There are also open source implementations of Java EE licensed under the GPL (Glassfish) and some under the Apache licenses (Geronimo).
Adopting Java has worked well for Red Hat after all.
Edited 2011-05-06 19:59 UTC
You misunderstood me. I meant Scala as a boilerplate-free language compared to Java language, not a platform. Java is bad and ugly programming language. Its the new old C++.
I disagree with that. And here is why. It’s true that Java is verbose, but that verbosity is why Java IDEs are so incredibly powerful. Java IDEs can do things that IDEs for dynamic languages can’t even dream of doing because there just isn’t enough information in the code to figure out what to do. If you really take the time to learn the features of your Java IDE, it can save you enormous amounts of typing, and enormous amounts of time because you don’t have to break your flow to stop and look things up.
Let me give you a few examples of things I typically do in my Java IDE, in this case, IntelliJ IDEA.
Let’s say I want to add an action listener to a component that I have:
addAc [Ctrl + Space – Enter] The IDE automatically finishes the method name addActionListener for me.
Now lets say I want to create an anonymous inner class as my action listener:
new A [Enter]
The IDE automatically completes the class name, automatically imports the required classes, and automatically generates a method stub for the method I have to implement. So basically, when I type new A [Enter], the IDE generates all of the following code for me:
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
new ActionListener() {
public void actionPerformed(ActionEvent e) {
// Insert code here
}
});
I get all of that, just for typing “new A [Enter]”
Let’s say I want to create a new RequestDispatcher object:
RequestD [Ctrl + Space – Enter] [Ctrl + Space – Enter] = new R [Enter]
Again, that will automatically complete the class name, and automatically import the required class. The second [Ctrl + Space – Enter] will automatically create a variable with a reasonable name (in this case it will create a variable named “dispatcher”), and finally, the new R [Enter] will automatically complete the class again.
Later, lets say I want to pass that request dispatcher object to another method of another object that accepts a request dispatcher as a parameter.
someObject.foo([Ctrl + Space – Enter]);
In this case, IDEA is smart enough to know that the only variable I have in scope that matches the type expected by someObject.foo, is the dispatcher object. So it will automatically complete the code with the correct variable. This works even if dispatcher is a subclass of the type that someObject.foo expects (or implements a compatible interface). IDEA is smart enough to recognize that as well, and so recognize that dispatcher meets the type requirements of the parameter that someObject.foo expects.
Whether you use [Ctrl + Space – Enter], or just [Enter] depends on whether a popup code completion has already displayed automatically or not.
If you really learn how to use your IDE (especially if it is IntelliJ IDEA), you’ll be amazed at how often you can use auto-completion and have the IDE know what you want. That saves enormous amounts of typing, as well as reduces the risk of repetitive stress injury to your fingers.
Granted, Java is not much fun to write in a plain text editor that doesn’t “understand” the Java language. Bur when you write Java in a decent IDE, you’d be amazed at how productive you can be. And of course, since the IDE recognizes and flags all of the same errors that the compiler does, there’s no excuse for ever having a compile time error when working in an IDE.
Edited 2011-05-07 02:06 UTC