Effective C#
If you're interested in, or currently working with, .NET and are tempted to skip past this book as Just Another C# Reference Book, think again. Wagner's book is a great resource because it covers concepts which run across the entire .NET Framework regardless of which language you're working with. While this book focuses on C#, VB.NET developers can benefit from some of the text within as well.
I also think this book speaks to a wide range of readers. Seasoned developers will blow through this content, fine-tuning their coding methods or starting new ones. Wagner specifically points out how practices experienced C++ developers may use aren't good practices in C#, such as avoiding function call overhead by writing longer C# methods with more convoluted loops. More on that later.
New developers also can greatly benefit from this book by using it to properly form development habits early in their careers. Examples of this might include following Wagner's recommendations for safe casting, strong use of interfaces, and knowledgeable resource management.
Wagner's writing style is clear and concise. He occasionally comes across as brusque, or as writing only to experienced developers ("I wouldn't write code like this and neither would you."), but those instances are few and far between. The rest of the book's voice is terrific. More important is the weight of Wagner's knowledge and experience.
One real drawback is a large number of typographical errors, sometimes several per chapter. Some sentences are missing content, and there are a large number of run-together words. These errors don't take away from the material, but it's an annoyance all the same. I would have expected better proofreaders at AW.
The book is well organized into six chapters, each hitting a specific area in C#. Within each chapter, Wagner covers six to ten items, each item focusing on one specific "minitopic," as Wagner calls them. Each item includes code snippets to demonstrate recommended approaches. Few of Wagner's snippets will function as standalone programs, but this is an advantage, as I see it. The book focuses on tight, specific examples, rather than weighing itself down with pages of extraneous fluff.
Often Wagner's recommended approach is contrasted against bad practices, or practices which might be optimal in other languages but work poorly in C#. An example of this would be Chapter 4's Item 31: "Prefer Small, Simple Functions," where Wagner shows how smaller functions are generally more efficient than larger functions with complex loops. This probably confounds experienced C++ developers, but it's a prime example of how valuable this book is. Wagner shows that .NET's Just-In-Time compiler pays less cost when calling functions than it does trying to wade through convoluted loop logic. His recommendation? Write "the clearest code you can create. Let the JIT compiler do the rest."
Chapter 1, "C# Language Elements", hits hard the topics "you must remember every day when you write C# code." This chapter discusses issues central to C#'s syntax, implementation and optimization. Wagner talks about basic Object Oriented concepts such as hiding class data members behind Properties (.NET's common access methods/fields via gets and sets), and why it's important to implement a ToString() method. Basic software engineering topics are also covered, like why it's important to differentiate between value and reference data types -- and the pitfalls of failing to do so. This chapter also thrashes out coverage on deep C# concepts like why developers should use foreach loops and why the GetHashCode() method will "practically always get you in trouble."
Chapter 2, ".NET Resource Management", has a lot of text on general patterns for constructing optimal code. Wagner's in-depth knowledge of the .NET Framework's underpinnings really shows through here. There's a very clear discussion of the performance ramifications of boxing (wrapping value type data into an object for method parameters) and unboxing. Minimizing extra garbage (unnecessary objects) and easing resource clean up via standard dispose patterns are also covered. This chapter's critical to ensuring you understand what's going on with resources in your .NET application.
Chapter 3, "Expressing Designs with C#", looks at object-oriented design in C#. While the discussion's specific to C#, there's a lot of great, practical information which applies to any object oriented development. Wagner gives some great examples with backup discussion regarding preferring the use of interfaces over inheritance and why it's a cleaner solution. (Java programmers who've read Alan Holub's "Why extends is Evil" in JavaWorld would enjoy this section.) There's also great treatment of using delegates for callbacks, and events for outgoing interfaces. Wagner also points out more pitfalls in a reference data type language: returning references to internal class objects via a read-only property (getter for Java folks).
Chapter 4, "Creating Binary Components", shows what critical topics you have to consider when creating even a moderately complex system for deployment. Wagner exposes some terrific details on how smaller is better when developing .NET assemblies for deployment. He also discusses why it's best to limit a class's exposure through public scope since this ends up advertising too much of your class's internals to potential users of that class. Wagner ties this back to interface discussions in earlier portions of the book, and makes a good case in this section for bad scope's impact on deployment.
Chapter 5, "Working with the Framework", delves into the .NET Framework Class Library. The FCL is a huge library and Wagner's insistent that too many developers are writing custom code for functionality which already exists in the FCL. This section helps to avoid having "developers reinvent the wheel." There are very useful discussions on using .NET runtime diagnostics, .NET's validation capabilities, and standard configuration mechanisms. Wagner also shows why .NET's reflection capability (one component dynamically discovering another component's capabilities at runtime) can be overused - but he also shows how to best use it in the appropriate cases.
Chapter 6, "Miscellaneous", is the catch-all section. Security and exceptions are covered here, as is the pain of working with COM interoperability - and why you should avoid it if at all possible. Just as importantly, Wagner points to several tools which should be in any C# developer's belt. He also identifies terrific resources available online.
What makes this book so useful is that Wagner constantly talks about the reasons behind why specific choices in C# should be made. For example, in Item 3, "Prefer the as and is Operator to Casts" Wagner moves through the rationale of why a developer should (when possible) avoid casting in C# and use the as and is operators instead. Casting can lead to headaches with data loss when casting a long data type to an integer one, or more headaches with the extra lines of code to ensure the cast was to a proper type. Sure, casts are sometimes necessary, and it's another value point for this book that Wagner gives clear examples of when his techniques don't apply -- and he also shows recommended alternatives for those cases.
It's just this kind of discussion from an experienced developer that makes this book so valuable. Good developers need to understand the ramifications of choices they make designing and implementing a system. Wagner's book is outstanding for exactly this kind of detailed, clear exposition.
An additional bonus: Wagner has a blog dedicated to discussion of items from his book. Erata are also listed there. See Bill Wagner's Effective C# blog.
The bottom line: this book really is a critical addition to a serious C# or .NET developer's bookshelf. It deserves a place right alongside books from McConnell, Macguire, Kernighan and Pike.
You can purchase Effective C#: 50 Specific Ways to Improve Your C# from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Effective C#? How about don't use it.
Effective C#!
..C# developers have bad sentence structure, leave important structures out, run everything together, and even though the end product is kind of annoying its still helpful?
"..in the same class as Code Complete"
But do we really need a "programming good C#" book? Isn't good programming all about, well, good programming? If I remember Code Complete correctly, it used pascal and C, I think. It definitely was one of the best books I've read, but how many times can you say the same thing over and over again?
Languages come and go. But good coding techniques don't dependent on a certain vendor or technology.
Maybe this is a good book if you don't know much of any programming language and want to pick up C#. Speaking as a C# developer who does Java, C, C++, and VB, I just read some of the rags and jumped in. Then when I wanted to do something else, like create a custom web control, I got a book in C#. Presto/Bingo, I'm coding in C#. OOP as a concept is going to have similar constructs, no matter what the language, right?
Sorry for the rant. It's probably a great book. I just don't understand how good coding practice is dependent on the flavor-of-the-week. Perhaps in his comparisons the reviewer does a disservice to the intent of the work.
Click on this link for the blog.
Synchronize your calendar and mobile phone via text messaging.
Thats what I've found. Another .net language syntax is book is hardly useful. You find yourself wondering what the fuck you would do with all these new wonders and you can think of a 100 better ways you might design code compared to your procedural past but your head is left spinning with options. That is where the design patterns come. OOP ways to do different things which can have a huge impact in the future of your coding. Also MS Press has been doing a bang-up job in documenting the net framework APIs. I would start with a design patterns book and a book on the net framework.
Yeah, except those of us working on large systems that run on UNIX machines. C#/.NET can leave me far far behind and I'll be happy coding in Perl/Sh/C/Java like I do every day.
Someone get me more blog paper.
Sorry. I hate that word. Blog. =X
The review is missing something important. Effective C# is of the same mold as the Scott Meyers' Effective C++ franchise - known by many C++ programmers as a great resource of best practices. Bill has Meyer's approval to publish an "Effective" book, and even announced its publication on his mailing list.
Heard of Mono?
Effective Java!
[mod me +5 funny like the parent. What's that? You don't like underhanded my-langauge-is-better-than-yours jokes, meant to enflame rage between already volatile communities? Oh, sorry, mod me down then.]
Tech, life, family, faith: Give me a visit
will you still be happy w/no job?
Yes and Yes
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
tbh, I'm not sure that that is a recommendation. We have been going over cc in a reading group at work for the better part of a year now (chapter a week takes a while!), and overall, while he does have a lot of worthwhile stuff to say, the book is mostly dross, coupled with misleading stats, poor editing (and occasionally worse writing) lack of direction and bad analogies. .net knowledge will pretty much provide that anyway)
On the other hand, it has proved useful as a talking point in our reading group (a mix of professional programmers ranging from fresh grads to seasoned vets). As for the C# book, well we could do with a good reference for the language (although a decent c++ book and a little java and
"Success is based on knowing how far to go in going too far"
I eagerly await the chapter on porting C# applications to HP/UX.
But does it work on Linux?
Joke aside, that's the question I was asking myself. Why learn a platform specific language when you can use a platform independent language like C++, Java or Ruby?
Windows is wonderful (well, not really), but there are other platforms out there as well.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
Try Mono.
Often Wagner's recommended approach is contrasted against bad practices, or practices which might be optimal in other languages but work poorly in C#. An example of this would be Chapter 4's Item 31: "Prefer Small, Simple Functions," where Wagner shows how smaller functions are generally more efficient than larger functions with complex loops. This probably confounds experienced C++ developers, but it's a prime example of how valuable this book is. Wagner shows that
I don't know how he got the impression that experienced C++ developers would be confounded by short functions. By using short inlined functions, C++ developers don't pay any cost by breaking up large routines.
That will only go as far as Microsoft will let it. Meaning that if MS wants to, they can close it down with their patents on C#/.NET. I would hate to code under that condition.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
Except for the vast majority who aren't even considering it. I don't know anyone who has even been asked to look at C#, I know plenty of people doing C++ and Java. But keep reading the MS press releases and believing that, its amusing to people who actually follow industry.
I still have more fans than freaks. WTF is wrong with you people?
Can you list those C#/.NET patents which worry you? I wasn't aware of this.
"reality has a well-known liberal bias" - Steven Colbert
Paul Graham said it best:
He goes on to reference Norvig's paper Design Patterns in Dynamic Programming that points out that in more productive environments, many if not most of the classic "design patterns" are totally invisible in better platforms today.If you are spending a lot of code writing stuff that fits nicely into design patterns, you'd be far better off switching to a platform (any lisp platform; any python platform; ruby/rails) that frees you from this redundancy automatically.
Did you know you can't see patents pending? There is no databse for them, its secret until its rejected/accepted. In addition, they can send in a correction or addition to one, and it remains hidden longer, but still becomes effective as of the original submission date. So if they exist, we won't know for another 3 years if MS doesn't want us to.
And before you say its an ECMA standard- ECMA does not require standards to be unencumbered, or even to be licensed on a RAND basis.
I still have more fans than freaks. WTF is wrong with you people?
So, under your rules, you'd better not code in Java either since anyone, anywhere could have a pending patent.
.NET framework and C# language.
Give me a break... at least with C#, it's an ISO and ECMA standard. Further, Microsoft has explicitly permitted 3rd party implementations of the
But I'm not going to get into a petty langauge war. Use the right tool for the job, if it's C# or Java, frankly it matters little. Only zealots think otherwise.
Tech, life, family, faith: Give me a visit
Only on slashdot would you see people rant on C#
God's in his heaven-All's right with the world. Karma=Bad ? F*ck that
Why learn a platform specific language
.NET framework (i.e. the common code library shared by all .NET languages including C#) is partially platform specific (in particular, System.Windows.Forms namespace).
.NET language (be that C#, VB.NET, JScript.NET, J#, C++, and about 30 others) that runs on everything from Solaris to Mac to BSD to RedHat. I suggest you check it out for more info.
C# is not platform specific. However, the
That said, the Mono Project allows you to write code in any
Tech, life, family, faith: Give me a visit
What I find funny is that MS ppl still keep stealing from others. Not even shamless about it.
C# is revolutionary !!
Windows r0X !
Keep creating high quality software Bill !!
Gooooo Longhorn !
*ducks*
But seriously... choose a platform independent language... and anything that isn't bound to Winblows.
Perhaps that's your view, but it doesn't necessarily make it correct.
I am in the industry too and know plenty of people who ARE looking at C#. Try not to make blanket statements like that based on your own skewed perspective and you'll make us all seem more intelligent.
That's funny because the Rails people go on and on about how it does MVC and all which is... you guessed it... a design pattern.
(Please browse at -1 to read this comment.)
Not that I'm a fan of Java, but Java has no angle in blocking other OSes from using it. In fact, that was its big selling point. Microsoft does have a big angle in doing so, and an even bigger one in hurting open source. Mass adoption of C# by OSS followed by a patent attack could put OSS back by years. Java is an acceptable gamble, C# isn't.
I still have more fans than freaks. WTF is wrong with you people?
Microsoft even released the source code to a FreeBSD CLR implementation called "Rotor".
Under what terms?
C# is a GREAT language, this is coming from a long history in Oracle/Unix/Linux. I don't understand where people got the idea that it won't work on Linux either. We're coding 3-monitor full screen 3d MRI analysis applications in it, and I can assure you that it has accelerated our developement time over the last iteration created with Borland C++ Builder. Ironically, it took 8 years to write the last version of our software in Builder, and 6 months to completely rewrite it with enhancements in c#. That, consequently, was with both the lead developers having no experience with the language (I was a C++ folk, and he'd been using Delphi, so we settled on C# since it was essentially the next evolution of Delphi).
It's no joke, and I'll be buying this book just to have it. I've also picked up most of the Deitel series of books on c#, and of course the O'reilly books. The c# cookbook is another GREAT reference. Anyone interested in starting with C# should check www.codeproject.com for examples. Also, along with a rude admonishment to the MS haters for not having researched the topic (MS dependant indeed), check www.omnicore.com for a native crossplatform compiler for c#. It's cheap too, but doesn't do forms support just yet (when it does, I'll probably move from VS just to get free cross-platform compatability).
-chitlenz
Imagination is the silver lining of Intelligence.
Actually, you can run C# code on Linux! With tools like the Mono Project, you can port your C# code over to the Linux platform...
If you look at the review section for this book on Amazon.com, there are a lot of mixed feelings about the book. I'm not convinced these are negative interpretations of the book but rather individual bias against the language/Microsoft.
Personally, I've read it from cover-to-cover and found many useful tips about writing better software. Although it covers many major topics software topics beneficial to junior/intermediate C# developers, the book layout and numerous publication errors (words run togetherwithoutspaces...) may hinder its sales until a newer edition is released. Some type of color-coding or quick lookup would help emmensely! I'd definately recommend reading it but, if possible, try to hold out for the next edition.
We just moved our site www.autoexpressusa.com over to mono. The site was built on windows and trasfered over to linux without any problems.
Take a look at this:
Sapir-Whorf and programming languages
I personally use Herbert Schildts: "C# a complete reference" for reference.
It teaches u how to program in the first half and in the second half it has references to all the libraries.
I find C# pretty straight forward if u know Java.
I love programming in languages that have their own memory management. Worrying about pointers and what not takes away so much time from productivity. For ppl who wanna get hardcore and want control. Yes u can embed Assembly in ur C# code.
Now if only someone makes microcontrollers/dsp's that do their own memory management. That's make my life so much more easier.
Lets set aside that C# is nothing but a rip off of Java.
So far, other than low-end schools or schools with millions being thrown at them from MS, few in academia are adapting it. ACM and the major 4 universites backs Java as the primary language for CS.
Likewise, set aside the fact that nothing inovative has come from C#. I will grant that one day something might, but after 5 years nothing yet.
the real problem is the Gnome world was foolish enough to adapt it. Now, MS is finally throwing the patent stuff at them on a number of issues. My guess is that C# AND the api will be dead on all but MS. Even on the BSD platform.
I prefer the "u" in honour as it seems to be missing these days.
Secondly, OO programming is inherently parallel, as you access everything by implied reference, all data is stored on the objects, and all communication is by very controlled, specific paths. But multi-threaded OO code tends to be horrible to write, whether in C#, Java or any other OO language. Most OO languages assume a serial flow, even though the architecture implies a parallel flow.
Third, C# is a hybrid - it is more an object-based language than a pure OO one. (The difference is that a pure OO language has no atomic types visible to the programmer, as atomic types mean procedural code. There should be no procedural code in an OO program.) Unfortunately, the only language that is even close to pure OO is Smalltalk, and I dare you to name any serious applications written in that.
Fourth, Microsoft has explicitly said that the new C# extensions supported in Longhorn must be licensed under a non-free license, so there's no chance that Mono will support the newer stuff.
Lastly, I would agree that Java and VB are a mess - Java is inefficient and slow (not to mention horribly designed), VB is way too proprietary and non-portable, but that doesn't make C# good, it merely makes it better than most of the competition. D is a better language than Java! The biggest difference between C# and D is that D isn't as well known and doesn't have a trillionaire backing it.
Academia's judgement on languages has yet to impress me. Whilst I am from an academic background, I do not regard languages such as Cobol or Ada to be noteworthy uses of software engineering, and both Modula-2 and Modula-3 are useless for anything beyond classwork, and Pascal is perfectly good for that. (IMHO, it is also better.) Occam, perhaps, but only a handful of Universities - and all in Europe - still teach it.
Just because it's from Microsoft does NOT negate it, you are quite right. Microsoft is quite capable of producing good ideas and good software. Sometimes, it even does. However, C# does not seem to me to be worthy as a contender for "ideal language of the year".
Ok, so what WOULD be an ideal language? Something with the inherent parallelization of SISAL, with transparent networking (if the resource is specified, and the resource is reachable by IPv4, X.25 and Appletalk, why should I need to know which is used, if the communication still takes place within the desired constraints?), with a consistant architecture (no hybrids, please, the compiler should take care of optimization and consistancy is readable).
There should also be a rigid distinction between UI (and UI constrants) and the backend (with all the constraints there). One thing I hate about programming for X is that there is a blurring between quite distinct components. (I also don't like the container management, the parameter lists, and the layout management, but it is the violation of an essential SE design principle of keeping interface details completely independent of engine details that really bugs me.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Because C# is quite popular on the job market?
I started working on a hardcore C# project around the end of last fall. Effective C# has been my guide and while there are a few recommendations that I'm still experimenting with, I must say I have been very pleased with the results of following its recommendations. While I do concur that the number of typos was surprising, most are simply a missing space between two words and thus little is lost other than the finish of the book. In general, the entire "Effective" series of books has been equally useful, though this one misses the fine sense of humor Scott Meyers has contributed to his own books.
Effective Coleco Adam Basic!!! I had one, and if you didn't you aren't as l33t as moi. Seduction Home
Java is an acceptable gamble, C# isn't.
Frankly, most companies (including the one I work for) choose to support the most widely used OS; supporting multiple OSes means more testing, more development costs. And for Windows, C# blows away Java.
But again, I won't get sucked into a langauge debate. If I were to write cross-platform software, I might choose Java over C#. It's all about getting the right tool for the job.
Tech, life, family, faith: Give me a visit
Simply put, notice the ethics of the post. Good ethics are not often seen.
Microsoft's COM model which interlinks many supported languages so that they can talk to each other... Supported programs have properties which can be accessed from external programs if they allow it - eg Photoshop provides this feature and .NET apps can script Photoshop without being an internal plugin.
I'm new to the .NET environment ... (Disclaimers: 1) I got this book for free from Addison-Wesley as a regular giveaway for our .NET Developers Group.
This is pretty shameless, guys.
Beacuse C++, Java or Ruby may not be the best language for the job. Currently C# is a great language for developing Windows applications.
There are plenty of reasons to learn and use a wide variety of languages and platforms. The right tool for the right job.
Java runs only on OS and architecture combinations where Sun wants it to. Due to the hard work of some people, I can at least get java on BSDs for i386, but not amd64. And even for i386, Sun's license says I can only use it for testing, because I haven't paid them to certify the port as java compliant.
Heard of Mono?
Yeah. That's the kissing disease.
http://msdn.microsoft.com/vjsharp/
Deja Vu
n. 1. The sensation that you've read this very article before.
Being the curious type, I installed dotnet framework and the sdk on windows. I also installed mono on fedora. Some basic code tests worked on both platforms.
Still I dont like having to install a framework/vm
just to have a piece of code be able to run.
On the linux platform, there is no adoption
worth mentioning and even MS admits dotnet
has stagnated
I am in the same situation, and I feel exactly the same way. Often people fail to understand why I dislike Microsoft so much. It is because of Microsofts Policy of Proprietary Design (you can quote me on that:). Every piece of software they have written seems to be tweaked (from orders from high up, no doubt) to work best only with MS. The resemblance that Bill Gates's behavior in the marketplace bears to the Robber Barons of the 19th century is disgusting. I have all the respect in the world for the (honest) MS developers, they need to make a living like everyone. The problems clearly stem from those who are becoming filthy, filthy rich from forcefully beating out competition in the software market.
Disclaimer for .NET haters: Mono --open source dev tool for .NET. It's nice i've got it on my gentoo partition :-)
/. is pretty much a open-source favoring crowd, but MS Visual Studio 2005 is a nice improvement upon the previous edition. The gripes most had about the old version have been fixed, and there are quite a few great improvements, including my favorite improved intellisense! :-)
end-disclaimer.
The MS bashing is quite disturbing. Well i know that
While i may have made myself flamebait, i think that if you are honestly interested in VS, you wont be disappointed by the new improvements they've made to Visual Studio.
I got sucked into the whole Java "write once, run anywhere," back in 1996 only to find out that it was "write once, debug (or should be re-write) everywhere." Now you just have the "Java Platform," which really isn't much different from any other platform. What a nightmare.
Moving forward and wanting to get away from Cold Fusion development for the web, I must say that C#/.NET infrastructure looks very appealing. The programming IDE is nice, and the language/classes look very easy to get started with. So what if it's platform dependent? My servers are on Windows boxes and they run great. It's not like people running UNIX or Macs cannot view web programs written with .NET technology.
Is this whole thing really about Linux/Unix is cool and Windows is not? Give it up! We're talking about computers and operating systems! Who cares what color your iMac is or what flavor of UNIX is the best? Am I being selfish when I say that all I care is that it works, and that there will be a company around next year to support it?
And please, spare me the php speech. I don't know why, but I'm just don't like it. It reminds me of Perl, and if I never write Perl again, it will be too soon.
-- www.punkmusic.com
OOP as a concept is going to have similar constructs, no matter what the language, right?
The basic concepts, yes. How the platform or language treats things, not necessarily. Here's a specific OOP example between the latest so called "fad" languages. In Java methods are implicitly virtual. In C# you have to explicitly declare a method as virtual. Prescriptive guidance as to how one should go about determining which methods to mark as virtual is only relevant to one of these languages. So while you are correct that general coding practices are independent of the flavor-of-the-decade language, there are topics which warrant books targeted at specific languages or platforms.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
.Net Components by juval lowy
C# is actually another clever way of saying C++: it comes from music notation. C# is the same black key on a piano keyboard as Db. It mean C one half-tone higher...
i liked the name, at least.
But for a real modern OO language, you should try no other than OCaml.
C# is, just like Java, a simplified C++ with half the performance and flexibility. C++ for the brainless, easily replaceable masses if you will...
I don't feel like it...
I work on consumer applications and would love for our team to be able to develop on .Net, but I have no idea from anyone how widespread it is? I don't think we can get people to download a 20mb framework for a 500k app? .Net has faster dev than C++ or C# due to the available tools, but that's no good if the users won't use it.
Any ideas?
Look into using AJAX.Net for providing changes without a full page refresh, ie when I change the dropdown selection for car mfg, it does a postback.. considering the first page is pretty big, this isn't a good thing..
Michael J. Ryan - tracker1.info
That's why Novell is putting a lot of time and money into the mono port of C# to *nix?
Michael J. Ryan - tracker1.info
The browsers out there are not the same and now it's MS fault? Come on!
. NET+browserCaps
It appears that you skipped a few details while learning ASP.NET... Look up browserCaps on Google.
http://www.google.com/search?biw=1497&hl=en&q=ASP
>>C++ for the brainless, easily replaceable masses if you will...
What an elitist prick you are!
KYLIX! Borland's implementation of Delphi works on Linux just fine with the same code you'd use in Windows.
.NET (even though as was mentioned in this thread, it is just the evolution of Delphi to the next level basically because Anders Heijelsberg designed both Delphi & largely the new VS as well improving it and anyone who's done BOTH Borland's Delphi/C++ Builder and VS, can attest, things like data containers come from Delphi for example)... is the performance of it being interpreted is slower than std. 'old-school' true single-.exe format programs.
.OCX form loads, which VB is highly geared to).
The ONLY thing I do not like about
Other than that? It's going to be the future whether we like it or not, MS is behind it.
Question - IF C#, VB.NET, etc. was a performer? Why isn't LongHorn being coded in it from the ground up? Performance...
(You still cannot beat straight C, C++, or Assembler for OS coding... the only language I have EVER SEEN that can beat them? Delphi... especially in Math & Strings work, which EVERY program does! E.G.=> Visual Basic Programmer's Journal 1997 issue "Inside the VB5 Compiler Engine" showed this with Delphi 2.0 beating the snot out of BOTH VB5 &/or VC6 by MS, consistently across the boards (losing only SLIGHTLY to VC++ in graphics methods & only slightly to VB on
Other than that? Delphi swept the rest of the tests from MS' toolsets. Again, especially in Math & Strings work.
That's my take on tools and why I prefer Borland Delphi over them all, and probably WHY Mr. Bill Gates ("King Billy" as I call him) hired Anders Heijelsberg away from Borland (brain-draining that company as per usual over time as MS does quite often for coding & design talent):
PERFORMANCE!
APK
http://www.torrentspy.com/download.asp?id=212745