Why is it bad to write something in language X as if you're writing a program in language Y in terms of using a shared coding paradigm

Question

A while ago, I asked a question on SO about something written in C++, but instead of getting an answer to the problem at hand, the comments went all crazy on my coding style, even when I indicated that it was a WIP piece of code and that I meant to clean it up later when I had the base case running. (I got so many down votes that I decided to pull the question, as my rep on SO already is near-abysmal)

It made me wonder why people adopt such a hard line "you're a noob, go fuck yourself" attitude. I was being accused of writing C++ as if it was Java. Something that I cannot understand, and that still baffles me.

I've been programming in quite a few OOP languages for a number of years now, albeit in intervals. I choose the language to use in terms of its available libraries and optimal execution environments for the job at hand. I adopt design patterns in OOP code and I'm quite confident that my use of patterns is sound and that OO wise, I can hold my own. I understand the OOP toolbox, but choose to use the tools only when I think it's really required, not to just use a neat trick to show my coding wits. (Which I know are not top notch, but I think aren't at n00b level either).

I design my code before I write a single line. To define tests, I list the goals of a certain class, and the test criteria that it has to adhere to. Because it is easier to me to create sequence diagrams and then write code, I chose to write my tests after the interface has become obvious.

I must admit that in the piece of code I posted in the question, I was still using pointers, instead of using smart pointers. I use RAII whenever I can. I know proper RAII means safeguarding against nullpointers, but I work incrementally. It was a work in progress and I meant to clean it up later. This way of working was condemned strongly.

In my view, I should have a working example first so I can see if the base case is a viable way of thought. I also happen to think that cleaning up the code is something that is typical of the refactoring phase of agile, after the base case has been proven. I must admit that although I'm slowly getting the Cxx standard, I prefer to use what I understand, instead of taking the risk of using concepts that I have yet to master in production code. I do try new stuff once in a while, but usually in play projects that I have on the side, just for that purpose.

[edit] I'd like to clarify that gnat's suggestion [1] did not show up in the search I did before I started to ask my question. However although his suggestion does cover one aspect of the question, the question he linked to does not answer the heart of my question, just part of it. My question is more about the response I got to my coding style and the professional aspects of handling different coding styles and (apparent) levels of skill. With my previous question on SO and it's response as a case in point. [/edit]

The question then is: why scoff someone that doesn't use your coding style?

The matters/subdivisions at hand for me are:

• Why would it be a bad programming practice to use more error prone code in prototype situations, if refactoring makes it more robust afterward?
• How would can program written in C++ be like it was written in Java? What makes it a bad program, (considering that I indicated the intent of the current style and the planned work to improve?)
• How would I be a bad professional if I chose to use a construct that is used in a certain programming paradigm (e.g. OOP/DP)?

[1] Develop fast and buggy, then correct errors or be slow, careful for each line of code?

Answer 1

Each programming language has a set of idioms and best practices, which will usually lead to elegant, correct, and performant code. Here are a few worst-practices that are perfectly fine in some other language:

• I will yell if you write for ($i = 0; $i < 42; $i++) { … } in Perl, but not in PHP
  (in Perl, variables should be declared, and such loops should iterate over a range)
