"I agree the decimal math isn't optimal in Javascript, but it seems like
such a small thing compared to adopting an entirely other language to do
the business logic "
Hmm, I'm not sure the inability do basic financial calculations is that small a thing, but it's one of many issues I think JavaScript has, dates is another example of where it's weak. As I've mentioned, the lack of static typing (Typescript aside) and it's dynamic nature make it very easy to write code that's brittle.
"And then there are two separate change management and
deployment processes that need to be coordinated. And maintaining knowledge
in both languages."
Actually, on quite a few the projects I've been involved with recently we use Git even for our IBM i sources and I'm currently working to try to create a decent build chain using Jenkins and either BOB (
http://www.s4isystems.com/better-object-builder/) or a derivative of it to automate builds in a similar way to our front-end. I can't help wondering why IBM didn't just give us a version of BOB way back when ILE was introduced...but that's another story...
"If tasked with building an application from the ground up, what would your
language stack look like?"
That's a really good question, and I don't think we're as far as way as you think. The answer depends on what the starting point was. If I was looking at an IBM i application, especially if it was an extension or migration of an existing application I'd do what I've done already, that is implement the business logic in the language best suited to the platform and closest to the database (SQL and RPG in my case) because I think that's where many of the IBM i's strengths lie. It also means that the existing knowledge people have can be leveraged, there doesn't have to be a mass retraining and relearning exercise and you don't have the fatal combination of a team of inexperienced (in the new methods) developers writing a new application from the ground up using an unfamiliar programming paradigm. Having worked on similar Smalltalk project back in the day, I know from experience that this is doomed to failure.
For a web app that wasn't IBM i based but still had to talk to a relational database then I probably would use Typescript, simply because most other platforms don't have the integration between database and programming languages that the IBM i has, so there's not a readily available backend language to use - and I like Typescript 😊 I'd still strive to keep as much of the core business logic wrapped up in SQL stored procedures but I'd try to split the functionality out to where it's done best, e.g. financial calculations and record processing in SQL, token decryption etc. in Typesript.
If the web app were to use an object database like MongoDB then of course there would be no real choice but to implement everything in *script of some sort, but again, in both the latter cases it makes sense dealing with the Idiosyncrasies of *script because it's the obvious choice and bringing something else into your mix would most likely make your life harder not easier
To be clear, my criticism of backend *script is mostly in the context of the IBM i, which already has built into it languages that are specifically designed to efficiently express typical database orientated business functionality. It's an integrated platform and it doesn't make much sense to me to wrestle *script into submission to do something that can already be done much more eloquently with another language. Once you start talking about not taking advantage of the IBM i's integrated nature then I would question why you'd use it at all. If you want to develop NodeJs applications then there are probably plenty of other platforms that are cheaper and better suited to the task - containerisation using Docker, for example, springs to mind.
________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Aaron Bartell <aaronbartell@xxxxxxxxx>
Sent: 20 March 2018 12:40
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] [EXTERNAL] Re: Rise of Node
I'm not suggesting you can't write typical "business logic" in Javascript,
but I'm questioning the wisdom of it and your workarounds demonstrate why
IMO.
I agree the decimal math isn't optimal in Javascript, but it seems like
such a small thing compared to adopting an entirely other language to do
the business logic (i.e. RPG, Java). While there are tools to span the gap
(iToolkit), it is still a gap that needs to be crossed for each business
logic call. And then there are two separate change management and
deployment processes that need to be coordinated. And maintaining knowledge
in both languages.
Regardless of our different views on possibilities of where business logic
should be, I am curious of the following given that you have a decent
amount of experience in a variety of languages...
If tasked with building an application from the ground up, what would your
language stack look like?
Aaron Bartell
IBM i hosting, starting at $157/month. litmis.com/spaces
On Tue, Mar 20, 2018 at 4:33 AM, Tim Fathers <X700-IX2J@xxxxxxxxxxx> wrote:
I'm not suggesting you can't write typical "business logic" in Javascript,
but I'm questioning the wisdom of it and your workarounds demonstrate why
IMO. The solution below is like something from a 1980's Windows program
before preemptive multitasking was around you had to remember to yield to
the OS and I'm sure you don't need me to explain the potential drawbacks.
The fixed point function doesn't round properly, as far as I remember, the
only safe way to do fixed point maths is to shift the numbers to integers
first, either way, it's not as straightforward as you claim. Even if it
were, having to wrapper all of your basic maths operations in a function
call is error prone and ugly and simply clutters up the program with noise.
The benefits of using JS or even Typescript to express your business logic
over a language designed specifically for that purpose would have to be
significant to outweigh the disadvantages and in it's current state, I
don't think they are.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7C15cca215f9184070397908d58e5768e6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636571428425000686&sdata=Dhf%2FoRSlCaSn4VTNp7mqWYf4d6hOUrv5XvCBivGuDbk%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7C15cca215f9184070397908d58e5768e6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636571428425000686&sdata=YZ7UP3O4dXjs%2BY0PH4v9ZS%2FNNVuordpSPWC2Hhrwiek%3D&reserved=0.
midrange.com
