What programming 'religious' position or argument bothers you the most?

123 accepted

I would have to say the position that bothers me most is the almost venomous rejection of open source I am greeted with in some circles.

The same goes for the open source believers that attack proprietary software based on nothing but the fact that is not open source.


I don't like it when Knuths quote: "Premature optimization is the root of all evil" is used like a mantra.

Throwing a slow O(nē) bubble-sort into an application and mumbling that "Premature optimization"-mantra is way too often used as an excuse to deliver shitty code. I think it's always well worth the few minutes to pick an algorithm or data-structure that is more suitable to the problem.

That way you save the time for refactoring and optimizations in the long run because once a program is exposed to real world data brute force algorithms tend to become a major problem. And it will take longer to replace a piece of code than to do a good choice at the first place.

Imho that quote has been written in the context of code that is already free of brute force algorithms. It applies to needless, premature optimizations like cache-aligning writes in general purpose code.


Script languages aren't real programming languages.


I'm a Baptist. I love religious arguments.

Oh, but in context, the one that annoys me most is "Don't reinvent the wheel". I've seen organizations time and time again spend three months searching for an "off the shelf" solution and six more months customizing it to their needs, when we could have written it from scratch in a month.


All religious arguments really boil down to the false notion that one particular solution is the best for all circumstances. I think that people who make religious arguments (and I USED to be one of them) really haven't learned a basic fact. Any one language, OS, DBMS CAN be used to solve ANY problem. However, that doesn't mean that you won't be fighting your favorite religious package to shoe horn it into your solution.

Being anti-religious with regards to software is just a matter of accepting that in order to make the best solution, at the best price, you need to have a breadth of languages and systems under your belt. Some things are just better designed to handle some things than others.


Mac vs PC, especially from people who don't know how to use either one well

name-brand vs clone, especially when the hardware is all made by the same offshore manufacturer

scrum vs xp, especially when this is an excuse for not getting things done

microsoft vs not-microsoft, especially when this is fueled by programmers who aren't very good in the first place

but my favorite is still the-only-language-i-know vs the-only-language-you-know


Emacs vs Vi.


Spaces vs. Tabs


I would say programming paradigms are it for me. Most of it's centered around OOP. Some will say that OOP is the worst thing that's ever happened and that anyone who uses an an object oriented language is a terrible programmer (bonus points if they say we should all go back to writing C). Then of course, you have the people who say that OOP is the best thing since sliced bread and that OOP is the panacea to all of life's problems (although these types are becoming less common).

Both of these points interfere with the best way to do things: choosing the best tool for the job.


3-tiered (or n-tiered) design. It's like a chef decreeing that all food must be layered - this works great for lasagna, not so much for a steak.

"Many-teared" is another term for it.


When people get upset about source code formatting and related coding standards.

I have no problem with formatting rules that have practical effects (i.e. "putting the paren there makes it easier to grep for function calls"). But huge arguments over whether an opening brace should be on the same line or on the next line? Haven't we evolved past that?

Now, I see the value in having a large body of source code look consistent. I'm just talking about getting emotional about particular individual rules like mandating the spacing around parentheses or getting anal about indentation.


That goto statements should never...ever be used.


There is already mentioned holy war between open source and proprietary software. I'd like to stress one of its fronts that bothers me the most. It is holy war between *nix systems and windows. I've heard hundreds of times about Windows' instability, security holes, slowness etc from people that are considered to be good developers or administrators. And they really are. But when they speak about Windows they completely lose their objectivity and become crusaders of *nix. I am not really big fan of Windows systems but I had to use it as well as *nix systems and I see both pros and cons in both worlds.


Java is slow


If you don't know <foo> then you don't really know how to code.


There isn't really one religious argument that bothers me the most - all of them bother me because they all take time away from the important task of delivering great software.

Some arguments like Hungarian notation, the use of var in C#, and whether your brackets are on the same line or the next line, are at least fairly harmless. It doesn't matter which way you go as long as everybody on the team agrees to stick to the convention (note that I didn't say agrees with the convention, as that's fairly unlikely in any sizeable team).

However other arguments are more problematic as they make it less likely that you'll deliver great software, or that you'll deliver at all.

One of the worst groups for this are the TDD zealots who believe it is the only way to code, which it simply isn't in many circumstances, particularly in extremely fast moving and changeable organisations [so actually I'm probably lying - this is the one that bothers me the most]. Other arguments that cause problems are a strict adherence to an architectural style in the face of alternate requirements (e.g. using object-orientation when distributed performance is more important than ease of programming).

But essentially all religious arguments are detrimental on one way or another, and all bother me because their presence is an indication that you're working with cargo cult programmers. Just choose one way or another for the trivial ones, and make sure you have someone who understands the complex ones that can make the right choice based on experience and reason rather than beliefs or blog entries.


