Slashdot Mirror
Head First C#
Michael J. Ross writes "For computer programmers who do not have a solid understanding of object-oriented programming (OOP), learning the C# programming language can be rather challenging, even if they have experience with C or C++, which at least would give them a head start over non-C programmers. Any developer in this situation may well want to begin the learning process with a book that aims to teach both OOP and C# in as gentle a manner as possible, with plenty of patient explanations and illustrative diagrams — such as those found in the book Head First C# by Andrew Stellman and Jennifer Greene." Read below for the rest of Michael's review.
Head First C#
author
Andrew Stellman and Jennifer Greene
pages
778
publisher
O'Reilly Media
rating
7/10
reviewer
Michael J. Ross with Greg Hanson
ISBN
0596514824
summary
A heavily illustrated intro to object-oriented programming and C#
Published by O'Reilly Media on 26 November 2007, under the ISBNs 0596514824 and 978-0596514822, Head First C# is one in a series of "Brain-Friendly Guides." The introduction to this particular book discusses how the series attempts to present the concepts and technical material in a way that is far more intellectually compelling and memorable than the approach currently taken by most books. Some of their guiding principles include: making things visual, oftentimes using novel and even outlandish diagrams; using a casual and conversational style; engaging the reader through exercises and questions; and spicing up the discussions with humor.
On the book's Web page, readers will find links to download the book's sample code, participate in a forum dedicated to the book, register their copy of the book, read and submit any errata (of which there are many), and submit a reader review and read those of other readers.
The book's material is organized into 15 chapters, covering the topics in a progressive order that would probably be most helpful for the inexperienced developer: the advantages to programming visual applications in C# and the Microsoft Visual Studio integrated development environment (IDE); building a simple application to get started; the C# code produced by Visual Studio; basic C# language constructs; an introduction to objects and their components; data types, including arrays and references, and how C# allows you to work with them; protecting an object's data from unintended access, through encapsulation; extending classes through inheritance and subclasses; finding and using class interfaces, and the advantages of doing so; storing data in arrays, lists, and dictionaries; saving data in files and directories, as well as working with file streams and serialization; exceptions and debugging techniques; event handling; how to build complex applications; creating user interfaces with controls and graphics; object destruction and garbage collection; and connecting your C# programs to databases using LINQ. Interspersed throughout the book are three C# labs, which encourage the reader to put into practice their new programming skills, and thus better internalize the ideas of OOP and C# covered in the chapters preceding each lab. The lab applications comprise a racetrack simulator, a simple adventure game, and a re-creation of Space Invaders.
When they see this book for the first time, some prospective readers may be overwhelmed by its size, clocking in at 778 pages. Yet a sizable portion of those pages will read faster than those of the typical programming book, largely due to all of the diagrams and whitespace, which really help to break up the material and make it more digestible. However, what many might perceive to be a strength of the book, could be seen as a weakness by others. In fact, if the unnecessary diagrams and redundant material were to be removed from the book, it might end up only half its current size. But this may only be a deterrent for people who are carrying this book around, or who tend to be impatient and wish to get right to the point of any book they are reading, or who may be upset by the extra trees chopped down to double the number of pages (the book does not appear to have been printed on recycled paper).
Despite Head First C# being clearly intended as an introductory book to object-oriented programming in general, and C# in particular, the target audience especially may be frustrated by all of the errata and other sources of confusion that they will encounter. This is especially true when readers are doing their best to implement all of the sample applications, and struggling when, for instance, the code does not match the figure provided, or even the code on another page. For example, on page 50, the authors instruct the reader to drag a new PictureBox onto a new form, but readers will probably struggle to figure out where to drag it from. On page 105, the authors instruct the reader to flip back and look through the code, to fill in some class diagrams, but they don't clarify what code should be considered. Readers' comments on the online bookseller sites, list far more similar problems. In fact, that there are so many technical errors in this book is quite remarkable given that the technical review team comprised no fewer than 14 individuals! How could so many eyeballs miss so much?
The authors make a real point of reviewing material explained earlier, which generally is an effective approach for this type of book. But the repetition sometimes becomes excessive — enough to annoy even the greenest novice. For example, on page 445, we find the question: "Okay, I still don't get it. Sorry. Why are there so many different kinds of exceptions, again?"
On the other hand, the book has some real strengths, including those mentioned above for making the material more approachable. In particular, when the reader becomes accustomed to the visual style of presenting concepts, he or she will probably find it a faster approach to learning the ideas. Admittedly, veteran developers may still prefer the more narrative style of conventional programming books — especially when they encounter rather convoluted diagrams, such as that on page 292. Yet the illustrations are particularly potent for explaining interfaces, as done in Chapter 7.
Although the book will be of most value to newer programmers, experienced C# programmers will find topics of interest and perhaps even some language details and analysis that they have never previously encountered. For instance, some of the questions posed in the sections titled "there are no Dumb Questions," could be valuable — such as the comparison of File versus FileInfo, and when to use one over the other. Also, some of the utilities could help the reader for future development, such as the hex dumper program on page 432.
Sadly, Head First C# is weighed down by excessive redundancy and an errata-to-number-of-technical-reviewers ratio possibly unequaled by any other programming book. Yet, for any programmer new to object orientation and C#, this introductory book should prove an extremely comprehensible and reader-friendly resource.
Michael J. Ross is a Web developer, writer, and freelance editor. Contributor Greg Hanson is a C# programmer in Fort Collins, Colorado.
You can purchase Head First C# from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
On the book's Web page, readers will find links to download the book's sample code, participate in a forum dedicated to the book, register their copy of the book, read and submit any errata (of which there are many), and submit a reader review and read those of other readers.
The book's material is organized into 15 chapters, covering the topics in a progressive order that would probably be most helpful for the inexperienced developer: the advantages to programming visual applications in C# and the Microsoft Visual Studio integrated development environment (IDE); building a simple application to get started; the C# code produced by Visual Studio; basic C# language constructs; an introduction to objects and their components; data types, including arrays and references, and how C# allows you to work with them; protecting an object's data from unintended access, through encapsulation; extending classes through inheritance and subclasses; finding and using class interfaces, and the advantages of doing so; storing data in arrays, lists, and dictionaries; saving data in files and directories, as well as working with file streams and serialization; exceptions and debugging techniques; event handling; how to build complex applications; creating user interfaces with controls and graphics; object destruction and garbage collection; and connecting your C# programs to databases using LINQ. Interspersed throughout the book are three C# labs, which encourage the reader to put into practice their new programming skills, and thus better internalize the ideas of OOP and C# covered in the chapters preceding each lab. The lab applications comprise a racetrack simulator, a simple adventure game, and a re-creation of Space Invaders.
When they see this book for the first time, some prospective readers may be overwhelmed by its size, clocking in at 778 pages. Yet a sizable portion of those pages will read faster than those of the typical programming book, largely due to all of the diagrams and whitespace, which really help to break up the material and make it more digestible. However, what many might perceive to be a strength of the book, could be seen as a weakness by others. In fact, if the unnecessary diagrams and redundant material were to be removed from the book, it might end up only half its current size. But this may only be a deterrent for people who are carrying this book around, or who tend to be impatient and wish to get right to the point of any book they are reading, or who may be upset by the extra trees chopped down to double the number of pages (the book does not appear to have been printed on recycled paper).
Despite Head First C# being clearly intended as an introductory book to object-oriented programming in general, and C# in particular, the target audience especially may be frustrated by all of the errata and other sources of confusion that they will encounter. This is especially true when readers are doing their best to implement all of the sample applications, and struggling when, for instance, the code does not match the figure provided, or even the code on another page. For example, on page 50, the authors instruct the reader to drag a new PictureBox onto a new form, but readers will probably struggle to figure out where to drag it from. On page 105, the authors instruct the reader to flip back and look through the code, to fill in some class diagrams, but they don't clarify what code should be considered. Readers' comments on the online bookseller sites, list far more similar problems. In fact, that there are so many technical errors in this book is quite remarkable given that the technical review team comprised no fewer than 14 individuals! How could so many eyeballs miss so much?
The authors make a real point of reviewing material explained earlier, which generally is an effective approach for this type of book. But the repetition sometimes becomes excessive — enough to annoy even the greenest novice. For example, on page 445, we find the question: "Okay, I still don't get it. Sorry. Why are there so many different kinds of exceptions, again?"
On the other hand, the book has some real strengths, including those mentioned above for making the material more approachable. In particular, when the reader becomes accustomed to the visual style of presenting concepts, he or she will probably find it a faster approach to learning the ideas. Admittedly, veteran developers may still prefer the more narrative style of conventional programming books — especially when they encounter rather convoluted diagrams, such as that on page 292. Yet the illustrations are particularly potent for explaining interfaces, as done in Chapter 7.
Although the book will be of most value to newer programmers, experienced C# programmers will find topics of interest and perhaps even some language details and analysis that they have never previously encountered. For instance, some of the questions posed in the sections titled "there are no Dumb Questions," could be valuable — such as the comparison of File versus FileInfo, and when to use one over the other. Also, some of the utilities could help the reader for future development, such as the hex dumper program on page 432.
Sadly, Head First C# is weighed down by excessive redundancy and an errata-to-number-of-technical-reviewers ratio possibly unequaled by any other programming book. Yet, for any programmer new to object orientation and C#, this introductory book should prove an extremely comprehensible and reader-friendly resource.
Michael J. Ross is a Web developer, writer, and freelance editor. Contributor Greg Hanson is a C# programmer in Fort Collins, Colorado.
You can purchase Head First C# from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Ouch, my eyeball!
and C and C++ are all good languages, but I like C@!&$. It's the $h!7.
Look where all this talking got us, baby.
Granted, in this case I don't know the language C#, but in general I never really understood the Head First series, unless you really like printed introductions to languages. It would just make more sense to use free Internet resources to take your first steps in C#, and then get O'Reilly's e.g. C# 3.0 in a Nutshell as a good desk reference. Tech books are expensive, so it just doesn't make sense to invest in a primer that, after you finish with it, is a paperweight.
This book happens to be in our club's collection. Someone gave it to us, I think I found it redundant, and times. but then, most language-centered programming books are, to a certain extent. The first person in our group who read it went through and hi-lighted the page numbers with redundant material on them in blue, and hi-lighted the important pages in yellow. We were able to learn the language's syntax and nuances without reading through long-winded explanations about core concepts in OO or reviews of concepts just covered that way. Generally, I've always found the "language bible" books more helpful than these types of books. Does anyone share my sentiment?
I always loved this series of books. My professor recommended this book to me and it has helped me understand the language much better then any other book. It's interesting, funny, and insightful! A very different take on presenting material then other programing books. As a college student I have a hard time reading through dull school text books. Sometimes I don't even have to open or own a text book in order to get through the class. Although you don't need to buy a book anymore to learn a language with the huge resources the internet has to offer.
A few years ago, when I was relatively new to programming, I read Head First Java and that really helped me understand the Java language and OOP in Java. Even if you aren't a beginner, the Head First books are still pretty decent, but make sure you have patience because most of the explanations/examples are "dumbed down" for the beginner. Also the harder stuff tends to be at the end of the book, so you can hold out for that.
As an experienced programmer looking for a friendly intro to C#, I have enjoyed it, but I would have to concur that O'Reilly's C# in a Nutshell will be my day in day out reference. But, I am glad that O'Reilly is coming out with these user friendly references that make new concepts/languages more entertaining and fun. Head First Design Patterns is another one that some may fine easier to handle than the traditional Gang of Four book.
Yet, for any programmer new to object orientation...
How many can there be left these days?!? It's too easy to accumulate enough material for a good-sized book by starting from scratch and assuming the reader only knows how to read. Anyone could write a beginner's book on a computer language, without knowing the language too in depth, by just padding it with lots of remedial review material, that 99% of the readers don't need and don't want (to wade thru or pay for).
Attention zealots and haters: 00100 00100
I have read the OOP book in this series and I learned lots from it. I had done PHP in a very non-OOP way, so seeing this book, visually, and having many examples that I could relate to really helped me learn fast. It was easy to understand and easy to read. It was repetitive, but that was helpful for me. It also showed different methods/scenarios for using the same principle, helpful if you don't understand why/how a certain thing works - as seeing it from different angles can help understanding. The HeadFirst series is easy to read, yet can teach "advanced" concepts with relative ease. It was a great help for me learning OOP, and I will most likely but this C# book. It is sad to hear about all the errata, but the idea/message will get through. I was bummed I wanted to comment, because I also wanted to mod the parent up, oh well...now you all can enjoy my 10 cents.
Why must a well designed language be challenging?
I came at Java with some C plus some experience with a (proprietary) object oriented AI system. Java was trivially easy to pick up.
Have gnu, will travel.
Slow readers? It's just a guess.
Dedicated Cthulhu Cultist since 4523 BC.
but this particular book doesn't do anyone any favors unless they are an absolute beginner. I picked it up when I started my current position (.NET shop, lots of C# and *shudder* classic ASP using VBScript) mainly because their books on Design Patterns and Servlets and JSPs were decent. I quickly discovered that if you know just about any other C-style variant that C# is a snap to pick up. This book does a great job of hand-holding and providing lots of examples of classic OO concepts, but I would never use it as a desk reference. Their style works very well for subjects which take some thought to wrap your head around (such as design patterns), but there is entirely too much noise to signal for learning a language for my taste. Personally I'd rather have quick access to the language reference and the pertinent APIs, but I suppose if someone was just getting started this book might be appropriate.
God, schmod. I want my monkey man!
Anonymous delegates came out in C# 2.0 (I think), and now we have lambda expressions. Umpteen ways to do delegates, and hardly anybody I know uses them and gets confused as heck when they see code I write that uses them. It's because F10 through the debugger "looks wierd" when you use them and people aren't used to seeing functions inside functions :-)
There's lots of stuff in C# that people never use.
Getting head first is the only way I'll program in C#!
In that post Linus seems to rail more against C++ and not OOP in general. Good design is good design regardless of a language. You can do OO like design in C or even ASM if you follow some rules.
OO is not a panacea, and just because some is OO doesn't make it a better design than non-OO. Each problem is unique.
"For computer programmers who do not have a solid understanding of object-oriented programming (OOP), learning the C# programming language can be rather challenging, even if they have experience with C or C++..."
If you are an experienced C++ developer who doesn't know enough about OOP to get by in C#, then I'd say you need more help than any mere book is going to provide.
Well, for a start that's clearly not true in this case - HFC# came out in November 2007. 8 months isn't a year.
However, if you want a review of a more recent book, Jim Holmes has submitted one for my own C# book (C# in Depth) which came out just a few months ago. It's in Firehose right now. Whether it makes it to the front page is a different matter, of course.
Torvalds was trashing C++ not OOP (though he has trashed OOP before too.) I'm an OOP programmer and I agree with everything he says. C++ is a shit language, but that's not an indictment of OO. C++'s OO is horrible.
For computer programmers who do not have a solid understanding of object-oriented programming (OOP), learning the C# programming language can be rather challenging, even if they have experience with C or C++
Well if you have "experience with C++" but no "solid understanding of OOP", there might already be a problem with your programming skills.
My first program:
Hell Segmentation fault
Mate. That probably is Twitter.
It's because C++ breaks programmers minds so badly in such a way that they feel like they have to overcomplicate everything using stupid template tricks and stupid pointer tricks.
C++ programmers who move to C# often fail to comprehend how overcomplicated they tend to make things.
These 700+ page books on programming languages have too much bloat. Usually because they're full of recipes, plus a rehash of introductory programming material.
A really well written 50 page book on C# would be more useful. Especially if it came with a little summary card with the syntax. Code examples should be on an associated web site.
Of course, it's a Microsoft product, so it has "strategic complexity", not minimalism.
Please, elaborate as to how C# is "goo". What exactly do you mean? In the sense that you don't think the language is designed correctly? The runtime doesn't do it for you? The compiler? The type system? The platform itself?
Because "teh M$ goo" is not exactly enlightening, other than in the "I hate Microsoft" sense, which is your prerogative of course, but has nothing to do with the technical merits of their products. Especially when you
base your opinions on incorrect premises, since J++ (and J#) have nothing to do with the Sun complaints that brought the antitrust trial, which is what I assume you are referring to here.
Someone actually modded you up, which means that someone out there assumes you were not merely trolling (which is what it looks like to me, frankly). So a more detailed explanation of your claims would be double plus good.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Head first was pretty good, but I still prefer my old standby - "Balls Deep Into C#"
Unfortunately it's somewhat out of date. While it does cover C# 2, it was published a year before C# 2.0 (and .NET 2.0) were released - which means it won't be accurate when it comes to things like boxing nullable types.
It also (for obvious reasons) doesn't cover C# 3 at all. But yes, it does look like an interesting book...
I mean, I can write a C# compiler in Java, can I not? Oh wait, I can write a Java compiler in C#. Holy crap, I can write anything in assembler. I just found the best language.
Last week we had that story about Textbook Torrents. This was one of the ones I found there!
Given that Peter Sestoft was Beta tester on C# 2.0 you can take it for granted that the book covers C# 2.0 as it was at the time of release. If you find anything that is inaccurate in the book I am sure the author would appriciate the feedback :-)
Thomas S. Iversen
Given that Peter Sestoft was Beta tester on C# 2.0 you can take it for granted that the book covers C# 2.0 as it was at the time of release.
No it doesn't. The behaviour for boxing changed after the book was published. It was changed in the the August 2005 CTP, I believe.
C# 2.0 was finally released as part of .NET 2.0 in November 2005, over a year after the book was published - which means it's more likely to be about 15 months since the final copy was written.
If you find anything that is inaccurate in the book I am sure the author would appriciate the feedback :-)
I suspect the authors aren't that bothered at this point, given that the book is coming up to being 4 years old.
Mind you, judging by the table of contents, there's very little about nullable types - the chapter looks like it's only two pages long. That's not going to be enough to cover lifted operators and conversions, boxing etc.
Jon
It's M$ goo. It's a "we lost our J++ lawsuit so we gonna rewrap our crap" thingy..
Except it came out better this time.
Flamebait? One could argue not. Admittedly my experience with C# is very limited, but the first time I used it about five years ago, it struck me as as blatant a copy of Java someone could make without getting sued... but without the baggage and with a few nice improvements.
MS don't deserve *too* much credit for this, since (unlike Sun) they were able to benefit from five or six years of someone else's experience when creating their language, but with the ability to start with a clean slate and no backwards-compatibility baggage.
(Java inevitably accumulated a fair number of dead ends and improved reinventions of the same functionality over the years.)
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
i think c# and M$ products are rubbish.. blah blah blah... Get a new line guys.
So? Linux is a blatant copy of some other *nix.
Open Source software factories are constantly churning out copies of commercial software.
What's your point?
Exactly. What he said. I also respect no language that does away with pointers. Heck, I don't really like C++ too much either. Polymorphism, Encapsulation, inheritance and abstraction scare me. Give me a Struct or a Union any day. Of course don't take my ramblings as gospel as I also cut my grass at home w/ a chainsaw.
LFS. Have you built your system today?
...and I guess someone who uses a wood chisel to open a paint can is a handyman. The differences between C++ polymorphism and C# interfaces are extreme and I find it baffling that someone who could claim even a passing familiarity with both languages could genuinely confuse the two.
Wrong, no one cool actually programs in Java.
Can someone please explain what is wrong with C#? Something other than the fact it was created by Microsoft or simply that it is 'rubbish'.
What features of the language do you have a problem with? Ok, so there's no multiple inheritance. What else?
I've been doing ASP.NET via C# for a living for about 18 months now, and I've found it to be a perfectly servicable language. What's the problem with it?
I hate Microsoft's business ethics just as much as the next /.er. I'm still going to judge their products based on their own merits.
Technoli
MS don't deserve *too* much credit for this, since (unlike Sun) they were able to benefit from five or six years of someone else's experience when creating their language, but with the ability to start with a clean slate and no backwards-compatibility baggage.
... were able to, but didn't. The difference between C# vs Java was like C++ vs C. C++ and C# basically just add a lot of syntactix mumbo-jumbo onto a plain, reliable, usable language.
Mandatory generics, iterator yield, implicitly typed variables, 'object initializers', extension methods, embedding C++ and SQL directly into the code, operator overloading, implicit conversions, conditional compilation, etc -- none of those C# features actually helps you write better programs, and a lot of the so-called improvements in C# just make it a complicated mess.
The main problem in C++ and C# is that just looking at a statement you can never be sure what it does without poking around a lot of places (in Java a statement always says exactly what it does). A simple statement like "x.y = a[b]" can involve at least 6 different method calls. In Java is always means assign array element to a field.
Like C++, there are some people who will claim more features are better no matter how much more complicated (and generally the 'never enough features' crowd lives in Redmond). But at the rate C# is gaining kitchen sinks I think it will only be a few years until people switch back to Java because it doesn't have all that baggage.
It's very windows orientated, but that's about all I find wrong with it. Not a problem if you're never leaving Windows land - I find it an excellent language. If you are going outside of Windows, pick a more suitable tool for the job or use mono.
throw new NoSignatureException();
Mandatory generics, iterator yield, implicitly typed variables, 'object initializers', extension methods, embedding C++ and SQL directly into the code, operator overloading, implicit conversions, conditional compilation, etc -- none of those C# features actually helps you write better programs, and a lot of the so-called improvements in C# just make it a complicated mess.
I couldn't disagree more. Leaving aside your mischaracterisation of LINQ as "embedding SQL directly into the code" all of these features can *hugely* improve the readability of code.
Having used both Java and C# extensively, I know which language I prefer by a long chalk. Happily Java 7 will (eventually) gain at least some of the nice features of C#, but unfortunately not all - and it won't get rid of checked exceptions...
I now use Java professionally, but I'm constantly missing the features of C# which consistently allow me to write readable, reliable code.
So? Linux is a blatant copy of some other *nix.
Open Source software factories
(Side point, but what are these "Open Source software factories" that you speak of? I'd have said that- whatever you think of open source- its development model is generally far less factory-like than that of commercial software firms).
are constantly churning out copies of commercial software.
What's your point?
My point was that it wasn't unreasonable to argue that C# could be considered an improvement upon Java.
I then went on to explain why indeed this probably *would* be the case given the circumstances of C#'s birth. Credit to MS for the improvements, but it shouldn't be read that MS are better than Sun (or whatever) solely because they improved upon their work.
And get off your high horse- though they've done a lot, I wouldn't give Linus Torvalds or Richard Stallman the credit for inventing Unix and its descendants either.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
I also respect no language that does away with pointers.
Don't Java and C# still feature pointers implicitly via their referential handling of objects?
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Um, the features listed by my post's parent.
I don't have time to describe them all in detail here (or, more importantly, how they can improve readability of code) but here are a couple of URLs which give a bit more information:
http://csharpindepth.com/Articles/General/BluffersGuide2.aspx
http://csharpindepth.com/Articles/General/BluffersGuide3.aspx
Shameless plug: for a lot more detail, read C# in Depth... (there are sample chapters available at http://manning.com/skeet)
Yes. But C# handles pointers in "unsafe" coding areas which then need special permissions =(
I really did make my initial comment well before I had my first cup of coffee (Again, I'll drink Java but won't code in it.) So I hope everyone doesn't get to bent over my ramblings (frick'n MS fanboys! All of ya! Not you dogtanian of course.)
LFS. Have you built your system today?
We all stand on the shoulders of giants.
Java was not revolutionary, it was evolutionary. Sun certainly had a lot of 'prior art' to guide them when they developed Java.
I'm sitting here wondering what you think made Java so special that it was, by your logic, in a class unto itself? It wasn't the first OO language, it wasn't the first platform-agnostic language, it didn't expose a new and wild syntax, etc.
Java was successful not because it was groundbreaking: It was successful because it took all the best innovations from the existing languages of the mid-90s and coupled them with a familiar syntax and a large and cruft-free library.
The framework ecosystem gave a further boost by giving C and C++ programmers a route to web development that didn't involve terrible pain (CGI) or the loss of self respect (VB Script).
I imagine Anders had similar goals for C#.
I don't know who this guy is but i like him already.
LFS. Have you built your system today?
I'd reply to the both of yous, but I'd go over 140 chars.
LFS. Have you built your system today?
But what strikes me as ignorant in your post is the OTHER HALF of your analogy.
Following your logic, you're saying:
"[Compared to C] none of those C++ features actually helps you write better programs, and a lot of the so-called improvements in C++ just make it a complicated mess."
I'm not a huge C++ fan. I'd rather have my teeth drilled than take apart a C++ template.
But to suggest that C++ was not substantive is, IMO, ignorant.
I think in both cases -- C++ and C# -- you'd benefit from looking at them as standalone languages and analyzing them from that POV.
Except when you're called at 2am because the smoke test that was running on product release binaries failed with an access violation and no stack dump.
You better hope that the other programmers using pointers in the 250,000 lines of code used them properly.
There is no specific need for pointers. They can be abstracted either with shared_ptr or using a more modern language.
I agree. I don't even let our programmers use pointers in C, except for specific cases where the language is limited (returning multiple values, and char * for strings). If you dump pointers to structures and use more abstract coding, just accessing properties of objects through object references/handles, everything gets better.
In fact, you can also get waaay faster.
Beer is proof that God loves us, and wants us to be happy.
Favored by BG, since it allows him to pick your pocket while getting the shaft.
My problem with C# is not in the language itself. It's in the fact that untold manhours have been utterly wasted in cloning Java.
Yes C# has some nice things Java does not have. And if Microsoft has worked with the Java community to add them, imagine what amazing things we could do with the language by now, the very advanced tools that would have arisen with a unifies choice of an essentially VM based language.
But because Microsoft suffers eternally from NIH, we all must suffer an industry a shadow of what it could be - from both the C# and Java side.
So basically I think using and promoting C# is like coughing on a sick man, just to see how long you can keep him in bed.
Nowadays I really can't understand why anyone uses ASP.NET for web development with some really interesting languages and frameworks like Rails and Pylons and umpteen interesting CMS systems all based on a variety of languages.
For Windows programming the choice is pretty clear since that's the way Microsoft is going.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
In Java x.y = a[b] could mean a few different things as well, if you throw in things like aspects, and many of the other things you mention have Java equivalents. Java extensions tend however to be more through frameworks than language extension which I think is a good thing if you do not want to end up like C++.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Well, if you're afraid of object orientation, there isn't much we can do for you, nor are you the target audience, but you really should try to modern-up your skillset if you code for a living. Once I "got it" i found I didn't want to go back to procedural coding at all.
Secondly, while there are times when points might be nice, the tradeoff (basically, you lose all the safety that a VM gives you) is unacceptable. In C#, you can do method pointers using delegates or reflection (another scary OO concept), and use pinned memory and marshalling for reading data into structs, without sacrificing safety. That covers 95% of what you'd want to do with pointers (The other 5% would be arrays of pointers, simply because an array of delegates would just be too slow in many such situations).
Jeremy
I would like to pontificate on the fact that the correct spelling is Zimbabwean..
I don't even know this guy but I like him!
LFS. Have you built your system today?
Yeah for you dumb MS programmer fuckers who don't know what Object Oriented Programming is, don't get stressed, it's just "OOP". You know, OOP!!!
retards
-- A cat is no trade for integrity!
MS DID try it was called J#
That was not improving on Java, that was the first, even less veiled attempt to basically copy Java and add Microsoft specific stuff to it (like Win32 api's).
I don't personally think code readability is the be-all and end all of utilitiy, the ease of extension and quality of frameworks are far more important I think.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
My only issue is the lack of local static variables. If I'm searching a database for a record I like to check if I already have that record in scope. Ie. Find(int id){static int lastID = 0; if(id == lastID).... I've heard that the reason for this omission is because of threading and it's impact. Blaaa, if you're doing threading you should know better. Other then that. There's nothing wrong with the lang. Garbage collection isn't the devil I once thought it to be. Not if you look closely. The interpreted part of the lang will always bother me but on the whole for desk programming it's as good a lang as many and better them most.
Ok. The first c++ I ever got was deital and deital. Almost 10 years later and I still find it a fun read. I still see things in it I missed every other time. (perhaps I'm slow ). Their coverage of c# is huge. I mean 1300 pages is just too much. I'd have loved to see something more concise. That said I still bought the book. Seemed to me that if their c++ was great then their c# could be just as good.
That's how long it took to get through the fluff remedial chapters. ;)
Re: reviewer
Camping on quad since 1996.
Having come from a CB86 / Commodore BASIC / GFA BASIC / MS BASIC / GW-BASIC / QuickBASIC / VBDOS / VB background, I felt really sorry for all these C people who had to learn a whole new language again. All I had to learn was what an O did and how to orient it.
-- none of those C# features actually helps you write better programs, and a lot of the so-called improvements in C# just make it a complicated mess.
I couldn't disagree more. Leaving aside your mischaracterisation of LINQ as "embedding SQL directly into the code" all of these features can *hugely* improve the readability of code.
...
I now use Java professionally, but I'm constantly missing the features of C# which consistently allow me to write readable, reliable code.
That's why I like perl. All those features make for more readable code.
Wouldn't that be the first one after the first, technically speaking? Speaking of which, as Head First is actually a series of books very similar in style, it would be nice to have someone elaborate on how much the authors re-use explanations, clip arts and examples their fellow authors already employed in Head First Java or the OO book.
Has anyone ever studied more than one of those books? However, I really like the approach, and I couldn't disagree more with the negative tone about the stated redundancy, because that's there on purpose. As those books are not meant as a reference but as a means of getting those language concepts into even the slightly ignorant minds (or the easily confused, or the easily distracted, your pick), repetition in slightly different wording is _great_.
A World in a Grain of Sand / Heaven in a Wild Flower,
Infinity in the Palm of your Hand / And Eternity in an Hour.
> but you really should try to modern-up your skillset if you code for a living
Modern? Simula67 introduced an implementation of OO with objects, classes and inheritance in... guess what year?
OO should only be one paradigm in the programmer's toolkit; applying it to all problems is unwise. Procedural, OO, AO, DO, functional, logic; they're all equally valid across an unbounded problem space.
My only issue is the lack of local static variables. [...] I've heard that the reason for this omission is because of threading and it's impact. Blaaa, if you're doing threading you should know better.
Decades of evidence points to programmers not knowing better. No matter how much they should, they don't. You have to hit them with a pretty big stick to stop them from doing the lazy broken thing, and taking away local statics is just one more example of this. (Personally, I'd be tempted to much further and take away most state that's not thread-local, but that's not how C#, or Java or C++, works.)
"Little does he know, but there is no 'I' in 'Idiot'!"
If you use a $ as an S in Microsoft, its flamebait. You've ventured outside the realm of reasonable debate. The fact that the original poster also calls it "goo" also indicates his preference to start a conversation not based on objective, or even subjective facts. It is in a word: flamebait.
Except that the person I was replying (and referring) to wasn't the one who did those things; that was the top-level OP.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
This is a silly place to post a review about a C# book. Most of the readers here are way too narrow minded to post any reasonable discussion about the book (or anything involving M$).
The posts here pretty much prove my point. It's actualy kind of sad - it's obvious some of these people are fairly bright, yet they can't seem to see past their 'elitism' BS - which is anything but.
The review itself should probably be marked 'troll'.
I don't particularly like microsoft - but yep, I do code for a living in C# after having done so in Delphi (way back in delphi 1). And sorry guys, but it's pretty damn cool - the database access stuff needs work but in general, it's a very nice language to work with (and the IDE rocks). And yeah, well, as long as windows land is 90% of the world, that's where I'll be coding. Call me back when linux manages to get some desktop penetration worth talking about.
EK
The main problem in C++ and C# is that just looking at a statement you can never be sure what it does without poking around a lot of places (in Java a statement always says exactly what it does). A simple statement like "x.y = a[b]" can involve at least 6 different method calls.
That stinking operator overloading! I hear that in C++ and C# something like:
s1 == s2
could even compare VALUES of two strings s1 s2! Instead of checking whether s1 and s2 two references point to the same object in memory, like every sane language should do.
And all those other things. I mean, in C++ you also had to deal with templates, those complicated buggers. I mean, dude, you'd even have to write something like vector<int> - instead of plain old simple Object containers that you'd only have to cast into the target type - the way that statically typed language are damn well supposed to be. Oh wait, we decided that the <Integer> thing was better in 1.5? Kahm...
And I hear that there are some other things where you could even hook into language constructs, such as the for loop, instead of using the simple iterator()/hasNext()/next() idiom. Oh crap, we did that too in 1.5 with Iterable???
It's not that I hate Java... too much. Yes, it is a good, robust platform with a myriad of tools, well suited for big project and enterprises. Yes, no-one can dispute that C++ had a number of completely unnecessary features (private inheritance, anyone?) but the amount of straitjacketing that Java imposes on you is completely unnecessary - as they admitted themselves on those two examples above. Only 10 years later.
Don't ditch C# just because it's from Redmond. They got a number of language things right IMHO (not saying that they haven't got a number of them wrong as well). If anything, having a competitor is good for Java and for all of us at the end.
Of course, I'd take Python or Ruby over both them C++ clones any given day.
If your interest lies in OSS, you may consider investigating a language that is less platform specific.
I find the "Sam's XX in 24 hours" books pretty handy for beginners as well.
C# is like taking C, stripping out the pointers, and mixing in some VB and Java.
If I want to write easy code without dealing with pointers, I use VB. It's great for those things. Especially when I can use VC++ to create a new ActiveX to extend functionality rather easily. I can even create some pretty whiz-bang stuff that integrates nicely into Access and makes VBA rock.
If I want super fast code to crunch things like graphics, then straight old C is my tool of choice.
If I want clean syntax, plus the ability to use pointers, then my choice is a good Object Pascal or Delphi. ANSISTRINGs and dynamically resizable arrays are manna from the code gods when time is short and speed counts.
For web stuff, PHP is king.
C# to me is basically putting up with the cryptic PITA of C while giving up the benefits, and it lacks the cross-platform advantages of Java.
So what is the damn thing GOOD for?
If you're a n00b...Fine. If you're someone who codes for a living...the books are idiotic and really not that funny. I'm interested in learning, not being entertained. I find myself about every third page wanting to scream "JUST TELL ME WHAT THE F!#K I NEED TO KNOW!". But...then again...that's just my opinion.
Aawww, troll. I guess I'm not being a good little Slashbot here.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Alright, but given the overhead of OO it wasn't exactly mainstream until C++ came out (and even then, a lot of C++ is procedural). Also, virtualized address space and the lack of true pointers IS definitely modern (circa 1990s, anyhow). The OP's impression that the lack of pointers = toy language is an inaccurate and outdated notion.
Jeremy
> but you really should try to modern-up your skillset if you code for a living
Modern? Simula67 introduced an implementation of OO with objects, classes and inheritance in... guess what year?
OO should only be one paradigm in the programmer's toolkit; applying it to all problems is unwise. Procedural, OO, AO, DO, functional, logic; they're all equally valid across an unbounded problem space.
Exactly good sir. You don't need to use C++ to implement OO in C. I can easily do OO in regular C thru the use of structs & unions. Not all functions need to utilize get/set member functions and whatnot.
LFS. Have you built your system today?
Keep it up, trolltard. I guess you're down to this because the "game" wasn't as dreadfully easy as you calculated, eh?
You must have the Slashdot record of most ruined accounts, outside of the GNAA team. Impressive achievement.
And I'm including these as well, because I know that's you.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
But hey, languages are there to be used so, C# on man!
I'm getting into lighter flavors anyway, I figure that for most stuff I don't need the bulkiness of Java.. Python does the trick neatly.
From C# 2:
o There's nothing directly like iterator blocks in Java. If you want to implement Iterable/Iterator, you're on your own. Furthermore, there's no safe way of using non-memory resources in an iterator.
o Java generics are very poor compared with those in .NET.
o Anonymous methods are much leaner and more flexible than anonymous inner classes. That's why there's so much discussion about how to bring closures to Java 7 :)
o Nullable value types don't exist in Java (we're not talking autoboxing here). Of course, Java doesn't have user-defined value types in the first place...
o Partial types don't exist in Java at all
C# 3 introduces a whole raft of new features. The links were only very brief introductions to the new features. C# 3 *definitely* allows more readability than Java. I know both languages pretty well, and now that I'm back to writing Java commercially, I really miss the expressiveness of C# 3.