Perl-Sensitive Sunglasses | |
PerlMonks |
Re: Maximising Language integration: Holy Grail or Dystopia?by sundialsvc4 (Abbot) |
on Jul 14, 2015 at 11:52 UTC ( [id://1134699]=note: print w/replies, xml ) | Need Help?? |
(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
In Section
Seekers of Perl Wisdom
|
|