Saying that a language is better/worse because it uses semicolons/indentation. (i.e. Python vs. C-like languages).


What I don't like is someone who opens with the "I don't want to start a religious war here, but, ..." gambit followed by something they know is inflammatory.

Often, they'll layer in the evasions with other moves like "I'm just curious why you feel..." or "It seems contradictory to both ... and ..." or "Why does ... work so poorly?"

All of these are usually revisions of "I prefer [X]; you have no compelling evidence to the contrary, neener-neener-neener."

How about just present the technical merits (whatever they are) and the all-important personal biases, and leave off the opening gambit?

The few people that are actually curious never seem to play the "religious argument" card. They just ask.


The one i particularly hate is:

"Every time you use a global variable, a kitten dies".

I know its not "entirely" correct, but cīmon, everything depends of its context.


I dislike the religious arguments over use of the C preprocessor. There's some strange idea that the preprocessor is inherently evil, when in reality its proper use can lead to far more maintainable and readable code. This can often be better than functions, because in some cases you have a "function" which, if made into an actual function, would need a dozen or more arguments, peppering the code with long, ugly function calls. If the "function" is simple, a macro might be more applicable.

Much like GOTO, few things are "inherently evil"; what is evil is overuse of anything, regardless of what it is.


I just had enterprise versus opensource in mind (where enterprise=good because opensourse=bad), but now, this question bothers me the most:

"What programming religious argument bothers you the most?"


Curly brackets on the same line as method declaration (or if /try/catch/etc) or next line.


Using huge Enterpris-y logging / auditing frameworks for even the most simple tracing task.

The configuration complexity of some of these frameworks boggles the mind, and if you need to do something slightly different than the framework provides (for example, DB logging and the provided formatter/listener/whatever has a horrible implementation) - I now have to write a CUSTOM bit ontop of a gangly framework for what? So that we can say we use log4whatever and pat ourselves on the back?

They certainly have their place, but like most religious arguemnts my point is that their place isn't everywhere.


.NET = Microsoft = Evil. Java/PHP/C++/etc. is better!


Whether a language is really object-oriented. (For instance Javascript or Objective-C.) Who cares? If it works for me, it works for me.


As you might guess, the answer for me would be: Mandatory OpenId

To clarify: my problem is with making OpenId mandatory in order to force people to convert to a technology. If everyone decided tomorrow that it was the way to do it, I am all for that. But I have a problem with making it mandatory simply to get people to convert and see the light.

My concerns about OpenId are spelled out:

What are the benefits of making OpenId mandatory question

I moved this from the question body to keep the question and my mandatory OpenId rant separate.


I don't know if it's really a religious argument, but it really bugs me when people do premature optimizations for things that they should know don't matter... like avoiding throwing exceptions for what should be an exception... or even more minor things like ++i versus i++.

When you blindly optimize things like that, it can become a real danger. More often than not, this sort of micro optimizations creates code that might be micro or nanoseconds faster, but at the cost of being hugely less readable.

I think it is much better to evaluate performance based on actual statistics of the code's actual performance, and then improve bottlenecks based on these facts. Thus, write your code so that it is the most readable, and only then refactor for performance.

This of course does not mean you should never do optimizations ahead of time, it just means you should think about what the performance gain you will actually get with realistic data versus the maintainability hit you might get as a result (copying a java array of a small amount of items to an ArrayList for huge readability gains should not be converted to an array just for performance reasons... but if it is likely to be an array of 1,000,000 items... then it might be worth rethinking the approach ahead of time).


open vs. closed source

and its sister...

Linux vs. things not Linux...


The "not invented here" argument is really tiring. Especially when it results in someone deciding to reinvent some complex concept and you know that there is no way it is going to be better than using existing implementations.
If it's not a core business and there is an existing implementation that is free or reasonably priced don't invent your own!


general tool(language,IDE,platform,whatever) selection

as an example OOP has been pushed so hard as being the best thing ever that it gets bent and twisted to fit a problem that a procedural model fits better. Ironically usually resulting in code that more complicated and less extensible than it would have been if built under procedural model. choosing a tool because it has a "object oriented!" marketing gimmick/buzz word attached without real discussion of how or why it makes something better is something i've seen several times. The reverse is of course equally as bad, however i don't see it often as it seems everything is OO these days.

in general i see a lot of bending of problems to fit a tool because its "in" or "new" or whatever other reason comes up.

choose the tool that fits the problem, don't redefine the problem to fit within a prematurely chosen tool set.


Not that there must be unit tests, but that development MUST be TDD.


Native vs. Managed Code


Agile Programming vs anything.