• I will weep if you write new Foo() in C++ without good reason, but not in Java
  (C++ doesn't have garbage collection, so RAII should be used. Noobs will leak memory otherwise)
• I will cringe if you declare all your variables at the top of your function, except in C89, Pascal, or JavaScript.
• I will facepalm if you put all your functions into a class in Python, but not in Java
  (Python is a multi-paradigm language instead forcing “OOP” and supports functions at the top level)
• I will cry if you return null in Scala, but not in any C-like language
  (because Scala has an Option type)
• I will complain if you write a recursive algorithm in Java, but not in OCaml
  (because Java's stack overflows quickly, whereas OCaml has tail call optimization)
• …

It is easy to use a new language as if it were something you know, and with luck it will even work. “You can write Fortran in any language”. But you really don't want to ignore the specific features language X offers, because chances are good that X offers some advantage over U.

“I choose the language to use in terms of its available libraries and optimal execution environments for the job at hand” – but whether this language X is actually better than language U for the job at hand also depends on how familiar with that language, or how long it will take to get sufficiently familiar in order to use it well. You wouldn't yield a heavy chainsaw just because it cuts wood fastest, when you actually want your old pen knife because it fits into your hand perfectly. Unless you actually want to fell a tree.

But your question is more about a cultural issue: learning all best practices takes a lot of time, and newbies ask the most questions, whereas gurus answer them. But what is obvious to a guru is not obvious to a newbie, and gurus sometimes forget that. As a newbie, the solution is not to stop asking questions. However, one can show an openness to learn and apply best practices, e.g. by trying to clean up your code as much as possible before showing it to others. Most languages have a few core best practices which are easy to learn, even when the whole learning curve is actually very long.

A common problem is that people new to programming disregard any indentation or other formatting, and then are confused because their program doesn't work. I would be confused as well, and the first step to understanding a program is making sure it's perfectly layouted. Then, simple errors like a forgotten closing quote or a missing comma suddenly become obvious. I trust that you already practice good formatting, and here it's a metaphor for other best practices: best practices prevent errors, best practices make finding errors easier, applying best practices comes before finding the problem.

It is too cheap to say “I'll fix it later”, when fixing it now would have solved your problem (also, that fabled “clean-up phase” may never come, so the only responsible option is to do it right the first time). At the very least, trying to make your code as good as possible before asking others for help makes it easier for them to reason about your code, so is the polite thing to do.

Answer 2

Without seeing the code in question, there are a few ways to write Java code in C++, some worse than others.

1. At the one extreme, there's laying out your source like Java: everything in one file, everything within the class definition, etc.:

   class HelloWorldApp {
   public:
       void main() {
           cout << "Hello World!" << endl;
       }
   };
   

   This is how Java source would be laid out. It's technically legal in C++, but putting everything in the header file and everything inline (by defining it in the class declaration) is terrible style and will kill your compile performance. Don't do it.
2. Excessively OO - To oversimplify, in Java, it's the Kingdom of the Nouns, where everything is an object. Good (i.e., idiomatic) C++ code is more likely to use free functions, templates, etc., instead of trying to cram everything into an object.
3. No RAII - You already mentioned this - using pointers and manual cleanup instead of smart pointers. C++ gives you tools like RAII and smart pointers, so good (i.e., idiomatic) C++ code uses those tools.
4. No advanced C++ - The basics of Java and C++ are similar enough, but once you get into more advanced features (templates, C++'s algorithms library, etc.), they start to diverge.

Except for #1, none of these make a C++ program a bad program, but it's also not the kind of code I prefer to work on as a C++ programmer. (I also wouldn't enjoy working with non-idiomatic or C-style Perl, non-idiomatic Python, etc.) A language has its own tools and idioms and philosophy, and good code uses those tools and idioms instead of trying to use the lowest common denominator or trying to reproduce another language's approach. Writing non-idiomatic code in a particular language / problem domain / whatever doesn't make someone a bad programmer, it just means that they have more to learn about that language / problem domain / whatever. And there's nothing wrong with that; there's a very long list of things I have more to learn about, and C++ in particular has an absolute ton of stuff to learn.

Regarding the particular question of writing error-prone code with the intent to clean it up later, it's not black and white:

• If some prototype code fails to handle every possible exception and every possible corner case, then that's to be expected. Get it working, then get it working robustly. No problem.
• If some prototype code is written in what's simply a bad style or a bad design (bad for the given language and its idioms, a fundamentally bad design for the problem, etc.), then unless you're writing it as a throw-away proof-of-concept, you're not gaining anything.

To use raw pointers versus smart pointers as an example, if you're going to work in C++, using RAII and smart pointers are fundamental enough that it should be faster to write code that way than to go back and clean it up later. Again, failing to do this doesn't mean someone's a bad programmer, unprofessional, etc., but it does mean there's more to learn.

Answer 3

I'm not a hardcore C++ developer, but...

Why would it be a bad programming practice to use more error prone code in prototype situations, if refactoring makes it more robust afterward?

One thing to keep in mind is that an error in C++ usually means "undefined behavior". In a safe language the worst that could happen is an exception terminating your program immediately. In C++, you're lucky if you get a segfault. It's entirely possible your program keeps going doing something subtly wrong. It could also behave correctly for a period of time and manifest bugs much later, or it could behave correctly all the time but eventually eat up all your memory.

In any case, it only takes a single mistake to take program execution completely off the rails and into uncharted territory. It's likely that for the full-time C++ developer, the "base case" means "no possibility of undefined behavior or memory leaks."

How would can program written in C++ be like it was written in Java? What makes it a bad program?

I don't think there's an answer to this that won't be largely speculatory and opinionated. If you want my take on it though, Java tends to have a couple of antipatterns associated like the fact that everything has to be an object. Where in other languages you'd pass a pointer, functor, or function, in Java you usually find tons of vacuous and narrowly-useful ThingDoers, FooFactories, and IFrobnicators which are just functions in disguise.

Likewise, where in other languages you might pass a simple tuple or nameless struct, in Java to bundle up even just 2 objects into a simple data container requires you to predefine a 30+ line NamedThing class with setters, getters, and Javadocs. Java's relative lack of features forces programmers to do object-oriented double backflips to get things done sometimes. The resulting code is rarely idiomatic outside of Java.

Then there's the fact that in C++ you need a very simplified object graph to manage memory manually; usually an object is owned by exactly one other object. In Java you don't need to follow such tight constraints, because the garbage collector ensures things will get cleaned up when there's no more references to them. So there's definitely a risk of incorrect memory management if you just transliterate code from Java to C++.

Finally, it could just be elitism. I won't pretend they make up the majority, but I've definitely seen a sentiment of "I don't need a language that'll hold my hand and keep me from doing stupid things" amongst some C++ developers. In their minds C++ is a "real" language and if you can't handle its idiosyncrasies you're not a "real programmer".

Answer 4

Slightly off topic answer...

Don't worry - this is a common "behavior" in any expert community. And be honest, if you're good in any language, and you will meet a code what is "strange", probably you will criticizing it too. (because, want TEACH).

I'm in the perl-world - when will see something like:

$imax=$#array;
$str=""
for($i=0; $i<$imax; $i++) {
    $str = "$str" . $array[$i];
}

instead of:

my $str = join '', @array;

sure will comment it - (read: teach the author) about the join function.

Anyway, too much criticism is counterproductive at all, and one of the best example is the next: (grabbed from: http://perl-begin.org/humour/#How_can_I_switch_off_the_T.V..3F)

(This bit was posted anonymously to a pastebot on 23 March, 2011. It is placed here for posterity after some editing.) - slightly edited too

Question: how can I switch on my TV?

What the OP wants to hear?

For example: Locate on/off button your TV remote a press it. The button is usually red and located at the topmost line on the remote.

The #perl expert's answer: First, what do you mean with "switch on"? Define it first. Nopaste your TV, TV remote and the living room too.

... after a nopaste:

Your room is ugly. And the TV looks terrible. Use Mr. Clean on the screen, and clean your living room first. Use three cleaning mops instead of two. Use HDMI and never use scart (?) connectors, unless you really want to. Your TV remote has unreadable buttons, clean up first. You're a beginner, so read:

http://experts.blog/how_to_design_a_future_3D_TV.html http://experts.blog/the_basics_of_tv_repairing.html http://experts.blog/viruses_in_living_room_short_essay.html http://experts.blog/global_chip_replacement_guide.html

IRC guest: But, i don't want be a TV expert.

Answer: Why do you want to switch the TV on then?!

Answer 5

Why would it be a bad programming practice to use more error prone code in prototype situations, if refactoring makes it more robust afterward?

When writing quick and dirty with the mind of fixing later there is the danger of forgetting something that you need to fix.

How would can program written in C++ be like it was written in Java? What makes it a bad program, (considering that I indicated the intent of the current style and the planned work to improve?)

In java you don't have to think about who owns a certain object, you just pass the reference along and forget about it like it is nothing. However in C++ there needs to be a clear definition of who owns the object and who is responsible for cleaning it up.

How would I be a bad professional if I chose to use a construct that is used in a certain programming paradigm (e.g. OOP/DP)

You wouldn't; C++ is a multi-paradigm language, it happens to support OOP rather well but it can do a lot of other things as well. However most of it boils down to using the correct tool for the job instead of pulling out the hammer each time you need to drive a pointy spike into some wood.

The reason you got a bad response is that most people on SO tend to judge skills by how idiomatic you can code in the language you are asking about. The people familiar with C++ tend to knee-jerk when they see bad code that looks like something that has bitten them in the past.