Slashdot Mirror
How Can an Old-School Coder Regain His Chops?
DonLab writes "I was a proficient software engineer in the 1980s, writing hundreds of thousands of lines of ALGOL, FORTRAN, COBOL, and Pascal programs, as well as working in 370 and 8080 assembly language & pre-relational DBMS systems. My hands-on programming career ended when I became a freelance analyst and designer, ultimately retiring young in the early '90s. Now I'd like to reenter the field, but I'm finding that I know nothing about today's post-C languages, programming tools, and computing environments. I wouldn't know where to start learning C++, PHP, Java, HTML5, or PERL, much less how to choose one over the other for a particular application. Can I be the only pre-GUI software designer or hobbyist searching for a way to update his skills for Windows, iOS, or Android?"
Pet project.
I agree. C# is very likely to become a powerful language in today's market, if it isn't so already (It isn't on my market, people just seem to love Visual Basic and PHP a lil' too much). That said, the new COBOL versions, as my father says, who's a guy who's been working with computers for over 30 years, have programming environments which are very close to what Java offers. Perhaps you should look into that area.
Oblivion Awaits
There are still plenty of FORTRAN shops out there, or at least legacy FORTRAN applications.
There is a ton of COBOL apps that need maintaining
If you are going to learn anything, it should be stuff that makes you more interesting as a FORTRAN and COBOL coder. For example, get comfortable making HTML/CSS pages. A lot of shops are trying to connect COBOL to the web and SOAP.
Find a web site or book to learn what relational databases are. Everything is relational these days. The NoSQL crowd think they're post-relational, but they still talk in the relational language.
That's the other thing you should learn: Oracle PL/SQL and Service Oriented Architecture (SOA). SOA these days means SOAP and message busses. At my place of work, we have a legacy COBOL application that needs to connect to the enterprise's Enterprise Service Bus (ESB). We are struggling to find anyone who can do it inside our company.
Your future is being the bridge between the past and the future. Learn how to make those old apps do new tricks, and you'll make lots of money.
Learn Perl. Because Perl is like the swiss-army knife for programmers. You may not write an application with it, but you might use it to make bulk changes to a hundred COBOL or FORTRAN source files.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Don't talk about you know nothing about. Wine is an effort to reverse engineer something that is ill documented, not a standard and huge moving target. It might never worked or work well in every scenario though.
Mono on the other hand is based on the standards which makes it much easier to implement, make it compatible and test. Not every API is ported though, but I can tell you from experience you can create well performing apps that run cross platform with Mono and .Net without a single source code changes (or binary for that matter). Even ASP.Net runs out the box.
If the submitter wishes to learn C# (and I think he should) I even go as far as suggesting he does it on Mono/Linux. Not because I think Linux is great but because it will help you understand the implications of cross platform development which in some little cases the .Net platform did a poor job although it's a primary objective of the whole framework.
Oh, and btw the .Net source code for the core APIs is kinda open source so you can read it too.
Typically the older coders grew up in a much more structured environment - we were expected to know the theories of programming much more than today's coders. Not a put down for anyone; times have changed.
The only place I know of for old coders with old skills is in embedded linux. It's much the same attitude - squeeze a lot of performance from a limited box. And GUI skills don't really matter.
So start with busybox. Tear it apart, put it together, submit some patches. You'll find you're not so rusty.
Then find an embedded project you want to work on and contribute. Forget about working for someone else; most companies these days don't want anyone over 35.
Set yourself up as a specialist consultant. Embedded systems, old systems, IBM stuff that's still out there. COBOL is still in demand and coders, good ones, are getting consulting jobs. Not permanent jobs, mind you, consulting jobs.
Do what you know and build on it.
Why update at all? There are still legacy systems using FORTRAN and probably COBOL as well. While there are C#, Java, PHP developers all over the place I imagine that finding a developer to maintain a legacy system is extremely hard. Of course that means there will not be many jobs out there for you but the pool of qualified applicants will be extremely small.
Plenty of money in COBOL but there is a need to suit up (physically and mentally) - not for everyone.
I have found a small but significant niche in embedded *nix programming. Small yet powerful systems requiring every scintilla of juice tempered with a familiar API - C Systems programming work is common enough (yet not common enough!). This is where I hope to spend the next while.
An "old school" approach to knowing the architecture inside-out and attention to detail is clouded by the bizarre abstractions of C# and Java. PHP isn't even an abstraction, it's a distraction (I grew tired of the inconsistency so no longer practise).
Perl is unfashionable in some circles and has a reputation for having magic constants (or whatever it is the detractors call "I don't want to learn this language") but I recommend it if you want dynamically typed "chops".
I find these "chops" are overrated. I enjoy low-level thinking so don't need to bloat up with virtual machines[1] (the real ones work fine for me), OO[2] (I know how to pass a pointer to my data to a lib) or design patterns[3] ("ways to do things" - if you learn one way as "the way" you may be unlikely to think there may be a better way)
[1] I use virtual machines but it's perverse running the dozens of MB JVM (and waiting around for it) for a browser bound animation or trivial desktop app. There may be a better case for this messing on the application server, but I don't care.
[2] OK, I will make an argument for OO in GUI programming - a large and complex library of heterogeneous components is difficult to arrange sensibly in a procedural manner. gtk_status_icon_set_from_file(foo_icon, "bar.png") or fooIcon.fileSet("bar.png")? There may be a similar argument to be made for other systems but for the most part I find the OO model a needless abstraction.
[3] Right... most programmers aren't brilliant - I know I'm fucking terrible for the most part - so having established methods for common situations is no bad thing... just don't get too attached.
I'm sorry to say, but you probably won't land a good job just by learning COBOL.
What's needed is experience with the whole systems the COBOL programs run on, which is much more of a challenge than the programming language itself. Someone hiring COBOL programmers likely expects people who live and breathe CICS and LPARs too.
As for the OP, I vehemently disagree with those who suggest languages like Java and C#. Not because they're bad, but because they're so completely different from what he already knows.
To go from FORTRAN to C# is like going from AutoCAD to Photoshop. Just so very very different.
If he wants to ease into what's popular today, perhaps start with Object Oriented COBOL. That would be a handful in itself, as it turns the whole concept upside down from what's "old school", but it would still not be as suicidal as jumping directly into any of the "new skool" languages.
And if he wants to learn (pseudo)scripting langauges, Python is probably the way to go. Not because it's a wonderful language, but because it is about as unforgiving as COBOL, yet small enough that you can keep it in your head and focus on the actual problem without going OO (although you can certainly do that in Python too -- you just don't have to).
FTFY: Java is still the most actively used programming language.
Cobol is still the most used programming language... and is still being used (and I have no idea how to program with it... I can barely stand looking at its record/data structures).
-- I ignore anonymous replies to my comments and postings.
This is a plea for anyone who thinks object-orientation won't do anything for them to stop and back away from that view for a second. Give me a minute to explain.
Read this great article called Why are you still using C?. I think it explains very well what OO can do for it.
Did you know that the Linux kernel, despite NOT using C++, is actually doing bonafide object-oriented programming?
Just one example is the Linux VFS. A filesystem passes in a struct with function pointers to read, write inodes, etc. The I/O kernel code only knows about each VFS in the generic terms, but ends up calling specific implementations via the function pointers. This is called polymorphism.
That's right, the Linux kernel is doing real, meaningful object-oriented programming. In contrast, if you put a few functions together under a class (like many people do that "have to" write OO), then you ain't doing jack shit worth of object oriented programming. However, because the kernel is using C, it has to do a lot of messy things with pointers. C++ helps take care of that mess (polymorphism is supported in the compiler), so you don't have to write it by hand.
Problem is, object-oriented programming is useful when it is applied on an as-needed basis.
Design patterns? Same thing. People got a design patterns boner when the book came out (I know I did). The academic/enterprise/fancypants software architect approach was: "What if? What if?! Why not use a pattern here, just in case you ever need to do it this other way?" So, you end up seeing patterns and flexibility and layers of abstraction (variations on a theme) built everywhere, where you end up not using them.
So you end up with a ton of code that never really does you any good. Worse, when you suddenly realize that you need some kind of flexibility, you already probably sliced the code the wrong way, so now it's actually *harder* to make things flexible. All because you made them flexible ahead before you knew what you actually needed.
There's a concept of emergent design, which basically says: don't come up with any frameworks, let frameworks emerge from the code. That is, if you find yourself needing to copy/paste the code or find yourself repeating something that's awful similar to this other thing, well, *now* -- only now is the time to use a technique to eliminate the duplication. Maybe you make a little framework. Maybe you just make a class or two to help you out. Maybe you use a bit of a larger design pattern, well, 'cause you don't need to use the whole thing. And that's great! You've taken care of the duplication, so now all the code you have has purpose, has a real need.
WE have been made to feel stupid, by all these academic and UML software architect wankers that are removed from real-world coding and proclaim the need for design patterns everywhere and "careful architecture" beforehand. Turns out that we weren't stupid, we were just being practical.