Agile programming is great. We use a form of it at work - but I cringe reading about sprints and scrums and whatever other religious dogma comes from the Agile Manifesto. There are a lot of good ideas there - but they can be implemented in a number of ways and [gasp/] with varying terminology.


Yikes, just because a belief is "religious" does NOT mean that it is without reason. I think that a religious belief in terms of programming is more along the lines of making a technical decision because of a not too technical reason. Like for OpenID: the idea that having a single secure login is convenient and is the correct method. The belief doesn't have a technical reasoning behind it, just a belief. But with your take on religious belief,I would have to agree and say that, that is always a wrong way to find a solution.

Oh, and I hate C++ programmers who denounce Java because of its speed and "verbose" syntax.


When people claim open-source software is better than proprietary software.

I'm not denouncing open source as being harder to build/maintain, nor complaining that it's free, nor comparing it with communism (Not here, at least)... But I trust software alot more when peoples' livelihoods rely on it working.


Constructive arguments that aren't, and instead a rant ensues. The worst variants drip with Computer -Science/-Technology Priesthood pretense;

I'm not exempting myself from, at times, being guilty as charged. But here's where I'll eat my own dogfood and attempt to be constructive:

Let us both uphold correctness (in the mathematical sense) AND recognize that there is an ecosystem of software/hardware developers that, by analogy to natural ecologies, has a range of sophistication among its members—this is not a weakness, but a strength.


Religious arguments are good. I have my experiences that have worked well for me, and others have had different experiences that worked well for them.

The religious argument kicks in when two people with different experiences are trying to solve the same problem based on what has worked well for them in the past.

The only time any of this bothers me is when both sides are so closed minded that they refuse to see value in the others solution - and ideally, come up with something better than what either has created before.


Source Control:

Branch and Release Vs Branch Develop & Merge


I've come to believe that "choosing the best tool for the job" is a religious argument -- and one that irritates me to no end. I mean, clearly you can't write a driver in python, or a web application in C...

... but the choice between perl/ruby/php/python tends to be a matter of personal taste rather than which "tool is right for the job." I wish people would realize that personal taste is ok and these tools tend to cover all the same jobs. I prefer vim over emacs too, ymmv.


"Language wars are for morons", to quote a developer I once worked with.


My language is better because I know it, know yours, and thus your wrong. Okok, a bit over exaggerated. But the point is, I hate wars fuel'd when it comes down to some opinionated effort to push some newer technology on the point that, "I like it". AKA Language Holy Wars.

Drives me crazy... especially in a academic sense where your voice often gets washed out.


The brace style religious debate. Everybody knows that the One True Brace Style is braces on newlines! Why do they persist in putting them inline? And what's wrong with those Python people?! :-)


"It's a Microsoft world! I haven't used any non-MS software, though. Come to think of it, all I have used is ASP and Access."

"PHP sucks. Also- I haven't used it in a year or so, but that doesn't matter."

"HTML / CSS / JavaScript is the bane of my existence!"


Indentation and brace alignment rules anoy me. Any decent editor allows you to reformat the code to your personal style, then you can just have a pretty print program run on every checkin so that whitespace doesn't show up in diffs and the code gets checked out in a consistent fassion.


"Code must be unit tested"

But what annoys me most about that line, is that i believe in it myself!



C++ is faster ( and better ) than C#


I can't stand the "PHP IS BAD" people, I usually want to shove their foot up their own..........


It's all about C/C++.


Several things:

  • open source vs closed source
  • Linux vs Windows
  • GC vs malloc/free

Semantic arguments annoy me the most. If I say "Open Source", someone else says "No, free software!!", then a diplomat comes along and says "Just call it FLOSS, make everyone happy!"

Likewise, the reverse of that is true.

I think it takes time away from actually understanding how people want to use their computers, which is what we should really be doing.

This is separate from the license wars, its just nit picking on a term. I can say "cheese" or I can say "cheddar", you know what I'm talking about either way.


I'm personally very fanatical about Java and the commercially-friendly open source, even though I know its not all panacea made in heaven.

And I hate the whole meaningless sphere of rules, patterns, conventions, standards, etc that come with little reason to back them up, except for "you must apply this pattern coherently or follow that rule adherently or else you're doing it wrong".

I am a very practical person, and if the rules tie my hands for nothing, I just bend them or throw them out altogether.

I have no patience for fancy doctrines, so if I ever need to submit my soul, I can always turn to money (maybe religion?)


Design patterns. Sigh.


Let us not forget the great Design Patterns Debate! With the "don't re-invent the wheel" camp lined up against the "patterns are so over-rated" set.


Hungarian notation or not debate.


I am an agnostic. I believe the right answer is out there somewhere, but I am just not sure what the right answer is.