Re: Maximising Language integration: Holy Grail or Dystopia?

[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?