[prev] [thread] [next] [lurker] [Date index for 2006/12/27]
On Wed, Dec 27, 2006 at 11:57:15AM +0200, Yossi Kreinin wrote: > From the words you've accidentally forgot to delete, I sense that you > dislike C#. Is this based on experience or on the fact that it comes from > Microsoft? You know, they say the German highways built at the time of > Hitler are still decent highways. I read it as an indictment of fadism and unthinking worship of "progress" which is really just "change" at the expense of reliability. Which is a pretty fair target. But you're right. Managed environments may pay real dividends over time, even if Visual .Net shits the bed and forgets its dependency rules regularly when I use it. > Aaron J. Grier wrote: > >why aren't you playing^Wdeveloping in C#? > [...] > 2. I haven't look into it, but I assume that .NET implementations outside > of Windows have a quality below the level where you can hope to get > "portable" code (and by "portable", I mean running on Windows & Un*x). Oh, wow, this is a whole arena of hate. I can't really do it justice but I'll provide some tidbits. You speak of the .Net reimplementations, such as GNU Portable.Net and Mono. When I tried Portable.Net, it was FILLED with classes and implmentations which could not ever have worked. Things like an object with an update function that overwrites your data instead of the object's data. Good times. It was also slow enough to fall into the Python category, which is okay for some tasks, but Python is way more productive and portable, so it didn't seem worthwhile to use Portable.Net at the time. Mono had a working CIL compiler and CIL runtime with JIT that performed pretty well, so it worked for our purposes. Well, sort of. One problem with .Net is it sort of makes noises about providing a portable api, but it mainly does this by insisting on (stupid) win32 semantics. For example, the win32 file locking behavior we went round and round about is now exported to Unix, lest .Net programs fall over when running on non-windows. Another example of this would be the DirWatcher class, which provides an abstraction over something like inotify. You tell DirWatcher that you want to know about changes to a certain set of files, and then it tells you when changes have occurred via a callback, freeing you from implementing obnoxious polling, and probably doing obnoxious polling itself in many cases. But maybe doing something smarter sometimes. This is really nice functionality for a lot of purposes. The problem with DirWatcher is that you specify what things you are interested in with a glob expression. The ECMA spec says that the default expression is "*.*". The fun part is that the ECMA spec does not tell you what "*.*" means. You could presume you should use native globbing behavior, which would make your applications nonportable. "*.*" matches anything on windows, and only files with a dot on Unix. (I have no idea what Mac developers think about such expressions.) You can simply refuse to implement the spec and default to "*" on Unix, assuming the intended default is to notice all changes in the directory, even though this is not what the spec states. But then what do you do when a program passes in "*.*" explicitly? Is it possible to do anything sane here? Please note of course that the actual behavior of windows globbing (in its full details) is not specified anywhere, varies across windows versions, and is defined by its behavior. There are other issues with .Net. It's a leaky win32 abstraction. To Microsoft's credit, they are removing some of the leaks as they reimplement the interfaces repeatedly, CADT style. So maybe this will become less of a problem over time. But Mono itself is a true joy. Because Mono has to implement all these "system level" semantics that don't exist on unix, it has to create a sort of pseudo-system-wide layer itself. This means that all your Mono processes have to be able to talk to each other. The way it does this is the first Mono prcess you launch is not really your process. It is a "handler daemon", which in turn runs your process. The life of this "handler" wil be the time that you are still running any Mono tasks. This makes launching and managing pids in normal unix ways a real fun task for Mono tools, but that is easily worked around. The fun part about the handler daemon is that it communicates to its spawn through a socket and some other mumble in a fixed path from $HOME ($HOME/.wapi/mumble if I remember correctly). Thus if you want to run Mono tasks under accounts that do not have their own private $HOME dir, they tend to crash and burn. But that's not all, because Mono isn't fully baked, the handler daemon sometimes gets wedged. In this case, every Mono task communicating with the daemon will also wedge. Recovery is accomplished by manually killing all the processes. This is especially graceful because Mono cannot map signals into .Net in a portable way. I don't remember whether it doesn't support them all, or only in Mono specific way, which was unfortunately not allowed in the hateful time that I used Mono. But is this wedging behavior common? I mean, does it really happen so frequently? Well, the communications api breaks is incompatable across versions of Mono. This means that you can never run two versions of Mono in the same account at the same time. Like say when you are in the process of upgrading to resolve a bug. If you do something foolish - like try to build the new version of Mono, which requires launch Mono for part of the build process - all Mono instances, old and new will lock up. I think there was even some extra joy of some sort that the build, halting abruptly in the middle required some manual cleanup after killing off all the Mono processes. But the _best_ part was that after you managed to wedge all your Mono processes, and had to send them all a kill -TERM (or was it -KILL?), newly launched Mono processes (like say from cron), would also wedge. You had to ensure all Mono processes were exited, and then rm -r that $HOME/.wapi, before any Mono programs would ever work again. This, my friends is the future of Enterprise Class development. [irrelevant to the rest] > On the other hand, someone can get so good at grepping around the > filesystem that definition lookup doesn't look like a win. Some people > prefer to create digital images by manually setting one pixel at a > time, and if they are good at it, that's fine. The definition lookup facilities of emacs, vi, whatever other time-honored tool, may be clumsy in some ways, but they certainly have existed longer than Visual Studio. These days they have all the _capabilities_ of something like intellisense, even if the usability of them is open for debate. -joshThere's stuff above here
Generated at 03:02 on 01 Jan 2007 by mariachi 0.52