Comment: Re:Cross platform via wine (Score 1) 142
those options are not worst than the way other platforms offer to interact with native calls. e.g. Python ctypes or as mentioned jni. Most of the times you dont even need to go that far, and if you find repeatedly far from the runtime, then you are using the wrong tool.
I didn't say there were. What I did say was that MS claimed C# was the way of windows programming for the future. And then they failed to deliver by delivering a half-ass language.
.NET's primary feature is multi-language support. C# was supposed to bring the wonders of Java managed memory to Windows developers, and of course better it. MS itself originally stated that C# (.NET, C# with C++/CLI were the only two languages really supported at that time) was to be the one and future language for programming in windows, including the system. Recall Longhorn?
Since VS2002 vb
Yes, it serves fine as a Java competitor, if it could only get to be a little faster. At least it's faster than Ruby, Grails, et al.
Maybe not everyone wants to use C# to do system programming and the language fits their needs? It seems a bit far fetched to call the whole thing misguided because it does not fulfill your expectations on a specific area that pretty much everyone knows by now is not its main target.
Ah - there's the rub. Systems programming was one of C#'s original purposes. I never said when the systems coding took place. It was years ago. I would not try it today, it'd be pointless,and quite possibly easier and faster to do in Java, Ruby, Scala, or Lisp, which should say everything you need to know or hear about the state of systems programming in C#, at least on Windows. It's also an indictment of the language itself.