Linked by Thom Holwerda on Fri 22nd Feb 2008 09:16 UTC, submitted by obsethryl
.NET (dotGNU too) "Previously, we have presented one of the two opensource licensed projects related to creating a C# kernel. Now it's the time to complete the set by rightfully presenting SharpOS, an effort to build a GPL version 3 + runtime exception licensed system, around a C# kernel of their own design. It is my pleasure and priviledge to host a set of questions and answers from four active developers of SharpOS, that is William Lahti, Bruce Markham, Mircea - Cristian Racasan and Sander van Rossen in order to get some insight into what they are doing with SharpOS, their goals, their different design and inspiration."
Thread beginning with comment 302078
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: So what ?
by obsethryl on Sat 23rd Feb 2008 09:40 UTC in reply to "RE[4]: So what ?"
obsethryl
Member since:
2006-11-16

Resource leaks can be dealt with by using the 'Resource Acquisition is Initialization' pattern. It is not as elegant as in C++, but definitely possible. I use this all the time.


Correct. And there are many many ways to do nice things in C++. It is just hard when you begin, but not at all once you start relying on efficient design and solid implementation to develop your ideas further. It does not attempt to make things easy for the sake of making them easy to begin with. Sure, nothing is perfect, but a multiparadigm language that allows you to be able to work at _any_ level you wish to work with your hardware may be a best fit in many scenarios.

However, language shoot - outs serve no particular purpose, for the record, I will quote B. Stroustrup on this, from his page at

http://www.research.att.com/~bs/bs_faq.html

where you can see the context the words below are written in:


I also worry about a phenomenon I have repeatedly observed in honest attempts at language comparisons. The authors try hard to be impartial, but are hopelessly biased by focusing on a single application, a single style of programming, or a single culture among programmers. Worse, when one language is significantly better known than others, a subtle shift in perspective occurs: Flaws in the well-known language are deemed minor and simple workarounds are presented, whereas similar flaws in other languages are deemed fundamental. Often, the workarounds commonly used in the less-well-known languages are simply unknown to the people doing the comparison or deemed unsatisfactory because they would be unworkable in the more familiar language.

Similarly, information about the well-known language tends to be completely up-to-date, whereas for the less-known language, the authors rely on several-year-old information. For languages that are worth comparing, a comparison of language X as defined three years ago vs. language Y as it appears in the latest experimental implementation is neither fair nor informative.



I believe that the above apply to many situations.

Reply Parent Score: 1