Classic Delphi and .NET book in the making
As I have mentioned earlier, I've been working until recently with tech-editing Jon Shemitz' upcoming book .NET 2.0 for Delphi programmers. The book has been taken a long time to complete, spanning the timeframe from the .NET DCCIL preview compiler to BDS 2006, from .NET 1.0 to .NET 2.0, and from VS 2002 to VS 2005. Due to print-schedule issues, the first books should be available in June 2006.
I may be biased having worked on and off with tech editing the book the last two years. In the end, I even contributed Chapter 10 on the new and improved features of the Delphi language since Delphi 7. Nevertheless, I'm one of the few that have read the book's chapters in their entirety (twice!), so I feel entitled to writing the first review of it ;).
In general, I very much like Jon's candid way if writing. He doesn't just describe how a system or API is working, he wants to figure out and explain why it works that way, how it compares with other technologies (Win32 and Java for instance). He doesn't talk down to us, reading the book rather feels like discussing the issues with a peer programmer.
I think the book will be very relevant for a large number of programmers. It will be useful to both beginners, intermediate and advanced programmers. Clearly, the book is primarily targeted at Win32 Delphi programmers that have or will take the step into the .NET world, or even just wants to have a better understanding of .NET from a Delphi programmer's perspective.
Like .NET itself, the book is primarily language agnostic with example code in C# and Delphi. While the author admits that C# is now his primary .NET language, the right-tool-for-the-job rule still applies. For a quick overview of the sections and chapters in the book, go to the author's book page here.
Conclusion
In my opinion this will be a classic Delphi book, one that should be on almost every Delphi programmer's bookshelf. In many ways it is a more readable, mature and Delphi-friendly version of Jeff Richter's Applied .NET Framework Programming. Note that the book does not cover specific IDE features - instead it gives you a comprehensive and practical understanding of .NET fundamentals, the CLR, the JITer, the memory and threading model, the FCL and the C# and Delphi programming languages.
Highly recommended!
Click here to order your copy at Amazon.
Update:
There have been some misunderstandings about the book's coverage of .NET 2.0 vs Delphi.
While it is true that Delphi does not fully support .NET 2.0 yet, the book is about .NET 2.0 nonetheless. And it is primarily targeted at existing Delphi programmers.
Delphi programmers can still use Delphi to program against .NET 1.1, or they can use C# to program against .NET 2.0. Or they can even use the Delphi command line compiler to compile and run against the .NET 2.0 framework, even though they cannot directly use 2.0 specific features such as generics. (I admit this is a little tricky.)
And when Delphi for .NET 2.0 becomes available, the book will still be highly relevant.
The book is mostly about .NET 2.0 (but it does explicitly mention what is new in 2.0 compared to 1.1), but it is (AFAIK) the only .NET boook from the perspective of a Delphi programmer.
It doesn't contain much IDE specific information (BDS or VS), concentrating more on the .NET foundations, FCL and at the language level of C# *and* Delphi.
The book contains a great deal of Delphi code both in inline samples and as complete online examples. And explanationsxplainations of how to do things in Delphi, how things compare with Win32 Delphi, etc. One chapter (10) is only about the Delphi language changes, for instance.
It will be very relevant for users that wants to:
- Learn about .NET
- Learn about Delphi for .NET (on a language level)
- Learn about how to target .NET with Delphi
- Learn about how to target .NET with C#
- Use the right tool for the job
So it is a very pragmatic book, describing the world as it is, letting the programmer decide what tools he wants to use in each specific situation.
7 comments:
Where did you get the 2.0 in "NET 2.0 for Delphi programmers"? The title is "NET for Delphi programmers". Delphi does not support 2.0 yet.
.NET 2.0 for Delphi programmers is the new title of the book - the image and title has not been updated at Amazon yet. You can see the same title at the author's web page here:
http://www.midnightbeach.com/.net/chapters.html
While it is true that Delphi does not fully support .NET 2.0 yet, the book is about .NET 2.0 nontheless. And it is primarily targeted for existing Delphi programmers.
Delphi programmers can still use Delphi to program against .NET 1.1, or they can use C# to program against .NET 2.0. Or they can even use the Delphi command line compiler to compile and run against the .NET 2.0 framework, even though they cannot directly use 2.0 specific features such as generics. (I admit this is a little tricky.)
And when Delphi for .NET 2.0 becomes avilable, the book will still be highly relevant.
Looking forward to it. Jon Shemitz' book on Kylix development is the best book i have on programming. I absolutely love his style so i'll probably pick this one up also.
Since Amazon hasn't put up my review yet, I'll paste it here...
-------------
Jon Shemitz writes a book that does have lots of good information in it, written from the point of view of a former Delphi programmer. While he does provide a lot of good technical information about .net and compares and contrasts with what Delphi programmers typically do, his book is riddled with his "abandon Delphi" bias.
Examples:
Page 134: "I think you'll agree that C# has a cleaner, more maintainable syntax than Delphi". As someone who has 3+ years of experience writing C#, I can say that I personally don't agree with this statement. It's a matter of opinion. His is no better than mine.
Also on page 134: "The foreach loop eliminates lots of really common boilerplate code" (This sentence immediately follows the previous statement). Could Jon be unaware that Delphi 2005 introduced the for..in syntax to accomplish exactly that same "foreach" functionality? In the context of his opinion that C# is better, he has strayed into the error of apparently not being aware of what is in CURRENT versions of Delphi
Page 41: "One key difference is that in Delphi an event can have zero or one handlers, while a .net event handler can have any number of handlers.". Again, ignoring the fact that Delphi.NET has methods that provide for proper .net multiple listeners to an event. Maybe he mentions this elsewhere in the book, but I haven't found it. At any rate, the reader is left to believe that Delphi is something less than C#.
The Introduction to Part 3 states: "By all means, use Borland's VCL for .net compatibility layer for ports, but use the FCL for new code." Again, more pro-MS bias kicking in here. VCL.NET can continue to support new code development, and more VCL.NET support is on the way, even for Vista compatibility. Jon's "write once, work anywhere" mantra is again surfacing here. The idea is to scare you into thinking that if you don't dump Delphi and VCL.NET, you won't be able to get a job. He has a right to his opinion, but I think he crosses the line with his advocacy here.
He creates chapter titles like "Beyond Delphi", again the implication being that we should leave Delphi behind, whereas the Delphi language is constantly being revved to meet or exceed C# capabilities, AND many of those language enhancements work equally well in Win32 code. This is something Microsoft has NO answer for.
He also muddies the water by not making clear when he uses the term "Delphi" that he's talking about Delphi for Win32, vs. Delphi for .NET. He'll pronounce this or that feature in .net as superior to Delphi. Someone knowledgable in Delphi.net, C# and .net as a whole will know where he's misleading the reader, but someone who is not knowledgeable will be misled into believing that Delphi <> .NET. Yet, he often WILL use Delphi for .NET snippets or discuss Delphi for .NET features. How does one know "which Delphi" he's talking about? It's a catch-22. If you know these technologies thoroughly, you can chew the meat and spit out the bones. If you don't, you have no way of knowing WHICH things he means in .NET are really C# idioms, and which things are universal to all languages in .NET, including Delphi for .NET.
In spite of all the ripping I'm doing on him for being a MS convert/kool-aid drinker/peddler, there IS a lot of meat in the book, and it is definitely worthwhile to check out if you're lost in .net and want to see the technology explained in terms that a Delphi programmer will understand most easily. When he describes this or that feature in .net as being relevant to this or that feature in Delphi, it can be helpful. Just a word of caution. Understand the author's motivation seems designed to drive you out of Delphi and to the 'superior' C# language, even while he disclaims that .net is supposed to be a language-neutral environment. C# has its nice points, but it also has its warts. The same is true for Delphi for .NET. Much is a matter of personal taste. Much of what Jon says is "better" about C# is, again, his personal opinion, and should be taken with a grain of salt, particularly when he states or implies that this or that feature is absent in Delphi. Buyer beware! He may be wrong. Ask in the Delphi public newsgroups before assuming that C# has some feature that you want, but Delphi does not.
The book would have garnered more stars for its technical content if Jon could have set aside his bias.
Ahh, a review from a Delphi bigot. I'm sure I'd have preferred it if Randy had stuck to his original resolve to avoid [my] book like the plague - it's obvious that he was determined to dislike my book.
For example, I thought it was pretty obvious that when I invoke the reader's Delphi experience, I'm referring to native code Delphi's - D7 and earlier. Of course I'm aware that DfN supports a for/in loop and multicast events - but these are not part of a new-to-.NET reader's Delphi experience. No one else seems to be confused by this, which leads me to suspect that Randy's clenched teeth made it hard to pay attention to what he was reading.
I make no bones of my preference for C# over Delphi, despite my years of using Delphi. As Randy says, that's my opinion, and may not be yours. That's why I went to such lengths to have DfN examples in every chapter ... even when those were longer and harder to get working than the equivalent C#.
I do urge you to learn the FCL and only use VCL.NET for ports. The FCL is a great library, with much better collections and string handling than the VCL, and it's sort of silly to ignore the library and use .NET only for its automatic memory management. Besides, FCL skills are a lot more salable than VCL skills - your current employer and your current project won't last forever, and .NET skills will make it easier to find your next job.
Hm, I'm a "Delphi bigot" but you're somehow NOT a "C# Bigot", John?
I particularly like the sleazy tactic of buying Google ad-words so that "Delphi book" gets a google ad called "Can't find a Delphi job?" that directs them to your site.
There's basically no mud you can sling my way for being biased that doesn't also directly apply to you, Jon. You might consider that the next time you throw a stone from within your glass house.
I stand by my review of the book. Good technical information, and for that I give you props. But there's still a anti-Delphi attitude that runs throughout it that would put off anyone who still intends to use Delphi as well as .NET to get their work done.
Randy
>> For example, I thought it was pretty obvious that when I invoke the reader's Delphi experience, I'm referring to native code Delphi's - D7 and earlier. >>
Really? So Delphi's native code is "d7 and earlier"? Last time I checked, D2005, D2006 and D2007 are all native code.
>> Of course I'm aware that DfN supports a for/in loop and multicast events - >>
Then again you are wrong, because Delphi for NATIVE CODE also supports the for..in construct. Your comment above simply puts you deeper in the error hole.
>> No one else seems to be confused by this, which leads me to suspect that Randy's clenched teeth made it hard to pay attention to what he was reading.>>
I paid close enough attention to know that you played fast and loose with the facts, and now you are trying to create spin to make it seem like you didn't err.
Randy
Post a Comment