I was reading about how people were having trouble finding people to work with COBOL when working government systems that still use it. I was also reading about how Fortran, a language made two years before COBOL, is interoperable with C, C++, R, and Python with the right libraries.
This allows Fortran scripts to work with modern programming languages to some degree and even create scripts in modern programming languages that can work alongside Fortran code, making it easier for novices of Fortran to work with it. Are there any particular issues that prevent COBOL from having similar interoperability with other programming languages like SQL (which is used for databases similar to COBOL) that would make it easier for modern programmers who might not normally learn COBOL to work with it?
Q1: Does anything prevents interoperability between modern languages and COBOL?
A1: Short answer similar to those above: No, it is actually often done.
But that may depends on what "modern language" is defined for the reader.
Even with "real" COBOL (not some "shiny" [may be read as "blending"] "managed COBOL") you are in most cases free to directly call any C functions so more or less can call anything (at least with a C wrapper) and also can call binaries as you can do on the operating system (`CALL 'SYSTEM' USING 'some-executabe-or-script "param1" "param2"' is a common extension).
For calling into any "native code" directly (like Win32 or POSIX) you obviously have to ensure you are using the correct parameter definitions, but COBOL 2002+ have stuff like USAGE SIGNED-LONG, USAGE POINTER and similar (the extension USAGE COMP-5 is also common in this place).
Additional there are often direct ways to inter-operate with socket servers, HTTP(S), XML, JSON, ... ; and many COBOL implementations also allow to ASSIGN a (line-)sequential file to a pipe, allowing to interact with other programs in this way, too.
Q2: Are there any particular issues that prevent COBOL from having [...] interoperability with [...] SQL?
A2: No, and SQL is a very common directly used in COBOL: EXEC SQL
Many people will say that SQL is no "programming language". It is a query language and may be used in different environments, including COBOL.
Depending on the environment used, EXEC SQL may be directly integrated into the COBOL environment or with a pre-parser that adjusts the code to be plain COBOL (normally CALLing some "native" code, see Q1).
Q3: [... stuff] that would make it easier for modern programmers who might not normally learn COBOL to work with it?
... this is a completely different question, whatever a "modern programmer" is.
For a programmer to get to know a programming language it all depends on the programmer and the resources (like time, manuals, tutorials, mentors) - and the will of the programmer. Many people actually don't "want" to learn COBOL (for reasons I've heard but don't understand or disagree), other miss some of the resources (a free compiler is available with GnuCOBOL, nearly all COBOL compiler have their manuals available online and the ISO working group for COBOL publish the draft standards online, too; you often can find mentors in COBOL discussion forums or mailing lists, along with many samples).
One thing that often is special with COBOL is not the language itself, but the environment it is used on ("mainframe" with job control language "jcl" instead of a GUI to click or a shell to use) and/or the software that is actually coded in COBOL; every software that is maintained over decades has "special ways" here and there, and if you get to "decade old code that wasn't actually maintained for years" you get into even more troubles/fun (this is not something COBOL specific, but with COBOL you may encounter this software more often).
No, there is nothing preventing interoperability.
The main reason (this is an opinion, not based on known facts) that Fortran seems to have more interop out-of-the-box was that there was a free software GNU/Fortran for interested parties to work with. COBOL was very late in the game getting a viable free software compiler. That is no longer an issue with GnuCOBOL and people are finally starting to write the code needed to catch up.
Adding to Simon's answer; proof of concept for direct embedding is in a branch for GnuCOBOL; intrinsic functions added to support FUNCTION TCL, FUNCTION PYTHON, FUNCTION REXX, FUNCION LUA and FUNCTION JVM, so far. With FUNCTION JVM tests for Scala, Groovy, Java, Frink, all worked. This allows data transfer between COBOL working storage and the other language engine using simple COBOL syntax. Including setups for callbacks to and from. Those functions are embedded into the compiler and libcob run-time, when using that branch.
For other interface trials, not built into the compiler, but still allowing interop; the GnuCOBOL FAQ has dozens of examples. Shakespeare? Yep. Falcon? Yep. C, well, GnuCOBOL emits intermediate C so that's covered in spades. There is also a C++ edition of the compiler, so C++ is also covered, in spades. Javascript; Jsish, Duktape, Spidermonkey, Quickjs to name a few of the trials.
Ada, D, Vala, Genie, S-Lang, ROOT/CINT, J, Gambas, Forth, Perl, Postscript, Pure, Icon and Unicon, Nim, BaCon, SWIG (which opens up many multiples), PARI/GP, Gretl, R, Red, Ruby, Haxe/Neko, Pascal, Erlang, Elixir, SQLite, Rust, Go, more..., including a fair number of esolangs, and GNU Lightning for on the fly assembly modules. Trials documented in the GnuCOBOL FAQ.
Framework interfacing for AWT/Swing, GTK, Agar, and things like ZeroMQ, CGI and websockets also proved successful and are in productive use. Along with at least 7 EXEC SQL preprocessors successfully tested, and in use.
It comes down to someone caring to try, and writing some glue or properly aligning call frames. No attempts I've tried have failed to produce satisfactory results, although Perl 5 was a hair pull of unraveling macro layers. (Ok, I just lied, while attempting to embed jq, which relies on using C call and return by struct features, I would have had to leave pure COBOL interface coding, and didn't bother with the C middleware that would have made it easy). ;-) Will do that someday though, as jq is quite the powerful little JSON handler.
Use the search engine you mistrust the least and look for "gnu-cobol-builtin-script" and "GnuCOBOL FAQ", and visit the hits on SourceForge.
In my particular explorations I usually focus on languages with a C Application Binary Interface, but other ABIs would be along a similar vein. It only takes sitting down and writing some middleware or figuring out how to properly synch the call frames.
Are these current samples perfect? Not always, there are edge and corner cases with some datatypes and COBOL PICTURE data that would require more work, but that is all; a little bit of work and testing to smooth over the bumps. When exploring, I don't always go that far until an actual need arises. These seed work experiments are just to get some proof in the pudding, all done for the simple joy of it.
One of the lead developers for GnuCOBOL just added uni and bi-directional piping using simple filenames, which provides access to whatever the base OS offers, using basic COBOL OPEN/READ/WRITE/CLOSE (and other file IO) statements. Code was committed to trunk just a few hours before I started typing this response.
Basically, the answer to the titular question is a resounding No.
The scenario involved in the governmental systems is most likely IBM mainframe hardware with a flavor of z/OS, z/VSE, or z/VM operating system.
It somewhat depends on what is meant by interoperability in the sense that most any modern mainframe supports TCP/IP and that pretty much opens up the whole networked computing ecosystem to networked interoperability.
My guess is when all is said and done, the reason there is a problem is that the state refuses to pay a market rate for experienced mainframe developers and has kicked the maintenance can down the road as cost-saving measures.
It most likely is not a matter of there being no mainframe COBOL professionals able to make the systems work; it's most likely the state won't pay the price.
But this is speculation on my part since all I know is that the governor blames inanimate objects for appropriations and management failures within the state IT administration.
As a 40-year mainframe veteran, I'm dying to know details as to how this perfectly good technology is at fault for problems dealing with (again, I assume) unprecedented volumes of processing demand.
We found an interoperability problem between C and GnuCOBOL.
Our problem was addressed so this answer is just for educational purposes so you can understand what kind of problems you may have.
The problem manifests when C calls COBOL(a, b) calls C(c) calls COBOL(a, b).
And specifically when the number of arguments varies.
A recent change to GnuCOBOL assumed that COBOL called COBOL so it passed meta data about the arguments in some global area. Then the called COBOL program cleared out the second argument because is falsely thought it was being called with one argument. That is, the intermediate C call was transparent to COBOL.
This is under the guise of making it more compatible with IBM mainframe but it caused me a lot of grief. It was quick addressed with runtime changes. I would like to see it addressed with a compile time option:
Make .so file a stand alone .so file called from any language but programmer has to be vigilant.
Make .so file assume it will be called from COBOL and has the additional protections afforded by mainframe COBOL.
BTW: GnuCOBOL is great and has a great community behind it. If you are experiencing problems report it and you will get better response than commercial products.
EDIT:
I found that doxygen can generate call graphs for classes, but I could not find any options or examples where the call(er) graph is generated for public/private members of the class(es) such as fields, methods, etc.? See the example that I provided below.
Is it possible to find links/relationships between 2 variables/objects in the code using some IDE tools and code editors, i.e. in Visual Studio, Sublime, etc.
e.g.
a=func(b,c);
w=func(a,c);
Here w and b are indirectly related to each other.
In convoluted code it is very difficult to manually find such relationships.
I understand that reflection and dynamic nature of some languages can limit such analysis.
You need to provide the language you are looking to use. If I take a guess and say C/C++ you can use CCTree and Cscope in general for this functionality. Most open source developers use Cscope extensively for this purpose.
Eclipse CDT also has call graph's. It is a bit of a pain to work outside of VisualStudio for this purpose I know. But cost is part of the reason to use open source instead.
Your best bet to cover all languages for the purpose of browsing is Exuberant Ctags. This works with a fair amount of editors and all the languages you listed. With that large a list of languages and use cases its probably worth your time to learn either vim or emacs and the integrations supported here.
For Python you can also take a look at pyscope with cscope. Another excellent alternative for Python is Rope. Rope supports finding definitions and usages as part of its standard set of tools.
Most developers do not need CCTree as browsing code bases with cscope is relatively straightforward. I have used exuberant ctags + emacs on a huge variety of language for years. It takes a touch of time to learn, but the upsides are
it's free, portable, and powerful. Another alternative to CCTree is codegraph for some of your target languages.
Found a list of tools and comparison:
https://github.com/OpenGrok/OpenGrok/wiki/Comparison-with-Similar-Tools
EDIT
possible in doxygen, but only for classes and their relationships
I found it, this is code map in VS Ultimate:
http://blogs.msdn.com/b/visualstudioalm/archive/2014/11/12/announcing-visual-studio-2015-preview-availability.aspx
My team is currently creating an API that will interact with our core Ruby API.
The new API is for the public as the Ruby API is our private API. We want to be able to compile this new API into a PHP, Java, Python, etc., client libraries when we are ready to release.
Are there any gems, or other ways to write this new API so we can compile it into different client libraries?
There are several ways to think about exposing an API these days. If we're talking about creating a library in the sense of something compiled into other applications, that takes us down one path. If we're talking about providing, effectively, command line functionality callable from other contexts as system calls, that's another story. More broadly is the API is more of a service, like REST, that's different. I'll assume one of the first two.
There are several tools that will create a binary package for platforms. Look at ruby-tioolbox.com for some examples. None of these are compiling true executable code (as far as I know) but mainly provide an executable version of ruby with your code and dependencies packaged up. Perhaps the API appears callable as a system library (DLL for Windows, SO for UNIXy).
But either way, I would think you're dealing with ruby and your code loading and running as a separate process on each call. There's a library like this (not in Ruby) called ImageMagick, with a wrapper for ruby calls called MiniMagick that might be a pointer to the kind of pattern you're looking for.
If you want to run ruby and your app as a service, there are several tools for this -- this helps address the overhead of loading a process each time, and built into Ruby 1.9 is a Process class that daemonizes ruby, although presumably only on Unix. Check this SO answer
The best answer is probably that ruby, like other similar languages (e.g. Python) are really not designed to be low-level system libraries. There are likely many ways of accomplishing what you want in a given environment (notably Linux) ... but as far as I know nothing that really exposes executable codepoints to all languages.
Soon I will be coding the file patcher for my application (check if the files are up-to-date and download newest if not) so its not much to code.
The problem is that I don't want the application users to be forced to use additional libraries like .NET (even though I like to code in vb.net or C#). I keep in mind that the .NET framework is installing together with the Windows but still there are plenty people who somehow doesn't have this framework installed, and thats why I'm looking for the programming language that wont require an additional libraries to run the application.
I haven't got much knowledge about programming in C++/Java but I have some experience with the AutoIT, vb.net, C#.
So the question is, what programming language will be the best for this purpose?
This answer is for "what language is available on any version of Windows without additional requirements". There are many other options for "what I can use to create application that can be xcopy deployed on any version of Windows".
JavaScript is probably your best bet - it is supported on most recent versions of Windows (according to Wikipedia article - Windows Script Host JavaScript available for scripting starting with Windows 98). Allows basic operation with files and HTTP communication - maybe enough for simple patching application.
Next would be native Win32 application, but lack of C++ experience will make it hard.
Freepascal, D and Go — to name a few — are much easier to program than C++ and could be told to produce statically-compiled binaries (not dependent on anything but certain system DLLs).
I, personally, would use the latter as it has all the necessary tools (including HTTP and binary I/O) in its standard library and is super-easy to get started with.
On Windows there a few libraries that allow you to intercept calls to DLLs:
http://www.codeproject.com/kb/system/hooksys.aspx
Is it possible to do this on Mac OS? If so, how is it done?
The answer depends on whether you want to do this in your own application or systemwide. In your own application, it's pretty easy; the dynamic linker provides features such as DYLD_INSERT_LIBRARIES. If you're doing this for debugging/instrumentation purposes, also check out DTrace.
You can replace Objective-C method implementations with method swizzling, e.g. JRSwizzle or Apple's method_exchangeImplementations (10.5+).
If you want to modify library behavior systemwide, you're going to need to load into other processes' address spaces.
Two loading mechanisms originally designed for other purposes (input managers and scripting additions) are commonly abused for this purpose, but I wouldn't really recommend them.
mach_inject/mach_override are an open-source set of libraries for loading code and replacing function implementations, respectively; however, you're responsible for writing your own application which uses the libraries. (Also, take a look at this answer; you need special permissions to inject code into other processes.)
Please keep in mind that application patching/code injection for non-debugging purposes is strongly discouraged by Apple and some Mac users (and developers) are extremely critical of the practice. Much of this criticism is poorly informed, but there have been a number of legitimately poorly written "plug-ins" (particularly those which patch Safari) that have been implicated in application crashes and problems. Code defensively.
(Disclaimer: I am the author of a (free) APE module and an application which uses mach_inject.)