Beep boop - this is a robot. A new show has been posted to TWiT…
What are your thoughts about today’s show? We’d love to hear from you!
I enjoyed the show last night. 3 people is nice. When I watch live I have a hard time remembering things I wanted to say. There was a moment where Richard really showed his age but I don’t remember what it was. I wanted to make a comment about it. Had to be there, I suppose.
1 Like
Probably the bit around COBOL.
I learnt COBOL at college in the 80s and I programmed it for a living for about 4 years, it is actually a lovely language. It is elegant, the blocks of code can have wonderful symmetry and the code is easy to look through.
@Leo said it was a “batch” language, that isn’t true. A lot of processing at that time was done in batches, so every language was in essence a batch language. But we used it for our finance system and a personnel system that we sold. I was updating our finance system in 1989 in readiness for the Y2K and in the early 2000s I was working for a client that had a manufacturing system (forerunner of modern ERP systems) written in COBOL. The code was complex and it had a front end written in COBOL, one language was used for the whole system, it wasn’t C or something for the UI and COBOL for batch processing and reports, it was COBOL for everything.
The company I work for today, I am the IT manager and the COBOL ERP system was replaced by a JAVA based system about 5 years ago. The JAVA system is an absolute dogs dinner. We had 100 users on the COBOL system, the ERP system and 100 users worked on one Windows Server with 4 cores and 32GB RAM, the JAVA system that replaced it is much slower (the old system would display a delivery note in around 1 second, the new “better” system takes around 10 seconds), but is using a dedicated SQL Server, an Application server and 3 terminal servers to provide a worse experience than the old system.
COBOL isn’t perfect and there are much better languages today, but it also isn’t a bad language and it is generally more efficient than, say JAVA or applications that use Electron, for example.
COBOL is a delightful language and easy to maintain, if you are trained in it, but it should be retired, because all the people who were passionate about it are retired or coming up for retirement.
1 Like
I also was required to learn COBOL in university, and I didn’t mind it. In fact I got an A+ and then in subsequent years marked for the course. (Marking for COBOL is a slog because the language is quite wordy, and thus every assignment is quite a lot of paper, and thus marking 200 assignments is like carrying 3 large textbooks!)
I have to disagree about Java being slow. I write plenty of fast Java, so fast some times it shocks me. (Especially during the Advent of Code, where my Java solutions are faster than some of the Python ones.) What I think you’re seeing in the slowness you’re experiencing is bad configuration, bad design or lazy devs, or more probably, some combination of all three.
If you compared like for like and the implementation time of each, probably a lot less time was put into the Java implementation because they used a bunch of existing framework code. Considering the the capabilities of your old COBOL code, it was probably not easy to evolve, whereas, at least in theory, it’s likely your Java code is very easy to evolve, (but it’s because the devs used a bunch of frameworks and whatnot.) The average dev on your Java code probably doesn’t understand good design–in some sense they’re just not as skilled as those old COBOL devs, simply because they don’t have to be. (Because no one demands it as well as because all the framework code hides the details and extracts away any low level knowledge the would need.)
1 Like
I think part of the problem is, they wrote the COBOL code themselves. When they tried switching to a more modern platform, they licensed another (general) ERP system written in JAVA and then started to customise it to fit the industry their customers work in.
But the whole system runs, with 100 users in 32GB RAM, whereas the JAVA system requires 4GB per user, plus 64GB for the SQL Server, plus 64GB for the application server and from 4 cores to around 30 cores. In total the new ERP system, plus the terminal servers, consume around 500GB RAM.
32 bytes?!?! That HAS to be a typo? 
32GB even so, 1 server, with 32GB RAM not being stressed to 5 servers with combined over 500GB RAM and 10 times the cores used and still running slowly, it isn’t as much of an advance as they hoped…
BOOM 
Me also
1 Like