6 ms·
I did an internship in 2009-2010 with a company who used MicroFocus “AcuCOBOL” to modernize a green-screen automotive dealership management system into a Window
by marpstar 3y ago
I did an internship in 2009-2010 with a company who used MicroFocus “AcuCOBOL” to modernize a green-screen automotive dealership management system into a Windows GUI.
I wouldn’t say I did it for fun, but I did do it for the learning experience. My university was very invested in COBOL, and I had classmates who got offers much larger than mine to work for various finance companies in Wisconsin, so I had already learned the basics of language.
It’s hard for me to separate the COBOL from all of the other dysfunctional things going on at the company. I knew that the language was a dead-end and did not want to get stuck with it. Not because I didn’t like the language, but because I was 21 and “Web 2.0” was in full swing and I knew I wanted to do something “cool”.
Migrating data files to new descriptors was always a stressful time. The equivalent of a database schema change, but you had to load the old files and rewrite in the new format largely manually.
The tooling we used felt dated, but worked well enough. Better than the tools we used in school.
I always used “Murach’s Structured COBOL” [1] as my primary reference. Carried that book just about everywhere during that time.
[1]: Murach's Structured COBOL https://a.co/d/hONfFT7 https://a.co/d/hONfFT7
- anyonecancode 3y ago> It’s hard for me to separate the COBOL from all of the other dysfunctional things going on at the company. I knew that the language was a dead-end and did not want to get stuck with it. Not because I didn’t like the language, but because I was 21 and “Web 2.0” was in full swing and I knew I wanted to do something “cool”. I think this is an often under-appreciated point -- languages don't live in isolation, but within a wider context of libraries, people using the language, and institutions and jobs with jobs that use the language. As another example on this point -- at my current job, for some reason much of the backend has been written in Haskell. Haskell's a fine language, I actually really like many aspects of it. Our main product, however, is web based, a domain Haskell is completely able to handle on a technical level. In practice, though, it's a poor fit, and I find myself constantly puzzling at all the odd, non-idiomatic ways web architecture has been set up, often in ways that make it very difficult to make things work well for the web. In many cases, this has been carried over into some questionable typescript as the backend programmers then had to also try and become frontend programmers. None of these problems are because of Haskell the language or because the original programmers were bad programmers, but because their background, and the majority of the Haskell ecosystem, just isn't really web-focused, and so conventions and assumptions most people who work mainly on the web take for granted they were unaware of or got wrong. A language is more than just syntax and standard library, it's part of a broader culture.
- salmo 3y agoI couldn’t agree with this more. To me, there’s an ecosystem and a culture for a language in a situation. The ecosystem is the tooling around the language. Debugging, performance profiling, building and dependency management are examples. The culture is how the language is used in real life. How stable is the ecosystem? There are lots of beautiful languages that are used horrifically. Enterprise OOP is an example for me where more than half the code is dedicated to avoiding basic principles for “what if we want to change later” (looking at you getters and setters). And within a company or software suite, there can be subcultures of how “we” use the language. Every class needs an interface. Our C is written OO (see old GNOME). For the ecosystem you have extremes. C where debugging and performance profiling are well defined practice, but modern dependency management doesn’t exit. The JavaScript ecosystem changes so rapidly, documentation is usually out of date, “nobody does that anymore”, etc. And so much awful comes from trying to force a language into something the language wasn’t originally designed or even used for. Your Haskell example here. Adding functional language features and convoluted asynch to every freaking language is another. People create things much harder to learn than a new language with a mature ecosystem and culture in a domain just to avoid “learning a new language.” In woodworking, I can do pretty much anything with a chisel. But I plane with a plane, saw with a saw, use specialty planes for rabbets, etc. Each has a learning curve, but I’ll end up with a better, more consistent result. And really, they’re all just chisels with jigs in different configurations. But I’m going to use a chisel where it’s still best, like mortising. Well, and where I’m not sure I want to invest in a more specialized tool yet and risk my wife killing me. Then I use C… I mean, a chisel.
- tomcam 3y agoIf you’ve written about this on a blog somewhere, I would love to hear the lowdown in detail as deep as you wanted to go.
- krger 3y ago>I did an internship in 2009-2020 At eleven years, that sounds more like an apprenticeship than an internship.
- marpstar 3y agoOops. 2010*
- tomcam 3y agoVery cool slice of life, thanks. I didn’t imagine in 2009 that even a single university would have been invested in COBOL.
- marpstar 3y agoIt felt weird at the time, but I think the reach of COBOL is underestimated by just about everyone. I just checked the university's website and they still have their introductory Programming in COBOL course as well as a 400-level "Applications in Information Systems" course that "includes coverage of advanced features of the COBOL language." Northwestern Mutual is based in Milwaukee and is where most of the grads I knew who went down the COBOL path either started out or ended up.