Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
3  
People will make fun of you, for one thing :-) –  Karl Bielefeldt Sep 17 '12 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) –  ratchet freak Sep 18 '12 at 0:30
add comment

5 Answers 5

up vote 23 down vote accepted

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.

share|improve this answer
    
+1 Good answer, and thanks for the additional search terms with adding units of measure to C# like in F#. –  GlenH7 Sep 17 '12 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 Sep 18 '12 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 Sep 18 '12 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. –  MainMa Sep 18 '12 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. –  MainMa Sep 18 '12 at 10:21
show 1 more comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

What problems can arise from emulating concepts from another languages?

Leaky abstractions.

share|improve this answer
    
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 Feb 17 at 17:46
add comment

Т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.
share|improve this answer
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. –  comingstorm Sep 18 '12 at 0:04
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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