3

Many projects combine languages, for example on the web with the ubiquitous SQL + server-side language + markup du jour + JavaScript + CSS mix (often in a single function). Bash and other shell code is mixed with Perl and Python on the server side, evaled and sometimes even passed through sed before execution. Many languages support runtime execution of arbitrary code strings, and in some it seems to be fairly common practice. In addition to advice about security and separation of concerns,

  1. what other issues are there with this type of programming,
  2. what can be done to minimize it, and
  3. is it ever defensible (except in the "PHB on the shoulder" situation)?

Edit: To clarify, this is not about using more than one language for the job - That's a good thing for any but the simplest projects. The issue is mixing languages in the same file, such as magic strings for SQL, Bash & Perl eval, and the like.

Improve this question
5
  • 17
    I think that blind adherence to "Best Practices" dogma is a "Developer Smell"™
    – maple_shaft ♦
    Jun 28, 2011 at 15:59
  • 3
    @maple - Only when it's applied without understanding the benefits and drawbacks. Otherwise, I find no compelling reason to not follow what the top people in our profession say is the best way to write software; after all they are the "best" for a reason.
    – Wayne Molina
    Jun 28, 2011 at 16:04
  • 3
    There is nothing wrong with nesting languages. In fact, the more you're doing it - the better. There is no such a thing as "general purpose programming language", each language fits only a narrow problem domain. So, each task should split into a number of different languages, ideally - seamlessly integrated.
    – SK-logic
    Jun 28, 2011 at 16:13
  • 1
    @SK-logic: Nice straw-man. I wasn't advocating using only a single language for everything, only to avoid mixing them in the same file.
    – l0b0
    Jun 29, 2011 at 6:39
  • 2
    and I am advocating mixing them. Because otherwise you'd have dozens of files instead of just one, with quite a loosely tangled logical relationship. As a trivial corner case - imagine separating all the regular expressions and SQL queries from the host language. Each into a dedicated file.
    – SK-logic
    Jun 29, 2011 at 7:36

5 Answers 5

Reset to default
8

Other Issues

I find that mixing languages can cause:

  • code to become unreadable;
  • subtle ‘encouragement’ to developers to use the wrong language for the wrong job;
  • longer source code;
  • subtle ‘encouragement’ of copy-n-paste programming.

Minimising it

Is simply a matter of developer education. On the web front end side of things there are well established standards to externalise JavaScript and CSS from HTML. Less can be done in regards to HTML source code that is actually part of a server side language templating mechanism (PHP, ASP, JSF, JST, et al.), but even that can be laid out in a clean way.

On the server side you have well established DAO patterns that ensure SQL is all in once place (and hopefully injection attacks are mitigated as well).

Is it defensible?

Mixing languages isn’t always wrong per se, especially if it can add clarity to the source code in a safe way (i.e., it doesn't introduce a security issue). I typically stay away from mixing as much as possible, mainly due to readability and security concerns.

Improve this answer
3
  • 2
    And my experience is different. I find that mixing languages makes code more readable than if you have to keep related pieces of logic separated from each other. Mixing languages together gives a much more dense and still more maintainable code - as it frees you from the interop boilerplate.
    – SK-logic
    Jun 29, 2011 at 7:38
  • 2
    I don't entirely disagree, I've just seen too many bad examples of it - so I default to splitting it out.
    – Martijn Verburg
    Jun 29, 2011 at 7:49
  • 2
    of course, as with any other tool or technique, one must know well what he's doing. There is a huge potential for a misuse in each and every programming approach anyway.
    – SK-logic
    Jun 29, 2011 at 7:52
6

Other issues I can think of besides those Martijn have noted.

  • Screws up code-highlighting in text editors
  • Makes it difficult to separate tasks among team members
Improve this answer
2

Another issue I sometimes see, especially in the mixing in of SQL with other languages, is that the nested code is not syntax-checked by the IDE; it's either in some block that the IDE knows is not its native language and so it doesn't bother, or it's in a string (a "magic string" as I've often heard them called) which is simply data until some framework feature translates or transmits it into some form or place where it can now be interpreted and executed as code. This end-run around compile-time syntax checking greatly increases the possibility of runtime errors which can only be caught by comprehensive, 100%-coverage testing.

Apart from that, I agree 100% with the problems Martijn listed, especially the readability.

Improve this answer
1
  • "This end-run around compile-time syntax checking" Hardly a end-run around if your language isn't compiled.
    – Paul Draper
    Jan 14, 2017 at 2:24
1

There are a few big issues I could see with this:

  • Generalists may be required that have all some degree of proficiency in all those areas as this is a few different kinds of design getting mixed together, a relational DB, OO, and UI. This may not be easy to find the few good people to do the job.

  • Maintenance of such a system can be problematic if everything is together in a spaghetti code or kludge as getting something fixed may take longer than if things were broken down into a better organized solution.

  • Performance issues may pop up as optimizing the code may not be done as well as if everything was structured differently.

To minimize these:

  • Communicate the trade-offs to the project sponsor of doing the quick and dirty solution versus the well-built one that may take a little longer but provide better value in the long run.

  • Break down projects so that separations happen.

Defense of such practice:

Proof of concept work comes to mind of a case where mixing things together may be defended better as this is just showing something as being feasible. Unfortunately, some non-technical people may think that prototype should be used in production and is robust without realizing what they had agreed would be built.

Improve this answer
0
  • If you mix PHP (or other server side language) with JS, your JS won't be cacheable (if your PHP isn't).
  • Nested languages are like code generators, very hard to understand the generated code

My solution is to minimize the coupling between different languages by never generating code, using JSON as the data transfer between languages

PHP example (tightly coupled)

var arr = [];
<?php  
foreach($value in $phpArray) {
    echo "arr.push('$value');\n";
}
?>

PHP example (loosely coupled)

var arr = <?php echo json_encode($phpArray) ?>;

Notice that with json_encode, you don't have to worry about escaping strings or any other values.

Improve this answer

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