Maximising Language integration: Holy Grail or Dystopia?

[anonymized user 468275]

Hi all,

The normal (TM) way to create websites is to keep code from different languages mainly separate. The exceptions I have seen so far include generating Perl classes from database tables, embedding HTML and/or DHTML in Perl and embedding javascript and/or CSS in HTML files. These are low-overhead solutions, though not as elgant as they could be. I have also seen a product that stores all code (UI, processing, database meta-language, triggers of various kinds) in the database and has a form-painting interface. But that last solution was rather inflexible and performed too poorly.

And whereas a popular DB solution is to use DBI to send SQL to a database, it's a bad idea to combine objects with embedded SQL in a mult-user environment instead of encapsulating properly designed transactions (e.g. using stored propcedures instead).

It seems to me that Perl offers the tools to produce a single-language (*) solution which both performs, manages transactions properly and can be easy to use. For example, a framework class could inherit HTML, CSS, javascript and database object generation classes, all capable of generating tables and UI sources from a single Perl class designed by the (user-) programmer.

The question I am seeking wisdom for is - is it worth it to fly in the face of the traditional approach of separate sources for different languages? Or to put it another way, is maximising language integration a holy grail or is it destined to being over-compromised and unpopular?

Update: * I am not considering rewriting one language in another, but instead using Perl to integrate the sources of different languages that pertain to one conceptual class, in the interests of maintanability

[Anonymous Monk]

... who's going to write the test suite for and maintain the software which does the code generation?

In my experience the only time that an abstraction like that makes sense is if you know that the targets will change, e.g. abstraction of SQL can make sense if you don't want to be too dependent on which database you're targeting (although my experience has sometimes also been that you eventually do end up using database-specific features anyway, so if you had decided to marry one database at the beginning of the project, you could have avoided the extra abstraction layer).

Other than that - you'll usually only be targeting one version of HTML, one version of JavaScript, etc. - what would the advantages of writing a code generation tool to abstract that be?

Also, right after you say "keep code from different languages mainly separate", you name four "exceptions"... if you spend some more time looking around, I'm pretty sure you'll find that mixing languages is actually pretty common.

[anonymized user 468275]

I am sure you are right about mixing languages being common. My exposure to that is limited though so I am trying to get a feeling of what the trade-offs would be. You are right too about wanting to avoid getting language drivers stuck at particular versions. This happened with the tool I referred to, although customers often believed getting stuck with a language version was an avoidable mistake by the manufacturers. For example, instead the framework could settle for organising code into integration classes without actually generating statements - i.e. one should abstract only what needs to be abstracted for maintainability.

[Anonymous Monk]

It's worth adding that while mixing languages may be common, it's not necessarily maintainable unless done cleanly, e.g. using templates or at least having clear boundaries between the two languages in the source code. In the wild you'll see code like this all the time: print "<span style=\"font-weight:bold;\" onClick=\"alert('bar!');\">";

[Your Mother]

I'm not giving up Perl any time soon but I feel compelled to point out that you can do everything with JavaScript today. Then there is no need for integration. :P

[anonymized user 468275]

Theoretically, maybe. But the reason to put code on the server side (e.g. in Perl) is to limit intra-algorithmic communication across the internet, which would be aggravated by doing it all in Javascript. Having the javascript and HTML embedded in Perl aggravates the OO design. So what I am trying to do is to find a metaframework design using Perl as the 'host' that doesn't violate either of these considerations.

[Your Mother]

Server side JS is quite good and increasingly popular now and even used as a build tool the same way Python and Perl and Ruby have been.

As for your quest and original question: Dystopia. You can build a harness that fits horses, cats, ducks, and alligators but hitching your wagon up with it…

[Anonymous Monk]

using Perl to integrate the sources of different languages that pertain to one conceptual class

I'm having a hard time imagining that. Care to share some short example code?

[anonymized user 468275]

I have a bit of a chicken and egg problem here. If I could write such examples, I'd have answered my own question and could just go ahead and build the classes to support the examples. My hindrance is that I am still struggling with some fundamental decisions. The most promising is to code a web page in Perl as a list of nested objects to match XML structure, each of which may have hooks into database tables, CSS and javascript routines. The support for transferring the inline code into separate sources for each language could be achieved by multiple inheritance. One of the challenges is where to draw the line between declarative and procedural code. One of the concerns is ... would I be re-inventing Template Toolkit?

