How Can an Old-School Coder Regain His Chops? 565
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?"
Easy (Score:5, Interesting)
Re:C-sharp (Score:4, Interesting)
Re:Work backward (Score:1, Interesting)
You don't have to use Objective-C to write iPhone applications, nor should you if portability is a concern.
FORTRAN and COBOL makes you money (Score:5, Interesting)
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 [computerweekly.com]
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 [infogoal.com].
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.
Re:C-sharp (Score:5, Interesting)
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.
Re:Don't (Score:1, Interesting)
It partly depends upon where you look if you go to the scientific side the core calculation software is likely still FORTRAN because the best optimizing compilers exist there.
Cobol support is in short supply because the bulk of cobol programmers are retiring. If you look at a bank you will notice that sooner or later a 3270 style screen appears
on the reps PC and some info has to be input there. A lot of the bank web interfaces are essentially screen scrapers of 3270 displays (may be more sophisticated than a
pure screen scraper but the core app runs on the mainframe, because the performance and reliability best on Z-OS (MVS). If you have some business experience go into analysis
because its harder to move those jobs offshore. Once upon a time the oil company I worked for wrote compilers and operating systems (early 1970s thru about 1980). Then these got
to sophisticated and the ROI was not there. Today if you want to to os programing there is MS, Oracle, and IBM, unless you want to do device drivers. 20 years ago there
were far more operating systems out there, DEC had 5 or 6 alone.
You have skills.... (Score:5, Interesting)
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.
Re:Work backward (Score:1, Interesting)
You do need to use it if you're planning to use UIKit though -- or good luck with the objc_* funtions. I wish there was a decent C API because the entire thing is a clusterfuck. I've christened the satanic mix of C, C++ and ObjC (required to develop even trivial cocoa apps for iOS), "WTF++".
It's an "exciting" new, composite language, mixing 3 runtime libraries and 4 types of memory management (excluding ObjC GC). On the positive side, at least Apple finally did something about the POS that was XCode.
Re:C-sharp (Score:1, Interesting)
It is based on standards. The old standards.
Every time Mono starts to get remotely up to date with the current API Microsoft release the new version.
Re:FORTRAN, COBOL etc. (Score:5, Interesting)
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.
Re:C-sharp (Score:3, Interesting)
I would recommend starting with C#, also. One big advantage is the excellent and free IDE available from Microsoft (C# Express). There are also some excellent books available, such as Programming Microsoft Windows with C#, by Petzold. Also, C# is similar in syntax and structure to Java and C++, so you can more easily transition to these languages, if needed.
Haven't tried C# express but I did use SharpDevelop [icsharpcode.net] in a previous gig when doing a little windows dev - it struck me as very polished.
I ended up doing what I needed with Win32 API calls and building with wxDev-C++ [sourceforge.net] but I don't like talking about it... (Because of Winsock2 rather than wxDev-C++.
Re:Stay Retired. (Score:3, Interesting)
and work under a clueless asshole boss.
Amen. I had an experience last week where someone, (who wasn't my boss, but is over me, and happens to be married to the sister of the CEO of the small corporation I work for), complained that on a web page I had worked on, that half the hyperlinks were purple and the other half were blue, chastising me for the inconsistency. (It wasn't just that one comment; he had four emails full of requirements, but that was the straw that broke the camels back).
I set a reminder to deal with it the next business day, when I could respond in a more professional manner.
Off-topic, I know, but I wanted to post an example of what OP may be getting into.
Re:Work backward (Score:1, Interesting)
Which is why I excluded it and totalled 4 instead of the 5 availiable to fully fledged WTF++ Cocoa apps on OSX.
Re:Don't (Score:4, Interesting)
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).
Re:C-sharp (Score:3, Interesting)
Take a look at GP's sig: 101 Reasons why Java is better than .NET [helpdesk-software.ws]
Of course, a large number of those are quite dated, but that's where he's coming from...
FTR, I don't agree with most of that: just an attempt to be fair
Re:C-sharp (Score:2, Interesting)
Unless you play trombone where there is a difference between C sharp and D flat.
Re:C-sharp (Score:2, Interesting)
On the typical chromatic scale most instruments use, no such thing as B#. B# only really exists in instruments where there are no fixed note intervals, like a trombone or fretless slide guitar.
Re:Work backward (Score:3, Interesting)
What if you are interested in Objective-C, but not in Apple EULAs? Is there a good choice (is that a good choice) in that case?
I'm rather interested in using Objective-C on Linux, but not enough to fight with the old tutorials I've been able to find. (I suppose I could learn Objective-C++, but I've heard less than friendly things about it.)
Last time I looked at it I looked long enough to determine that the Foundation libraries supported Unicode (mandatory!), and I think I remember utf8. But that was string libraries, and I couldn't see how that translated into I/O. I'd need seek and tell, etc. Which probably means read binary files in C, convert into buffers, tell the string libraries to cast them into a Unicode string, etc. But I couldn't find any could tutorials about this.
Documentation is a real hassle. Last time I looked at Vala it looked quite interesting, until I started trying to figure out how to do the things I knew I needed to do...and the answer appeared to be "Use standard C libraries, but we don't bother to document that, because you're supposed to already know that." This just doesn't work. I can handle Java (though I hate their I/O routines and a few other features), Python is easy, Ruby is easy, D is easy (though a pain when you're needing to link with C libraries that require complex structures to be passed and match). But C and C++ seem to be undocumented. You're supposed to "just know" it. But I don't. I understand that gobj is important, but I can't find where it's documented, so if your language just says "And for this you call gobj", then you lose me. I don't have a history of C/C++ in Linux, and my history in MSWind dates back to the 1980's. (Actually I've got more history on the Mac II than in MSWind.)
Fortunately, for me, Python comes "batteries included", so I can get around that. (And it's got GOOD documentation. So does D. So does Java. So does Ruby. But both Ruby and D require C libraries, and that gets me back into trouble.)
Objective-C is in even worse position. It's documentation for the native language (the part I've found) isn't all that great. AND it requires you to use C libraries with no obvious documentation. (Granted this depends on what you are doing, but I know what I'm doing.)
So, it appears (to me) that Objective-C is only a decent choice if you are intending to develop on Apple hardware. If I'm wrong, I'd certainly like to know.
Re:Work backward (Score:1, Interesting)
I develop the majority of my iPhone apps on linux, mostly I'm writing C. The ObjC stuff is kept to a minimum until I switch to OSX and import into XCode. The best ObjC tutorial I found was reading the GNUStep header files. The only other documentation I bothered with was the trivial stuff for GNUStep make.
If you want to know how something works in Vala, it's mostly documented. 3rd party libraries are documented _somewhere_, the bindings are self-documenting. Grep the .vapi and you have all the information you need to use the binding. Remember that Vala is not yet stable, some of the bindings are incomplete and the Posix profile is (currently) useless by itself.
If you're beginning to see the "self-documenting" pattern here, it's not limited to open source projects. I personally find Apples API documents useless, again I favor using their header files for reference.
C is a very simple language and a copy of "K&R" goes a long way. Very few people know C++. [cat-v.org]
I'm currently getting HTTP timeouts from library.gnome.org. There's a link to the documentation at the bottom of the GObject wikipedia article. [wikipedia.org] Vala transparently wraps GObject via the C API so you can also pass --save-temps and study the generated C code.
Re:C-sharp (Score:3, Interesting)
Figure out what you want to do, then learn the language appropriate for it. Want to code Windows, MSSQL, or whatever Windows calls their web server these days?? Might not hurt to learn C#. I do mostly back-end data loading/transformation/modeling work, and Java works just fine. It fits more in with my skill set, and there just aren't that many programmers that want to do such 'boring' work so I'm in high demand.
In fact, just about any language, including COBOL, would work fine for 90% of what I do. Some of the financial modeling requires recursive code and more advanced mathematical functions, such as standard deviation, and I don't think COBOL ever incorporated that. But I haven't done COBOL since '85, so don't quote me on that.
Re:C-sharp (Score:4, Interesting)
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).
Re:FORTRAN, COBOL etc. (Score:5, Interesting)
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? [renaissancesoftware.net]. 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.
objective-C/iOS is a good option (Score:2, Interesting)