It sounds to me like another MS com tool that requires a lot of configuration and is too easy to break: WCF. When it works it works great, but when it doesn't it's very stubborn about it!
Peter Ripley
Posts
-
SignalR sucks -
SignalR sucksThat is very cool!
-
The 1950s called and wanted their toolbox backRasmus Andersson- I'm amazed that the majority of people commenting on your article have a 'what we have is as good as it can get ' mentality. I think from the first line of your article I had a bit of an epiphany--not one that I can fully explain yet and not one that I would dare describe to a seemingly short-sighted group of peers. Several contributors point out that processors execute operations in a sequential manner, and that it 'all comes down to 1s and 0s in the end' or something like that. Well guess what guys, assembly language takes a certain variant of programming discipline to do well. And even at that level, while you are telling the processor to load data and executable code with values in registers from specific memory segments, even assembler is an abstraction. Assembly code is compiled down to the actual bit values that a processor can understand. My point here is that as programming has evolved; we've seen the introduction of object-oriented languages. Yes, of course it still all comes down to bit vales for the processor at run-time, but OO design helps us as HUMANS to take abstract needs and use the concept of classifications (more often than not called classes) to allow ourselves to create solutions for complex real-world business requirements using a much higher level of abstraction. Even modern OSs and run-time platforms help us to abstract with high-level languages because we don't have to worry about handling the threads notifying our applications of events triggered by the user, e.g. button clicks, scroll bar movements, etc. We are to a certain extent freed from a lot of the mundane, thanks to the OS, the compiler and in many cases the run-time support. And let’s not forget the extensive pre-built libraries we have at our disposal. Yes, we have all of the above, better ways to organize software using classes, conceptual tiers for separation of concerns, software designs lending themselves to extensibility and reuse. But as Rasmus points out, we still sit at a console typing text to ‘classify’ much of these pieces of code, and defining how they will interact once they become objects during program execution Text is linear, even when defining classes that may interact in a multidimensional manner when used in an application. We use linear text to describe how multiple threads should run simultaneously. That is certainly an example of using a one-dimensional language to describe a multi-dimensional process. Rasmus Andersson is perhaps a bit too forward-lookin