[Anonymous Monk]

The point was a little more basic than that: You're talking in quite broad strokes with abstract terms, and I don't completely understand the question. You're not going to find a silver bullet anyway, so if you want more pragmatic suggestions, we'll need to know more about the problem space (how big is the software project you are looking at, what technologies does it involve, etc.). The request for sample code was not asking for an example of the solution, it meant show us the problem you are trying to solve.

[anonymized user 468275]

Thanks to all who responded with their wisdom.

As part of this mission, I am studying the w3schools.com Javascript course. It looks like javascript is trying to borrow some good ideas from Perl in recent versions (e.g. use strict). Not surprising given some of its original atrocities. For example null versus undefined versus NaN - omg and I thought having to test (in Perl) with exists() instead of defined() was bad enough! So in terms of what should the host language be to encapsulate the child languages, javascript is definitely not a candidate, owing to the randomly contrasting decisions that were made about typelessness and values in its world (and the number of mobile app bugs I have seen created when data in new versions falls through the cracks in this system). The workaround (of multiplying up) to its having no 'use integer' pragma is particularly disgusting and unscalable and the lack of scoping just about bangs the last nail in its coffin.

On the other hand, arrays would be needed in Perl to represent XML sequences and I already had enough trouble having to maintain these for DHTML output from Perl (via sprintf) - one of the things that got me started with this. Python occurred to me as a more readable way to manage sequences, but was dismissed almost as rapidly when I realised the nesting depth is arbitrary and there is no syntax for dereferencing the nested structures (unlike in Perl and XML)

Looks like I am left with XML as the candidate host format in which to express the Perl, Javascript, HTML and CSS components of a web or mobile application. It has the added advantage of being able to plug in other server languages, like Java, PHP etc., although I may be tempted to compile that into binary XML before deployment. I still haven't given this mission the green light, though.

[sundialsvc4]

(Isn’t this a Meditation?)

Well, I have already seen one project that attempted to do JavaScript on both sides, and the fly in that ointment turned out to be that there was a legacy system in the way.   The general lack of rigor in the JavaScript language turned out to produce a lot of maintenance-time overruns.   If you’re really going to go that way, a “transpiler” technology such as Haxe can be used to generate different code-bases for each side.   But there is already a clean point-of-separation between the two sides:   the JSON or other-IPC boundary.   The host is a transaction server and therefore can be written in any language.   The purported advantages of JavaScript on both sides, I think, are fairly specious.

The key difficulty that I have with the OP’s suggestion is that it adds another layer of ... obscurity and indirection.   There is one step removed from the source-code that is written and what comes out.   Now, you could say that transpilers run the selfsame risk, and you would of course be right.   But I would place more faith in a project that is being maintained by many people throughout the world, than one that is kit-bashed in house.   (That is to say, I would perceive it to have less business risk ... but I still might not approve its use.)

Like every facet of engineering, there are risks and compromises, and very few absolutes.   I think that a well-designed transaction server, talking to a well-designed transaction client, both of which leverage trustworthy frameworks as much as practicable, is a solid architecture.   I do not find it objectionable that more-than-one language is used in its construction, since that is usually the status quo when the (client ...) project starts.

I am also always looking at the long view, since “I See Dead Projects.™”   If the particular approach that you take does not “have long legs,” your project is not going to have a nice, long, maintenance-minimal lifespan in service.   Every software project starts out clean and beautiful.   Trouble is, I usually see them after a (sometimes, not so long) “lifetime of smoking.”   I am therefore nervous that this strategy, enlightened though it may seem to be now, might severely impact maintainability and comprehension in the long view.   However, I have only nervousness to guide me:   yours might be the Next Big Thing.™   :-)

[anonymized user 468275]

A wise reply - thanks! Although I did not mention it in my OP, you are right that I have toyed with the idea of transpiling from some mega-featured single language to the various target languages the web requires. Who knows, I might even decide eventually that it is the easier route. I've already worked in teams where some people are UI guys and others do the business logic. Yes, the world is used to that by now. What is certain is that many organisations spend a fortune developing their framework and no two seem remotely alike and take years to get right. Those who develop without a framework tend to meet a law of diminishing returns. Intuitively there must be a better way (TM). If transpiling isn't the answer, one still needs to improve maintainability one way or another. And if Perl can't deliver on that, what can?