I've read many times on the web that if your language doesn't support some concept, for example, object orientation, or maybe function calls, and it's considered a good practice in this other context, you should do it.

The only problem I can see now is that other programmers may find your code too different than the usual, making it hard for them to program. What other problems do you think may arise from this?

  • 3
    People will make fun of you, for one thing :-) Commented Sep 17, 2012 at 22:17
  • I've translated a nested function parser from D into java once but I'll admit it's not the cleanest piece of code I've ever written (one big function with an interface and several classes implementing it defined inside it) Commented Sep 18, 2012 at 0:30

5 Answers 5


One of the problems is that you may find yourself writing lots of code to express something in a way you will do in another language, while there is a more straightforward way in the language you use.

For example, in an answer on Stack Overflow, I've explained how code contracts, concept used in .NET Framework, can be partially emulated in PHP which doesn't support them. I ended up writing lots of code for nothing, since the same thing was doable with simple arrays.

More generally, each language has its own culture, its own best practices, its own style.

  • If I start writing C# code like it was C, it would be ugly.

  • If I apprehend Haskell as a Java developer who was forced to use Haskell, but don't want to understand its strengths and just want to clone the concepts of Java, the code I would write will suffer.

  • etc.

There is nothing wrong trying to enhance the language (for example enhance C# by introducing units of measure like in F#), but if you are doing it too much, you should maybe choose a different language which actually fits your needs.

  • +1 Good answer, and thanks for the additional search terms with adding units of measure to C# like in F#.
    – user53019
    Commented Sep 17, 2012 at 21:32
  • 2
    As one who once quit his job because of being forced to use Java, my 2 cents: one cannot get forced to use Haskell, one falls in love with it and then it sucks you in to the point of no return. Haskell is like one lovely black hole you just want to fall into - and unlike a real one, you still live to tell the tale :)
    – Cetin Sert
    Commented Sep 18, 2012 at 0:22
  • you should maybe choose another language... except when you don't have a choice, such as client side JavaScript. (Even so, having no choice is no excuse for implementing class-based OOP emulation in a prototype language. It's far more efficient to just learn how the language works.)
    – kojiro
    Commented Sep 18, 2012 at 3:44
  • @kojiro: or another job. I had the same issue myself when I was forced to use PHP, and I was constantly trying to modify the language, including writing my own compiler. An less crazier solution was to change my job and start to work only on projects which don't use PHP. Commented Sep 18, 2012 at 10:19
  • 1
    @Cetin Sert: agree, Haskell is an excellent language. But if somebody don't want to learn it and don't understand functional programming, it would be difficult to appreciate Haskell. Commented Sep 18, 2012 at 10:21

Тhe drop in readability is enough of a problem in itself: it drastically decreases the pool of people who could potentially maintain your project without an extensive training from you.

In addition,

  • Implementing the foreign paradigm may cost more than the potential savings from its use
  • Your adaptation of the foreign functionality may be buggy, increasing the costs of maintenance
  • Your adaptation of the foreign functionality may push your technology stack to the limits beyond these required by your native implementation.
  • 2
    I once had to emulate C++ dynamic dispatch (virtual tables, etc.) in vanilla C, and ran into exactly this problem: C programmers who didn't understand dynamic dispatch were unable to contribute to or maintain the project. Commented Sep 18, 2012 at 0:04

It's not as good idea as it appears on paper.

Example 1: If you're old enough, you may remember the days when C was the new kid in town. Pascal and Ada programmers didn't like C's terse open and close braces. They #defined begin and end to open brace and close brace, and voila! CAda! The unfortunate result was ugly from the perspective of either Ada or C.

Example 2, personal: One of the things I really liked about the Common Lisp Object System is it's before, after, and around methods. They can come so in very handy in multiple places. So I emulated this concept in C++ in a few select places. The only way to emulate these constructs in C++ is to require the developer of a derived class to call the parent class' method of the same name at the right place in the code. This put a requirement on developers who derived from my classes that was a bit foreign to C++ programming, and perhaps against the grain of C++ programming . No matter how well documented this requirement was, people just didn't follow the guidelines because it didn't quite fit the C++ paradigm.


What problems can arise from emulating concepts from another languages?

Leaky abstractions.

  • It might be nice to include some more details within your answer. The article relates a case where an abstraction fails to capture a significant performance optimization, but I'd say bigger problems arise from inconsistent corner-case behavior and inconsistent guarantees; an example of the latter would be C#'s attempt to emulate out parameters in a framework that doesn't really support them; C# assumes that every function will always write to all of its out parameters, but non-C# methods called by C# methods offer no such guarantee.
    – supercat
    Commented Feb 17, 2014 at 17:46

It can be prohibitively difficult. Imagine trying to implement LINQ from C# into your Java application. Or how about just adding lexical closures to a language? You would pretty much have to write a new compiler, which pretty much gives you a new language.

Or,for cases where you don't have to implement your own language, just imagine trying to implement collection methods using higher order functions (like map) in a language that doesn't have code blocks or lambda functions or closures or functions as first class objects. Every higher order function has to be declared as an interface and implemented explicitly, and all state that would have been captured in a closure must be explicitly stored in the implementing class. It's so much extra typing, and so much harder to read, that it often isn't worth it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.