C# In-Depth
Bergkamp10 from ComputerWorld writes "Microsoft's leader of C# development, writer of the Turbo Pascal system, and lead architect on the Delphi language, Anders Hejlsberg, reveals all there is to know on the history, inspiration, uses and future direction of one of computer programming's most widely used languages — C#. Hejlsberg also offers some insight into the upcoming version of C# (C#4) and the new language F#, as well as what lies ahead in the world of functional programming."
Could it be that C# is one of the most widely used simply because of the installed base of windoze machines all over the world and not because of any technical merit? Most current languages have compilers and interpreters that run on windoze; what makes people choose C# over the others? Just how much impact has C# had on computing sciences as a whole, anyway?
>>one of computer programming's most widely used languages.
I highly doubt that a language that has only been around for a few years is the most "widely" used computer language. Cobol, fortran, or standard C , maybe.
Well there is fragmentation produces as they introduce YET another language.
So? That's a problem for Windows developers. Why should a Java programmer care? In the realms where Java is popular, C# has had basically no influence. So MS has, at worst, fragmented the Windows development ecosystem... big deal. :)
You currently cannot say C# replaces C++ on Windows platform as using any DirectX components for example is nightmare through C#.
...
More on the major downside of writing .NET applications is that you cannot guarantee that the stuff I work on my Vista workstation works on my co-workers XP workstation.
But none of this has anything to do with fragmentation to begin with. You're getting off-point. And that's ignoring the fact that, once again, this is a problem for MS... the rest of the programming world doesn't care one whit how hard DirectX is to integrate with C#.
Can it be a success when it cannot be used to produce major parts of their own operating system.
Last I checked Java wasn't being used to write operating system components, yet no one claims it's a failure. Now, that's not to say C# and .NET are unbridled successes, but that's a pretty crappy metric for making the call.
The implementation is about the same in both languages, but using it is much nicer and cleaner in C# than in Java.
That really is a matter of opinion. In Java, it's pretty clear that you are requesting or modifying a property of the object. In C#, you are using assignment to represent that mechanism so you might be accessing a public member variable directly or calling a method to achieve that end. To me, the Java method is more explicit and therefore less prone to error.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Java: Properties are private variables/methods exposed through a public method. Seems unnatural and tedious when accessing a guarded variable, e.g.
Line.GetWidth(); Line.SetWidth(10);
Two different calls for accessing a single property.
C#: Properties are private variables/methods exposed through a public variable. May be cause for surprise e.g. when
Line.Width++
increases width and executes statements outside the scope of width increase.
For exposing a (guarded) private variable I prefer the C# way, but it's too easy to mix data with flow.
I don't feel a property can be accessed as either a variable or a method, because it isn't and adds to confusion.
Here are some problems with Python:
* significant whitespace does not play well with common development practices (merging, diff'ing, copying, pasting code, esp. on web pages)
* GIL makes it very hard to scale or completely unscalable in some situations
* no support for static typing makes large projects harder to manage
* not truly cross platform - a lot of common libraries are implemented in C and thus you have to install native code for them to work - bad luck if there isn't a binary for your platform.
* no common standardized GUI toolkit
* poor commitment to backwards compatibility - Python 3k is going to break compatibility in major ways as did releases before it
* awkward and ugly object oriented semantics (declaring "self" in class methods, ugh)
* poor IDE support
* poor adoption - not sure what makes you think the labor pool for Python is better than other languages
I'm sure a dozen python supporters will jump up and object to all these - there is hardly anything revolutionary about these criticisms and most of them have been fought to death in enormous flame wars in the past. But the end result is, Python is not great for a lot of "enterprise" type situations due to these things (and you will quickly see how sensitive pythonistas are to this snub since they constantly mock the word "enterprise" on mailing lists etc.). In other situations it can be brilliant.