Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Essential .NET, Volume I 286

Posted by timothy from the from-blog-to-paper dept.
hmobius writes "In a world where developers are baying for customers' attentions, very few people can claim to command that of the developer. Their blogs may be the only clue to the higher level of thinking that they operate at, creating the answers to why and when code works in addition to the perennial how. Whether he likes it or not, Don Box is one such system-meister. He may dislike writing books, but when one comes out, people pay attention and read. His first foray into text, Essential COM, was the book to explain how COM worked, and his latest, Essential .NET, takes the .NET Framework's Common Language Runtime (CLR), and does exactly the same." Read on for the rest of hmobius' review.
Essential .NET, Volume One
author Don Box with Chris Sells
pages 400
publisher Addison Wesley
rating 8/10
reviewer Dan Maharry
ISBN 0201734117
summary Great in-depth look at the CLR, but not for developers aiming to better their skills.

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.
This discussion has been archived. No new comments can be posted.

Essential .NET, Volume I More

Essential .NET, Volume I

Comments Filter:
  • Isn't that an oxymoron?

    (Thank God I got that joke out of the way.)
    • Hoh man, that's the exact first thing that came to my mind too =)

    • Re:Essential .NET? (Score:5, Insightful)

      by tempny ( 602740 ) on Monday July 28, 2003 @01:06PM (#6552479)
      Jeez, as a technical community can't slashdotters resist making dumb jokes that have been made millions of times before and actually pay attention to the content of something that could be relevant to many of us? I want to see a first post that's not an easy and bad joke for once.
      • Who's the more whorish, the whore or the whore that points them out?

        note: the above is not to be taken seriously

  • Slashbot book review. (Score:3, Informative)

    by rkz ( 667993 ) on Monday July 28, 2003 @12:48PM (#6552307) Homepage Journal
    This one is a great addition to the book shelf, you all know how to do certain things with .NET languages but this book clarifies nicely why you are actually doing it. Also, it introduces nice new .NET library/bytecode concepts which hardcore Visual basic 6/VC++ 6 users might not have come across before.

  • Everyone? (Score:4, Funny)

    by Acidic_Diarrhea ( 641390 ) on Monday July 28, 2003 @12:49PM (#6552322) Homepage Journal
    "Essential .NET isn't an easy read but everyone should try to read it at least once."
    Alright, if you say so - I'll give it out as a Christmas present to everyone I know. I don't know how much my butcher will like it; he seems like more of a C# kind of guy.

    Get it? C-sharp? Because he uses knives...and they have to be sharp?

    The important thing is that I am happy with me.

    • Get it? C-sharp? Because he uses knives...and they have to be sharp?

      Yeah, I think that one kinda fell flat.

      Sharp. . . flat. . . get it. . ?

      Oh, nevermind, I'm going home.

  • Nice review (Score:2, Informative)

    by Acidic_Diarrhea ( 641390 )
    This is an excellent book. Richter's "Applied .NET Framework Programing" covers the CLR from the programmers point of view. Lidin's "Inside Microsoft .NET IL Assembler" is a detailed guide to IL, ilasm and the managed PE file format. Don Box's excellent "Essential .NET Volume 1" bridges the gap-- leveraging your knowledge of the CLS to present interesting internal, runtime aspects of the CLR.

    The first couple of chapters do rehash the metadata structure (that is, assemblies, modules and members), which an

    • Re:Nice review (Score:2, Interesting)

      by Anonymous Coward
      Here [amazon.com] is the much awaited link to the amazon page from which this comment is stolen.

    • Re:Nice review (Score:2, Funny)

      by pestie ( 141370 )
      ...leveraging your knowledge of the CLS to present interesting internal, runtime aspects of the CLR.

      CLS? That's easy.

      10 CLS
      20 PRINT "HI MY NAME IS MIKE!!"
      30 GOTO 20

  • Skip this book (Score:3, Funny)

    by donald knuth troll ( 682408 ) on Monday July 28, 2003 @12:53PM (#6552355)
    Donald Knuth will be writing THE definitive book on bytecode languages in TAOCP volumes 11-12. I don't see any reason to dick around with some amateur's feeble attempt.
    • To make it even better, it will all be implemented in three generations of his own bytecode languages, using interpreters and runtime systems implemented in his own 4 different assembly languages for 8 ficticious processors of his own invention, none of which has anything to do whatsoever with the inferior designs and implementations people use in the Real World (TM).

  • uhh (Score:4, Funny)

    by nomadic ( 141991 ) <nomadicworld@ g m a i l . com> on Monday July 28, 2003 @12:54PM (#6552369) Homepage
    Their blogs may be the only clue to the higher level of thinking that they operate at

    Well let's not get delusions of grandeur here...

  • No more spoilers in the reviews! (Score:5, Funny)

    by Anonymous Coward on Monday July 28, 2003 @12:54PM (#6552370)
    Some of us had no idea CLR was going to replace COM. We all wanted COM to die a horrible death and now you've ruined the surprise. On top of that, you give away the fact that .NET is the first of a series. I suspect we won't get a real ending, but a cliffhanger that guarantees we show up for the sequel.

  • Don't Flame So Fast (Score:5, Insightful)

    by RealisticWeb.com ( 557454 ) on Monday July 28, 2003 @01:04PM (#6552458) Homepage
    Before everyone starts scoffing at how much Micro$oft sucks, I just want to say that .NET is really the best product that MS has produced in a very long time. And when I say .NET I am referring to both the object library and the .NET server.
    I'm with the rest of /. when I say that I would rather be on a UNIX based platform, but like many of you due to my job I am forced to deal with a Windows Server environment if I like it or not, and as much as I have tried to hate it, I have actually been quite impressed with what you can do with Visual Studio and .NET
    When you write a .NET web application you use the same code (meaning VB.NET, C# etc, as opposed to ASP, or VB Script) that you would use when writing a desktop app, and the fist time the page is accessed, the web server compiles all the code into dll's on the fly. Converting my existing ASP apps into .NET has tripled the performance using the same hardware. This method is very very fast. Fast to develop and fast to benchmark. It would take me months to write a C/C++ cgi app to do the same thing that I can pump out in an afternoon with VB.NET. And more intuitive I might add.

    Go ahead and flame me now.

    • Re:Don't Flame So Fast (Score:5, Informative)

      by JeanBaptiste ( 537955 ) on Monday July 28, 2003 @01:18PM (#6552569)
      When you write a .NET web application you use the same code (meaning VB.NET, C# etc, as opposed to ASP, or VB Script) that you would use when writing a desktop app,


      I also like .NET, it is the first good thing they have put in a while, it beats the hell out of COM...
      but your statement is not quite correct, unless I am not fully informed which is definately a possibility.... I have been finding more and more differences between programming for .aspx versus a standard desktop application... Still it beats the heck out of VS6...

      • Event Based Page Model (Score:5, Informative)

        by Anonymous Coward on Monday July 28, 2003 @01:35PM (#6552708)
        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.

        Each ASP.NET page is an instance of the "Page" class, or one of its sub-classes. The "Page Lifecycle" defines the various phases that apply each time a page is accessed. The "Page" is simply the top-level node in the "control tree", and each control in the tree does the following for all its children (recursively):
        1. initialization
        2. handle postback data
        3. state management
        4. handle events
        5. pre-render stuff
        6. render to HTML (or whatever)
        7. clean up

        Most of your code will pertain to numbers 4 and 5 above, if done correctly.

        It's not immediately intuitive, coming from a Web App developer's perspective, but does provide a good general structure and mechanism.

        In addition, each Page is split into its actual class (the so-called "code-behind page"), and its representation as markup (the .aspx page). The .aspx page is parsed on each request, but the code-behing is pre-compiled.

        ASP.NET provides a robust programming model for web applications, but it also provides a lot of built-in mechanisms for doing common stuff. Authentication, Authorization, Caching, DataBinding, XML, conditional rendering, templating, data access through ADO.NET, internationalization, Debugging and Tracing utilities, and more.

        That said, I find the event-based programming model quite difficult to master. If used improperly, you can end up running the same code many times; for instance of you populate a given control (say a dropdown) from a database, and do so in response to many different events. Better to flag things and then fetch just once from the DB prior to rendering.

        Thoughts?

        PS: At the moment, you can't mix multiple languages (C#, VB.NET) within a single Web App.

        • Re:Event Based Page Model (Score:4, Informative)

          by gludington ( 101178 ) on Monday July 28, 2003 @02:44PM (#6553213)

          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.

          Each ASP.NET page is an instance of the "Page" class, or one of its sub-classes.

          This is not a new invention of .NET, as these concepts go at least as far back as Java Server Pages. Every JSP page implements JspPage (or HttpJspPage), and follows roughly the same lifecycle. The container typically provides that JspPage class, though a developer can roll his/her own, as well. (Before people jump all over me, yes, in the Java world, people rarely put the page as the top controlling object, preferring to use a Servlet as the controller and the JSPs only to render the final view.)

          This is not to take anything away from .aspx -- some of it is quite nifty -- but the basic concept of a "Page" object and "Page Lifecycle" is not new to .NET; Java has had it for a while, and I am sure some geek out there will point out even older examples.

        • 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 [sun.com]. One big problem is getting it to work on the existing JSP architecture, though, as JSP still has no server-side component model.
        • PS: At the moment, you can't mix multiple languages (C#, VB.NET) within a single Web App

          No, and I'm not sure why you'd want to exactly, as it would be better perhaps just to pick one language and stick with it. However, if you had a need to use both, you could encapsulate say C# code behind a web service (simple to do in .NET) and call from VB. If everything is on the same box, there shouldn't be any additional overhead.

    • Let us flame it slowly then... (Score:4, Insightful)

      by Pac ( 9516 ) <paulo...candido@@@gmail...com> on Monday July 28, 2003 @01:34PM (#6552691)
      You should always write web application using a platform that allows you to use the same infra-structure you use for desktop application. Besides the learning curve problem, it also helps when you wnat to mix them both ("weblize" a destop app, for instance).

      That said, ASP and VB.NET are not the answer. Using non-portable languages to write web apps is a very bad idea.

      It would take me months to write a C/C++ cgi app

      Where are you from, 1994? If you really need unmantainable spagetthi like ASP, you can use PHP (portable across all known platforms), but you have Java (Tomcat) and Python (Zope) that allow you to use very high-level structures with a higher productivity (in my experience) than any Windows-only solution. No one writes C cgis anymore...
      • 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.
        • If you were not there to see the evidence with your own eyes during the dotcom crazy you missed a nice trip. Kids would start their sites in Windows 98 home machines, grow it to NT servers with the money that feel from the sky every even day and eventually notice they would need a farm of those or a Solaris box. So the CEO kid would buy the Solaris box and tell the devs: "Put our site here over the weekend, will you?".

          I couldn't care less for a Windows-only ratified standard. It is not religious if my com

    • Re:Don't Flame So Fast (Score:2, Insightful)

      by Anonymous Coward
      it's because it's a repackaged Java, reimplementing concepts and ideas that Sun (and others) has come up with for the past 7 years.

      believe me, if you've used both, you'll catch the striking similarities.
    • I have actually been quite impressed with what you can do with Visual Studio and .NET

      And what can you do with this that you can't do with JBuilder or WebLogic Workshop? You do realize that these tools can create portals, workflow and web service systems using drag-and-drop? I'd be interested to see if all this was really in VS.NET.
      • There really isn't much, if anything, one can do in .Net that you could not do in JBuilder, Workshop, or Eclipse, etc. The relevant point to make to much of the /. audience is that the relationship is largely bi-directional.

  • MS hijacks the name of a top-level domain... (Score:2, Informative)

    by Anonymous Coward
    ...The idea of some marketing guy noticing that his ISP's address ends in ".net" and thinking "Gee, what a cool way to align my marketing message with the corporate flavor-of-the-week"--or however it originated--is so intensely irritating to me that .NET could be the greatest thing in the world and I still wouldn't want to learn about it.

    I never did find out what "Microsoft BackOffice" and digital_nervous_system were supposed to mean. My guess is that I won't need to find out what .NET means, either.

    Actua

  • Box on .NET (Score:4, Informative)

    by mrkurt ( 613936 ) on Monday July 28, 2003 @01:07PM (#6552491) Journal


    You can sense that while he [Don Box] 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


    This could be an interesting read. The reviewer's comment on Box's impression of .NET confirms the wisdom of my decision not to be an early adopter of .NET, if I take it up at all. Although Box is a MS-centric developer, he discusses the issues involved in app development with candor as well as detail.



  • Structure overload (Score:3, Insightful)

    by Tablizer ( 95088 ) on Monday July 28, 2003 @01:08PM (#6552494) Journal
    You know, the "registries" and "assemblies" are getting so complex that I would rather they be stored and managed in a relational database. The rules and tools for relational databases are better understood and apply to many areas, reducing one's learning curve and let's them use existing tools to analyze data and structures. I can look at the schemas and data dictionaries (schemas with extra info, such as field descriptions), and fairly quickly get a feel for how the different entities work and relate to each other.

    A proprietary structure just ends up reinventing a lot of database wheels like concurrency, backups, change logging, etc., and has unfamiliar access protocols, often mirroring the "navigational databases" of the 1960's.

    I know, some of you say that I have an "if all you have is a hammer, then everything is a nail" view about RDBMS (relational databases), but when structures become non-trivial, then nothing beats a RDBMS in most cases. If it walks like a database and quacks like a database, then perhaps it is time to use a database.
    • And your general approach. From what I've heard Longhorn will do this with the filesystem, but I haven't heard anything about registry.

      Bloated registries with old, invalid data are one of the main places to cause windows problems. I find left over keys after doing the manufacturer uninstall all the time. Tying the registry record to the core application record in the new filesystem seems like a simple way to enforce referential integrity here at the one place where the lack of it causes so many headache

  • Monster Tech-en developer demand tag team match (Score:3, Interesting)

    by NZheretic ( 23872 ) on Monday July 28, 2003 @01:14PM (#6552537) Homepage Journal
    Based upon job keyword searches on Monster.com, the most of the demand is still moving towards Java and J2EE. Lets play Monster Tech-en developer demand tag team over the last 31 days.

    Java Vs C#
    Java and C# = 239 [monster.com], C# = 736 [monster.com] OR 497 for C# alone, Java = 4596 [monster.com] OR 4357 for Java alone, Java Wins outright 4357 to 497.

    In fact Java is more in demand than C++ (3081) [monster.com] or Visual Basic ( 2252 ) [monster.com]

    J2EE Vs .NET
    J2EE AND .NET = 23 [monster.com], .NET = 1392 [monster.com] or 1369 for .NET alone, J2EE = 2120 [monster.com] or 2097 for J2EE alone, J2EE wins by points 2097 to 1369.

    According to theory, .NET should be picking up the bulk of Visual Basic Developers...
    J2EE With Visual Basic Vs .NET WITH Visual Basic, Visual Basic AND J2EE AND .NET = 5 [monster.com], Visual Basic AND .NET = 58 [monster.com] or 53 alone, Visual Basic AND J2EE = 168 [monster.com] or 163 for J2EE alone, J2EE wins by points 163 to 53.

    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 [monster.com].

    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 [monster.com], Visual Basic AND C# = 250 [monster.com] or 185 alone, Visual Basic AND Java = 696 [monster.com] 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 [monster.com], C++ AND C# = 311 [monster.com] or 162 alone, C++ AND Java = 1242 [monster.com] or 1093 alone, Java wins outright 1093 to 162.

    • Java wins the "buzz word war" outright because it is an inucmbant platform with solid marketing for the past 5+ years. .NET is a new platform (about 1 year after release) that has not been adopted by most of the Microsoft clientelle.

      Lets revisit these results in two years.
      Considering M$'s deep pockets and commitment to .NET, I think an "upset" is in order.
    • This guy did some actual WORK and posted links. And we have mindless moderators pulling THIS kind of crap.

      I sincerely hope I get a chance to meta-mod these...

      I really do

    • Java is also in trouble (Score:5, Interesting)

      by 73939133 ( 676561 ) on Monday July 28, 2003 @02:04PM (#6552933)
      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.

      Both Java and .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.

      The solution? Don't use either. Mono may be a way out because, in addition to a .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.

      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.

    • Re:Monster Tech-en developer demand tag team match (Score:4, Interesting)

      by PhxBlue ( 562201 ) on Monday July 28, 2003 @02:06PM (#6552952) Homepage Journal

      I'd expected a search for COBOL to turn up a lot of hits, perhaps even more then Java. :) I was pleasantly surprised to find that COBOL only scored about 620 total hits. I don't know what perspective that adds, but it actually outweighs the C# positions.

    • Considering... (Score:4, Insightful)

      by OS24Ever ( 245667 ) * <trekkie@nomorestars.com> on Monday July 28, 2003 @02:31PM (#6553119) Homepage Journal
      ...that some companies still have 'Windows 5.0' on their sheets as lists of systems with operating experience, I don't see how this is relavent.

      Right now 'Java' is the en vogue thing to ask for on a resume. C# hasn't reached that level yet. It's still a buzzword to the HR types.
    • Of course, it is also possible that it takes 10 times as many Java developers to get the same job done.

      Just kidding...

  • At least this review didn't give away the ending [slashdot.org].

  • Essential Mono (Score:3, Interesting)

    by 73939133 ( 676561 ) on Monday July 28, 2003 @01:57PM (#6552873)
    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?

    • Re:Essential Mono (Score:5, Informative)

      by miguel ( 7116 ) on Monday July 28, 2003 @02:49PM (#6553234) Homepage
      Various publishers are working on books about Mono that will cover exactly what you want.

      But everything you learn in Don's Essential .NET book applies directly to Mono. In fact, before Don joined Microsoft, he was kind enough to let us preview his book, and that helped us understand various internals of the .NET framework.

      Miguel.
      • The fact that Mono developers had to resort to a general "HOW TO" guide to figure out details of the Dotnet implementation should set at least some people's alarm bells ringing.

        (Assuming of course that they've overcome the shock of discovering that the bulk of Dotnet isn't published, specified or standardized at all, despite all that hype about ECMA).

        Contrast this with Java, where we get a proper set of specifications and test suites, or with Perl/Parrot, where we get to write our own!

  • Isn't imitation the sincerest form of flattery? (Score:5, Insightful)

    by dot niet ( 629871 ) <MplsCpl@yahoo.com> on Monday July 28, 2003 @02:06PM (#6552955)
    I'll take umbrage with the kneejerk "Java has been doing this for years" comments. Must every idea be so mind-bendingly unique to be deemed useful? Should we all start buying Ford Model-A cars instead of Durangos (or whatever) because Henry Ford "was doing that 100 years ago!"? Are the CLR-based language features a lot like Java? Yes. Should every derivative product be denounced as coming to the table too late? I think not. Once more, .NET ( the bits for developers anyway) brings some better things to the table as well (as evidenced by Sun getting into the leapfrog game with Java v.Next features - Metadata (Attributes), etc).
    • Imitation is flattery, but imitation without acknowledgement is plagiarism. Microsoft appear (at the very least) to strongly discourage their employees from discussing how much .NET owes to the Java platform and how much C# owes to the Java language, even though anyone who knows Java can see that 80-90% of C# came directly from Java.

      It's good that C# is competition, in some domains, for Java, and seems to have pushed Java's evolution forwards (new features for Java 1.5 are similar to things in C#).

      In th
    • Do you?

      I take umbrage with people making claims about "standardization" which turn out to be false, so tempting me to invest in a platform that will lead me into either

      a) a half-baked solution than doesn't give me true portability (and it only takes one missing API to cost me bigtime)

      or

      b) causing me to infringe patents owned by Microsoft, which were expressly designed to prevent cloning and are likely to be enforced.

      We already have two excellent open-source VM projects (Perl and Kaffe), and a wealth of
  • They're running out of common terms to steal and obfuscate, aren't they?

  • Ummmmm (Score:2)

    by Goody ( 23843 )
    In a world where developers are baying for customers' attentions, very few people can claim to command that of the developer. Their blogs may be the only clue to the higher level of thinking that they operate at, creating the answers to why and when code works in addition to the perennial how

    (Score: -5, Please pass the doobie over here )

  • Good book. (Score:5, Informative)

    by miguel ( 7116 ) on Monday July 28, 2003 @02:37PM (#6553164) Homepage
    This is one of the best .NET books, the first of a series of pretty good books, by those involved deeply with the framework.

    This book covers the technicalities in the .NET framework, and is of special interest if you are interested in the advanced features of the Common Language Runtime like method interception, transparent proxies, application domains and metadata.

    Compiler writers, framework developers and those who need to get the most out of the framework will be interested in this title.

    I can not recommend this book enough. Don has done a fantastic job. It helped the Mono developers understand the low-level technical features of the framework.

    Miguel.
  • 99 little buttons to push on my screen 99 little buttons to push
    Mouse one down and push it around 98 little buttons to push
    (repeat 98 times)
    There are no more little buttons to mouse on my screen no more buttons to mouse. My mouse it is hung and just for some fun I'll cfdisk the whole fucking thing!

  • Response to blind criticisms of .NET (Score:4, Interesting)

    by Junks Jerzey ( 54586 ) on Monday July 28, 2003 @03:52PM (#6553641)
    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.

    The downside is that while .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.

    Personally, even though I think Microsoft is correcting a lot of past mistakes with .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.
  • oxymoron n. - words whose meanings contradict each other


    Hmmm, Essential .NET?

  • Essential COM
    Essential .NET

    So what's next, Essential .ORG and Essential .GOV?

Slashdot Top Deals

"I got everybody to pay up front...then I blew up their planet." "Now why didn't I think of that?" -- Post Bros. Comics

Close