I've always understood pedantic as a combination of the word 'pedant' (teacher) and a very detail oriented person.. so being pedantic is being focused on always teaching someone something.. a 'pedantic essay' spends a lot of time making sure the reader knows what the author is talking about, rather than assuming some expertise on the part of the reader and getting on with the point of the article/book. Given this definition, I don't think of programmers as mostly pedantic.. I actually see them hating to explain things to those that don't 'get it'. I've met a few that are.. but most I fear are not that way... And.. entertainingly.. this response is pedantic! =)

Indeed.. I stand corrected! =)

He says.. waving the metaphorical red cape in front of the angry bull..

Errr.. no. For years the military has used attention to excruciating detail in training to get soldiers aware of small things.. since ignoring small things can get you killed in combat. The attitude you bring to the table regarding how you handle details shows up in ALL we do. And good software is definitely about managing details well. I couldn't disagree with you more.

Yeah.. I got further than you, about 3 pages.. before I decided he was ranting about something I don't consider a problem. I personally find OO helps me protect one portion of a larger system from another.. and partition a system reasonably for maintenance.. but I ALSO know what to avoid in OO so that complexity is reduced. To me.. O-O doesn't get in the way.. and is much better than structured programming (which I used in the 80s and early 90s). The issue that author is worried about just isn't an issue. The REAL issue is there is no magic bullet to replace discipline and rigor in programming.. and management doesn't know how to create high quality because most management doesn't have the engineering experience to even know the real goals to create that (how many managers have I met that only were engineers for 5 years.. when in my experience you don't even achieve first level master until 7-10 years?).

I'm also a musician. :D Lifelong interest in the arts.. Interest in philosphy. I tend to agree!

I tend to agree. Passion for programming is definitely not required. I wouldn't call myself passionate about programming.. Its what I do to make money.. But I AM passionate about QUALITY. And I bring that passion to whatever I do.. programming included. Its why I always suspicious of folks who say they are passionate about programming. I can understand wanting to learn more.. and do things better.. but to me the goal is HOW I deliver things to others, and how many bugs I do/don't create in the process. And how easy it is to use what I deliver. I saw a write up on another site talking about how Object Oriented Programming is a huge fail and needs to be gotten rid of.. the rant goes on for pages.. and its clear the poor fool completely misses the point. Bad software can be written in any language.. because its the level of rigor we do/don't bring to the table that defines our end product. Some languages make it easier to express that rigor in real terms.. but at the end of the day if I get a job at a company 99% of the time the choice of language is not mine.. which means the only thing I have control over is the processes and thinking required to make programs. That rigor part. That is the end I've been working to my entire life.. and why after 30+ years I create very few bugs and provide value to the organization I'm in.. What I'm always surprised by is how difficult it is to sell rigor to the folks I work with.. I'll get lip service.. but rarely real buy in for it.. and in my experience its a true differentiator...and also the reason so much crap is committed to code (i.e. a LACK of rigor).

You are conflating skill and interest.. those two things may meet.. but frequently do NOT. In my life, I've met few truly great programmers.. and to date not one of the greats has been a coder outside of work. I DO see folks falling for the 'I code outside of work' machismo like its something to be proud of.. but to me its never translated to someone how is truly great at getting things done with a minimum of complexity, partitions modules based on logical precepts, and keeps things easy to maintain. Those engineering type skills are severely lacking in most programmers.. which is why I keep seeing so many utter messes that must be dealt with. The panacea of programming that most seek is contained in one word: rigor. Rigor is not based on hours/day.. its based on how you think and apply the lessons of engineering. Working tired actually DECREASES rigor.. Just my 2cents.

I like this list.. more to add: 1. Making all member variables public (usually in the context of unit testing.. but also to increase coupling because the original OO design wasn't decomposed correctly) 2. Making all member methods public 3. lack of use of auto_ptr and other more modern mechanisms for properly handling pointer lifetime management. 4. lack of understanding of exceptions, especially their side effects on locking and memory management. (years of my life has been spent on fixing these types of issues..) 5. misunderstanding by value semantics when passing instances of classes across method interfaces. 6. passing container instances by value (eek!). Note these are ALL things I've directly observed/fixed.

This now qualifies as trolling. Have a nice day.

How long have you been running this way? How many bugs do you fix per week? Saying your business is working means nothing to me.. there are quality measures you either meet or you don't. I'll put it very directly: I've seen folks make money while treating their customers like dogs. And left those same customers with applications that barely worked. You can make money and still create completely useless buggy software. Financial success is important to you I'm sure.. your customers have different motivations..

Heh? so you don't want your user to know to tell the DBA or YOU that something is wrong between the application and the database it uses? Hiding such things is asking for problems down the road. BIG problems.

Absolutely.. Its remarkable easy to write bad code, given how much of it I've seen over the years!

Just an aside.. I absolutely love your sig.. "the language is JavaScript. that of Mordor, which I will not utter here" LOL. I'm a sucker for Middle Earth comments and disparaging comments about Javascript!

Its more than that.. some of the object oriented structures in use in the underlying IL differ between C# and VB. Serge Lidin's IL book covers these differences. If you have to read both languages (and sometimes I do), its useful to know.

You didn't read my post? There are different portions of the IL set used by both languages.. its why they are different. This isn't subject to opinion, its stated fact. Seriously, don't take my word for it: The book is 'Expert .NET 2.0 IL Assembly Language'.. the author is Serge Lidin, HE IS THE DESIGNER OF THE IL LAYER. Most of the language uses very similar constructs.. but NOT ALL. Are you intentionally trolling here?

Is english your first language?

My experience of non-programmers is like this: they are good at small things. Ask them for small programs that do simple things and you are golden. Ask them for anything requiring Systems Analysis and real rigor and you've got serious quality problems on your hands. Its not that you can't get it from untrained individuals.. only that it takes a LOT longer. And 'the hardware layer' is where systems programming lives, which is what I do.. 'cellphone era' is a reference to time, not computers. I really don't know what you are trying to say.. As to C# vs. VB and trainability.. nonsense. I've seen folks pick up both. And seriously: what do you have against programmers?

Seriously? You are using this is a reason to disparage case sensitivity? This same example goes for case insensitive languages.. all it takes is one programmer using 'width', while another uses something like 'wdth', and we have exactly the same issue. I've seen this so please don't say it isn't possible. Beginning programmers cease being beginners when they start looking at the bigger picture and trying to understand that things like this are possible. Which language they use is inconsequential to that understanding. The issue is one of rigor.. not some language feature. You'll have to try MUCH harder than this to be convincing. And note I have no bone to pick with VB. It has driven a lot of business application development and TOTALLY has its place. Its the 'new Cobol'.. another language much disparaged by many but quite useful in my opinion.

They use the same underlying IL machine. I don't think its said anywhere that they are exactly the same.. If you read the book on the IL assembler the author talks in great detail on the differences between VB and C# and how the IL abstractions express them both. That qualifies this argument as a strawman.