4 ms·

I surprised banks don't have a domain-specific language (DSL) to describe their businesses. Instead each bank has to code "savings account" in COBOL.

• dan-robertson 3y ago
  What domain do you think COBOL was made for? Basically the only things computers were worth it for back then were scientific calculations and bookkeeping. Banking is obviously on the more complicated end of bookkeeping. Insurance did get a special COBOL variant because I guess they had some tasks shaped more like scientific calculations too.
• ravenstine 3y ago
  It's an interesting idea, but I'm not sure how that's the least bit surprising.
• skissane 3y ago
  > Instead each bank has to code "savings account" in COBOL At most banks nowadays, basic banking functions such as saving accounts are provided by off-the-shelf software, not written from scratch. That's not to say that nothing gets written from scratch, but it is generally adding code to support the more exotic product offerings, integrations with other systems, institution-specific business rules and processes, etc - any off the shelf banking system is going to have basic bread-and-butter stuff like support for savings accounts already included. This is true even for COBOL-based banking systems. Historically, many banks used CSC Hogan (now DXC Hogan)-and while many have moved away from it, some are still on it. Hogan runs on IBM mainframes (z/OS), and is written in COBOL and CICS. Basic stuff like savings accounts is supported by the vendor-provided COBOL code, but Hogan sites often end up writing their own custom COBOL code to support their own unique requirements. > I surprised banks don't have a domain-specific language (DSL) to describe their businesses. There is a long history of 4GL's being used in banking, going back decades. In prior decades, many of these 4GLs worked by generating COBOL code. Some of them were general-purpose, and used across many industries; others were exclusively used in banking. But, even those exclusively used in banking, rarely (to my knowledge) contained domain-specific banking features, and as such I'm not sure they really count as DSLs. To give a specific example, FIS Global's core banking platform, Profile, is written in MUMPS (actually the open-source variant GT.M). Due to how horrid MUMPS is as a language, they created their own higher-level object-oriented language which compiles to MUMPS, called PSL (Profile Scripting Language), and gradually rewrote their banking platform in it. An old version of PSL was open-sourced over 10 years ago on Sourceforge, if anyone wants to look at it. [0] I don't think PSL itself has anything really banking-specific in it per se, but as is inevitable with a language developed to support a single application, the boundary between the language and the application is a little blurry, and you'll find a lot of banking-specific stuff in the open source release (possibly included by accident), especially inside the binary GT.M database dump it ships with. I think the areas in which truly domain-specific languages are strongest in finance - such as modelling financial contracts - are generally the furthest away from the COBOL legacy. [0] https://sourceforge.net/projects/pip/files/PIP/V0.2/ https://sourceforge.net/projects/pip/files/PIP/V0.2/ see also more easily digestible (somewhat improved) Git mirror at https://gitlab.com/YottaDB/DBMS/YDBPIP/ https://gitlab.com/YottaDB/DBMS/YDBPIP/