5 ms·
COBOL will always have a soft spot in my heart as the first programming language I learned. I did not use it much - 2 years max - but when reading COBOL it was
by aparsons 6y ago
COBOL will always have a soft spot in my heart as the first programming language I learned. I did not use it much - 2 years max - but when reading COBOL it was really clear that there were some programmers who just saw code differently - in an abstract, artistic sense. It was the ultimate litmus test.
COBOL is really easy to write spaghetti code with - perhaps even the default. But some of these programmers (not including myself back then admittedly) just wrote code that came together beautifully like a jigsaw puzzle. I’m sure if given a C++ or other language with modern features, they could do amazing things. This was before a time when Clean Code (capitalized on purpose) and such were in the zeitgeist. I didn’t appreciate the full beauty of these modular, generalized, programs until a decade or more later.
I also didn’t realize that Z systems natively ran Linux. Must have missed that news. I suspect they’ll open source this soon - makes a lot of sense, if only for keeping consistency with their C/C++ work on Z systems. They are a big contributor to L.L.V.M in that area.
- IainIreland 6y agoI worked on the IBM COBOL compiler in a past life. It's not LLVM based; the optimizer and code generator are derived from J9, the IBM JVM. I would be a bit surprised if they open-sourced it; OpenJ9 is open-sourced, but the COBOL compiler for Z is one of those rare compilers that is still being sold to paying customers.
- aparsons 6y agoThanks for the insight. I strongly suspect the COBOL compiler buyers are really just buying ongoing support and updates. Open sourcing should result in minimal revenue impact, but shared code might make it quite problematic license wise. Wouldn’t blame them for turning down that headache.
- CountHackulus 6y agoDid I work with you!? I also worked on the COBOL backend for TR. And yeah, I'd also be HIGHLY surprised if it ever got open-sourced.
- IainIreland 6y agoWe must have just missed each other. I started in January 2014.
- skissane 6y ago> I worked on the IBM COBOL compiler in a past life. It's not LLVM based; the optimizer and code generator are derived from J9, the IBM JVM. Does it have anything in common with XL C? Does it use W code as an intermediate language? And what language is it written in? (PL/X? PL.8? C/C++?)
- IainIreland 6y agoAssuming nothing's changed since I left, the front-end is taken from the old COBOL compiler, and is written in PL/X. It emits WCode for the backend, which is written in C++. XL C is a separate codebase, with very little shared code IIRC.
- ineedasername 6y agosome programmers who just saw code differently - in an abstract, artistic Yes, some people like this are absolute geniuses.... And also result in code that's incredibly difficult to maintain, especially when it wasn't well documented or documentation binders have been sitting in boxes at some off-site cold storage for 25 years. For anything that isn't pushing the boundaries of computing, I'd much prefer a few experts to a single genius. If you find yourself with a true genius, you need to realize that they are not replaceable and you cannot rely on them alone, doing their work as usual. To harness genius like that, you need to build a structured team around them, not try to fit them into an existing structure.
- ineedasername 6y ago^^ I understand my comment on genius could be seen in a negative light, e.g., genius-level intellects are problematic and perhaps undesired. I mean quite the opposite: 1) I prefer geniuses to be working in areas where they are pushing boundaries further. I don't think such talent is used wisely in service to finding novel solutions to mundane problems much faster than the average expert. Better to throw three experts at the problem instead. 2) However, sometimes a large organization finds itself with a true genius in the ranks. (It might just be the sort of work they enjoy, or the best job in their region and they don't want to relocate, or any other factor) The problem is that even well-organized large organizations are is highly structured and setup to organize the massively vast majority of people who are not geniuses. Yet a true genius is inherently an agent of chaos. They are a genius precisely (in part) because they see things beyond the current structures & paradigms, and realizing their potential requires them to either break or circumvent the current status quo. If you put such a person in an agile scrum and assign them stories, they will either 1) Quit out of boredom 2) Fuck off on their responsibilities out of boredom. 3) Complete their assigned tasks finding novel and interesting ways to solve (compared to their capacity) stupidly simple problems that will make future code maintenance a nightmare when a mere expert or newbie has to decipher it. 4) If #3, they may have their productivity recognized and be promoted into a PM/Manager type of role they will hate, at which point see #1 & #2. Under #2 & #3, if you're fortunate, they will spend their copious free time finding more interesting things to do that benefit the organization. If not, they'll be off pursuing their own curiosity. So, any organization should have some mechanism of recognizing these individuals (This is not something I have an easy solution for because, given #1 & #2 above, they can sometimes be indistinguishable from lazy/incompetent) However, if recognize, you need to set them to very challenging tasks suited to the direction of their genius: Build a team around them. At least one of those team members needs to be an expert. This is the person that will act as a buffer between the genius and everyone else. The expert will also coordinate with the rest of the team to determine the practical/logistics involved in making use of the output of the genius. They will systematize the chaotic creative forces at work. They will document, they will disseminate to the rest of the organization, they will ensure that the incredible value of the genius's work isn't lost if/when the genius moves on, retires, or whatever. How do I know this? I've seen one or two geniuses myself. I have even experienced this dynamic first hand. Let me be clear though: I am absolutely not a genius on that level. I am very much a generalist with a few areas that extend close to expertise. I have, however, found myself working in organizations that are so far behind what is possible that even very basic things have had people label me a "genius", which is very embarrassing because I'm not. And what I've done-- to use an artistic metaphor-- is kindergarten finger painting, Yet presented to a crowd that's never seen art, I am praised as a Picasso. Seriously: Pulling down 5 years of data, pre-processing in python (my preference) and running some basic regressions in R to show that a current very time-consuming process was useless was thought to be revolutionary. As a result, I've been through #1, #2, #3, and I'm currently resisting #4. When in #3, which is most of the time, I try to document as much as possible and make sure anyone who would be responsible for my work if I left is fully in the loop on what I'm doing. And I get to spend about 10% of my time on things I find truly interesting that push my own limits. But I like working for organizations that are behind the times, if they are flexible to accept change. I like it precisely because while I am not a genius, I am pretty good, and working with such organizations still allows me to make an outsized impact on them for the good.
- n3rd 6y ago35% of the total installed capacity world wide today is Linux on Z and is growing at double digit rates each year. RHEL, SLES, Ubuntu and most recently CoreOS (with OpenShift) all run beautifully. Ultimately, it's just hardware and it's what people do on it that matters.
- ASalazarMX 6y agoI worked full time maintaining a huge COBOL system in the 90s. Seeing how a massive code base could be elegantly structured around COBOL gave me a new respect for the language, and the original developers. I always felt a warm sense of pride every time I managed to improve upon their work. It's not so much that languages are good or bad, it's developers that are. COBOL can be made elegant, Swift can be made ugly. Even driftwood can be made beautiful.