Slashdot Mirror
Essential .NET, Volume I
After chapter one's history of the evolution from COM to the CLR, the book takes a bottom-up approach to the CLR, starting with a deep and detailed six chapter look into the core elements of the platform. Chapter two begins with assemblies, the programmatic units in the CLR, and the implications of their construction. We learn how they are versioned, loaded and built, and why therefore they may be written in as many .NET languages as required. There's real depth to the material here -- you really do touch the bottom of the abyss, so to speak -- but it's countered with occasional levity that keeps this a readable book instead of a dense reference manual. The same is true of all the text. To wit, there's even some irony; "To allow old dogs to avoid learning new tricks, there is finalization," he declares in the next section on the Common Type System.
It's here that we discover how different types and interfaces are distinguished from themselves and from one another, and how their variations and relationships are kept separate by the CLR. It's refreshing to note that the proverbial big picture is never very far away from the commentary. After taking time to explore the avenues for types and interfaces, Box notes that types themselves aren't very interesting until you start working with instances of those types, and we're off again working through another thirty pages on how object instances preserve a sense of identity, how they are cast into other types and how they incorporate themselves into the concepts of reflection and metadata. Only then do we look at the actual lifecycle of an object, its creation, modification and disposal. The attention to detail is great, and there's little ambiguity in the text, but with that comes a slowness to this section that may leave readers frustrated.
One recurring theme of the book is the idea that while there is a very proper way and set of rules for doing things, there will always be circumstances in application development which call for exceptions to be made to those rules and made possible by .NET. This is true at a small scale and, as chapters six and seven prove, at a large one too, covering as they do how the CLR calls and runs methods first on a single machine and then over a wire. How does the runtime treat methods called explicitly, implicitly through a delegate, asynchronously, or as a combination of the three? How do remote calls and types bridge whatever gaps they must cross and activate the remote objects and methods they're targeting? The answers are here.
Essential .NET reflects Box's pride in .NET and also his slight dissatisfaction with it. You can sense that while he knows .NET version 1 is an improvement over COM, it's not as good as it could be and things are still be done in v2 and beyond. Chapter eight's look at AppDomains and in particular its discourse on threading within and through AppDomains is a good example of this. Meanwhile, we finally come full circle in our investigation of the CLR, seeing how the assemblies we built in Chapter 2 are resolved and executed within AppDomains. Exceptions to rules being included, we also see how objects references are marshaled across AppDomains for inter-application communication if this is required.
The last two chapters look at wider topics around the CLR in as much detail as they can for topics which have entire books dedicated to just them. Chapter nine covers code-access security and chapter ten topics which are not of the CLR but which be can be addressed from within a .NET application: explicit memory management, using p/invoke to import COM methods from DLLs and so on. Both are concisely written and to the point, but unsurprisingly leave you feeling like there's more to these topics than is covered here. Chapter nine is a great and clear introduction to code-level security, for example, but you'll get a lot more out of Michael Howard's book, Writing Secure Code if you want to know more.
Essential .NET isn't an easy read but everyone should try to read it at least once. Focusing on the CLR itself and how it deals with the components of an application means that it truly is aimed at the community of .NET developers as a whole (including those building and using alternate implementations of the CLR). The provided code examples are expressed in C#, but this is incidental, really, and won't stop VB.NET, J# or any other developers getting a great deal out of this book.
This is a dense, complex volume that requires a fair amount of effort to understand and use, and to some extent this may put people off. On the other hand, it is so packed with great nuggets of information that they may be inspired to keep reading. Of course, there is the question of whether this book will actually improve your .NET development skills, but in riposte, you can honestly say that no volume details the CLR and its potential so well, and that this alone is worth the book's cover price.
You can purchase Essential .NET, Volume One from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
how come it's more than one volume?
Je t'aime Stéphanie
Here is the much awaited link to the amazon page from which this comment is stolen.
Were it not for the patents conspicuously taken out to prevent interoperable implementations, this would be true and CLR/C# would be a better alternative than Java.
Java Vs C#
Java and C# = 239, C# = 736 OR 497 for C# alone, Java = 4596 OR 4357 for Java alone, Java Wins outright 4357 to 497.
In fact Java is more in demand than C++ (3081) or Visual Basic ( 2252 )
J2EE Vs .NET .NET = 23, .NET = 1392 or 1369 for .NET alone,
J2EE = 2120 or 2097 for J2EE alone,
J2EE wins by points 2097 to 1369.
J2EE AND
According to theory, .NET should be picking up the bulk of Visual Basic Developers...
.NET WITH Visual Basic,
Visual Basic AND J2EE AND .NET = 5,
Visual Basic AND .NET = 58 or 53 alone,
Visual Basic AND J2EE = 168 or 163 for J2EE alone,
J2EE wins by points 163 to 53.
J2EE With Visual Basic Vs
In comparison to the number of Visual Basic based jobs, there is very little demand for the shift towards the backward incompatable Visual Basic.NET.
According to theory, C# should be picking up the bulk of Visual Basic Developers...
Java With Visual Basic Vs C# WITH Visual Basic
Visual Basic AND Java AND C# = 65, Visual Basic AND C# = 250 or 185 alone, Visual Basic AND Java = 696 or 534 alone, Java wins by points 534 to 185.
According to theory, C# should be picking up the bulk of the C++ developers...
Java With C++ Vs C# WITH C++
C++ AND Java AND C# = 149, C++ AND C# = 311 or 162 alone, C++ AND Java = 1242 or 1093 alone, Java wins outright 1093 to 162.
To use your own words, why don't you come back and post when you have a clue?
If you "don't program in Java or C#", refrain from talking from the top of your head about something you can't know.
And "all this platform compatibility is a moot point" only in your dreams. Java is far from perfect but its cross-platform enough to make it a far superior platform for web and network development in general. Only the very young and inexperient amateurs mock the importance of being able to choose any system running on any hardware for you applications.
C# seems like a very nice programming language, but I really don't give a damn about .NET--as far as I'm concerned, Microsoft has never been able to put together a good set of APIs and .NET doesn't look like that has changed.
What I would like to see is a book on Mono, the core ECMA C# APIs, and the Mono-specific APIs like Gtk#. Is anybody working on that?
The only Java implementations you can get are all based on code licensed from Sun. With the JCP, Sun stifles innovation and progress. And Sun holds numerous patents on Java technologies, making it unlikely that the platform will ever be truly open. With so much control over Java, it is particularly worrisome to see Sun's market evaporate--Sun is a company on the way down, and the question is: what will they do to/with Java before they hit bottom? An SCO-like scenario involving Sun, IBM, and open source implementations seems entirely plausible.
.NET are attempts by two big competitors to establish new proprietary platforms and to do an end-run around open source systems like Linux. If a large fraction of the software on Linux were done in Java, for example, Sun could basically give their own platform an advantage by tinkering with the Java-on-Linux implementation.
.NET compatible set of libraries (which you shouldn't use and which may be encumbered by patents), it is getting its own, native set of APIs.
Both Java and
The solution? Don't use either. Mono may be a way out because, in addition to a
But if you want to avoid the issue altogether, just don't use either Java or C#--there are plenty of good alternatives around. In fact, most software these days should probably be written in languages like Python, with a few core C/C++ libraries for numerical and other high-performance subroutines.
The big difference between the ASP.NET paradigm and that of, say, Java Servlet Pages, or XSP, etc. lies in the event-based nature of ASP.NET pages.
Anyone in the J2EE community looking for similar event-based behavior should be keeping an eye on JavaServer Faces. One big problem is getting it to work on the existing JSP architecture, though, as JSP still has no server-side component model.
Sorry, but this is my first comment, and I dont feel like signing up.
You feel trapped in an all MS house? Try an all Borland house. I used to be pro-borland, semi-anti-MS where it made sense, but Ill tell you what... I would happily murder all of the children of a large household just to be able to use MS tools instead of Borland at my place of work.
As time goes on, they constantly show how much garbage they are.... version after version after version of everything. And good luck finding anything useful on google groups, or anywhere for that matter, if you need some help on something Borland. I find most of the time, if I do find anything, it is post after post of people with the same issues, but never a response.... and the Borland engineers are elitist assholes... to them, their "shit dont stink", and if there is a problem with their software, it must be YOU.
The post was not a troll. the truth about the .Net framework is that it is designed eventually to only alow tcpa key coded web pages to be displayed on an MS browser. Anyone who is stupid enough to think that MS is not in the business of trying to lock up all internet communication deserves what is coming. Something that will make you raise your right arm and alow access to your wallet in salute! Really read this guy he is biased but he is right! http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html
OH THE SHAME I fell off the wagon and use sigs again!
I'm seeing a lot of blind flaming about .net, so here's my overall response. .net (all lowercase, not ".NET") is Microsoft rearchitecting Windows across the board. You don't use the Win32 API any more; you use the .NET libraries. You don't write applications in raw C++ any more, you use C# or another higher-level language that targets the CLR (Microsoft gave advance information to a number of indepdendent language developers, encouraging them to port their products to .net). Security issues caused by low-level buffer overruns have vanished. You get a nice Visual Basic-like environment for creating GUIs. This is all a great idea.
.NET and C# are much better than the Win32 API and C++, there's a general staidness to it all. It feels like we've moved from 1985 to where we should have been in 1994. C# feels wonderful if you're a C++ programmer who never used Turbo Pascal or Visual Basic (or if you're a Turbo Pascal or Visual Basic programmer annoyed with C++), but it feels overly complex if you've used a dynamic language like Python, Smalltalk, or Lisp. The OOPness of .NET is very heavy and static. And it's all still based on a compile-run cycle, which is hard to go back to once you've gotten away from it.
.NET, and even though Microsoft is showing a lot of initiative and is willing to throw out a lot cruft we've all gotten used to, I don't think it's enough. The result is still complex enough and elaborate enough that it's tough to bank on it as the future.
The downside is that while
Personally, even though I think Microsoft is correcting a lot of past mistakes with
Using non-portable languages to write web apps is a very bad idea.
Statement by assertion with no supporting evidence.
C# is a ratified standard.
The other languages you suggested are not.
Maybe you should rewrite your statement "Using languages that I don't like because of religious bias is a very bad idea." It would be more honest.
The red parts are components that Microsoft has not submited to ECMA for standarization and hence have no explicit patent grant. Whether there is an enforceable patent there is unknown, but is dubious, as for the most part they are wrappers to existing technology, or implementations of concepts already available.
;-)
The green parts are components that we have developed outside of the Microsoft world (they do not have a Microsoft equivalent). Whether there are patents or not is uncertain as they are also wrappers for existing technologies (Gtk, Mozilla, etc). Microsoft would certainly not have a Mozilla# patent
Miguel.