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?
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.
Т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,
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.
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.
