What really surprised me is the number of Java and C# projects (and ports) that were attempted and canned. Don't get me wrong, this isn't against managed languages or anything, it's the fact that C++ seems to have an immense gravity pull that doesn't leave much room for alternate languages, despite what the collective perception might be.

There are no major operating systems written in managed code, but higher up the stack, I have written 4 applications using C# in the Visual Studio 2010 timeframe, had I been using MFC, I still wouldn't have finished the first app.

I was surprised to see that YouTube is written in Python.

Also I'm fairly certain C# is an official language of the Gnome Project (ie. parts of Gnome can/are written in C#), unless that changed and JavaScript is an official language of both Gnome/KDE. Big parts of Gnome 3 are written in JavaScript. Also I've fairly certain gcc is developed in C, not C++.

Python is one of the standard "Google languages", it is actually developed with financial support from Google. They probably use it for a lot of internal stuff we don't know about. The standard requirement for working at Google is to have at in depth knowledge of at least one of: C++, Java and Python.

I would have expected that in the big league, where there's no scarcity of highly skilled developers, legacy code would have been less relevant, which would have meant at least a few successful ports or at least a lot more hybrid projects, showing some ongoing transition. Guess I was wrong

Movement takes time however, and I think quite a few companies have hesitation for moving to JIT-ed language because of fear that readily readable decompilation will cause (so called) "know how" of the application leaks.

10 hours ago, Blue Ink wrote

I would have expected that in the big league, where there's no scarcity of highly skilled developers, legacy code would have been less relevant, which would have meant at least a few successful ports or at least a lot more hybrid projects, showing some ongoing transition. Guess I was wrong

There is always a scarcity of highly skilled developers. Every member of staff costs you money to employ - and the typically the better that member of staff is, the more expensive they are.

Now as a company you can either pay that member of staff to add new features to sell you more products, or you can get them to tread-water and "improve the codebase" - something that might make the whole codebase less stable (you're changing code that's already good enough to ship in previous versions) and without them developing more features for you to sell.

The sad fact is that a customer (and definitely a salesperson) would pretty much always prefer 10 new features to a 10% global speed-improvement - even if they hardly ever use those new features.

we had a release scheduled in 12 months, and the list of new features (and minor bugs) we wanted to add amounted to about 9 months of work, in C#. That would have called for a full rewrite, calling for 14 more months. Adding the same set of features in C++ required almost 22 months (it was UI heavy, and that's where C# really shines).

Result: our only option was to stay with C++, slashing the list of new features and triaging bugs aggressively. The loss will compound over the next few years, unless we can afford to skip a full release cycle (and that will be a major risk anyway). Outsourcing the job is unthinkable and hiring more developers for a contingency is usually not a good idea.

A larger company might have decided to bite the bullet and go the rewrite route, shifting enough developers to the team to make that fit the schedule. The investment would be repaid in a couple of years, with the added bonus of a (possibly) richer feature set and no risk of falling too far behind against the competition. This doesn't seem to be happening, which makes me wonder what I'm missing.

1 day ago, Blue Ink wrote

I stumbled upon this little table reading Herb Sutter's blog. Ok, most of the software listed there has been around for quite a while, or has evolved from something older, so it stands to reason that legacy code has a lot of influence.

What really surprised me is the number of Java and C# projects (and ports) that were attempted and canned. Don't get me wrong, this isn't against managed languages or anything, it's the fact that C++ seems to have an immense gravity pull that doesn't leave much room for alternate languages, despite what the collective perception might be.

i think the table only shows that large apps and OS are not written in C# / Java and that is not a surprise at all.

but I bet that there are thousands or hundreds of thousands of important apps that the table can not show - for example I have a large complex system that has been running for over 5 years and it's about 99% .Net / C#  - makes money for a fair sized company that employs around 300 staff.

now how many other systems are out there like mine ? a lot i bet and we will never show up on a table like that one....

1 day ago, Blue Ink wrote

I stumbled upon this little table reading Herb Sutter's blog. Ok, most of the software listed there has been around for quite a while, or has evolved from something older, so it stands to reason that legacy code has a lot of influence.

What really surprised me is the number of Java and C# projects (and ports) that were attempted and canned. Don't get me wrong, this isn't against managed languages or anything, it's the fact that C++ seems to have an immense gravity pull that doesn't leave much room for alternate languages, despite what the collective perception might be.

oh and as for the attempts to switch,  well some things should be done in C / C++ / ASM and only a nut will try and change them.   at other times it may be that folks who do not fully understand the tech may try and change stuff ; but if you do not have the right level of understanding of what you are getting into it may well fail not due to any flaw in the tech but due to flaws in management and in making the right calls on what to mess with and what to keep as is.

21 hours ago, davewill wrote

@figuerres: I concur.  There is a lot not reflected in that table.  I helped build custom systems for 9 years prior to my current work and none of those will show up on that table.  Many of those custom systems push millions of dollars through the customers company every quarter.  Weight the data you see cautiously.

LOL  , yeah there are so many small projects that run businesses that will never show up on some grand overview ....   it's like for each os listed there are probably 300,000 LOB apps that run on that OS and they use all kinds of stuff....   and that's proabaly a low number ....

right now a buddy i adding a new app to my system,  he is using MonoTouch for the iPhone /iPad so thats another C# app ..... and so on ...

and with the iPhone app it will look like it's Objective C unless you double check....