|
"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 (
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.s4isystems.com%2Fbetter-object-builder%2F&data=02%7C01%7C%7C9a9fad3828de47512ee708d58e635609%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636571479648889563&sdata=%2Bngb9XZ%2FuzLIuTmVbsVM%2FP%2BwqPmRgKnllcGg4VLsHKk%3D&reserved=0) 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" inJavascript,
but I'm questioning the wisdom of it and your workarounds demonstrate whythe
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,
only safe way to do fixed point maths is to shift the numbers to integersnoise.
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
The benefits of using JS or even Typescript to express your businesslogic
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%7C84df9e7fe9f640afb435aaaaaaaa
aaaa%7C1%7C0%7C636571428425000686&sdata=YZ7UP3O4dXjs%2BY0PH4v9ZS%
2FNNVuordpSPWC2Hhrwiek%3D&reserved=0.
--
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%7C9a9fad3828de47512ee708d58e635609%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636571479648889563&sdata=cXGxo0gvwDEnl6CNnoA%2FictdmM1P41sCm4F3C6M7BkY%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%7C9a9fad3828de47512ee708d58e635609%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636571479648889563&sdata=5%2Fgdj2CySO0R6C0Ewjp%2F8Ecgyeo%2Bhn3SnCVCssNWlDA%3D&reserved=0.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
