by John Browne, on Jul 6, 2022 5:23:37 PM
In the last 12 hours two blasts from the past showed up in my feed.
First, this excellent github readme which is a super-simple explainer of what exactly assembly language is. User jessicard does an outstanding job covering basics like registers, the stack, instruction sets, hex and binary, and Boolean operators.
Back in the 80s at Microsoft, I was part of the Languages Business Unit and one of our products was the Microsoft Macro Assembler which was, naturally, for X86 Assembly.*
It really wasn't until the 90s that most commercial application software stopped being written in Assembly and had switched to C, and later C++. From the dawn of the Commodore 64, Apple II, Radio Shack TRS-80 through the introduction of the IBM PC, if you wrote code for microprocessors, you probably used Assembly.**
For a real treat, be sure to download and look at the code for MS-DOS 1.25 and 2.0, now on github. If you read the tutorial from jessicard, you will be able to kind of sort of understand some of it. It is, of course, all X86 Assembly. Check out this "heavily commented" segment from COMMAND.ASM:
What's the point of learning Assembly, or "asm" as it is sometimes called? I can think of a couple of reasons.
As an intellectual exercise, it's delightful. Asm is the most basic programming language imaginable, requiring one to consider each atomic step of solving any problem. To add two numbers, what do you do? In a high-level language, you simply use an operator like +. In asm, you first shove your two numbers into tiny storage locations inside the processor (registers), then call an "add" instruction that works on the data in the registers.
But there's also a practical reason for learning Assembly. To understand Assembly language is to grasp the inner workings of your computing device, whether a laptop or smart phone. When writing code in a high-level language like C# or Javascript, it's helpful (to me anyway) to think about what is going on deep in the machine.
It's easy to write a line of code like
string foo = "This is a string";
And not think about it again. But deep in the machine a number of discrete tasks have to be carried out to execute that line of code, including allocating memory, converting the characters into ASCII or Unicode values, storing those values in the allocated memory, and keeping track of where all that stuff is. (To create that string in asm, you'd have to do each of those steps yourself; this is why we write programs in C# and not asm.)*** I don't know, but understanding how all this works helps me when I'm coding or debugging. Maybe it will for you, too.
COBOL redux
Shira Ovide is one of the smartest tech pundits around. Her "On Tech" email from the NY Times never fails to bring something both interesting and well-written to my inbox. So imagine my delight today when her column about COBOL showed up. "The Latin of Software Code is Thriving" highlights a recent college grad who is entertaining multiple job offers because of her knowledge of...
wait for it...
COBOL.****
Shocked? Surprised? COBOL? Not Rust, or R, or Vue, or Python, or some hot in-demand programming language?
Nope, it's COBOL. And if you think it's because everyone is desperate to hire CS grads, check out this poor graduate who sent 100 applications out only to get one interview and no offer. And based on my purely qualitative analysis of the current market, his/her experience was more typical than our COBOL student.
Shira makes a good argument for why this is a brilliant career move. COBOL is old and creaky but it runs an enormous amount of the current economy. Back in the 60s and 70s if you were a programmer in a bank, insurance company, hospital, government agency, or other large, complex organization you were probably coding either in COBOL for business applications or FORTRAN for scientific and engineering problems. Those engineers were overwhelmingly white, male, chain-smokers with buzz cuts. They wore short-sleeve white dress shirts, clip on ties, cheap wrist watches and drank coffee by the gallon.
Imagine all the characters in Flight Control from the movie The Right Stuff.
Who are all dead or retired now. So who's maintaining all that COBOL? Because maintained it must be. And unlike it's original creators, it has no fixed life expectancy--it could still be chugging away when the Sun goes supernova.
Creation is the dream; maintenance is the reality
I'm not sure but my guess is this: computer science graduates are horribly misled.
They're taught how to write code; how to design systems; how to integrate and optimize the latest frameworks and patterns. Their shiny eager faces accept diplomas and immediately apply for jobs where they expect to use all that great training.
Instead, what I bet 90+ percent of actual programmers and software engineers do on a day to day basis is maintain someone else's code. Code that could be a month old or 20 years old. Code that works, but is an undecipherable tangle of linguini. Code with comments like "I wouldn't touch this if I were you" and "This function works but I don't know why." The real skills CS students need is how to read bad code, how to understand full systems with no single design structure, and how to make incremental changes without breaking the whole thing.
When you're in school, maybe a terminal project is to create an app with a web front end and a big data backend with some ML added like pepper flakes on a pizza. You work a whole semester on this bad boi.
Get an A. Be proud. Show Mom and Pop.
Now you get hired by Bank of Wherever and they've got a VB6 program to do marketing direct mail campaigns that is 20 years old, has over 25000 programmer-hours invested, and is 3 million lines of code. 200 screens and 16 different database connections. It's a kludged glue-up of 4 different applications brought in-house as a result of acquisitions. Falls under FICA regs. And there's no documentation; comments are whacked; and the lead programmer just turned in her retirement notice.
Welcome to the real world.
Mobilize.Net is dedicated to the proposition that migrating large, complex legacy code bases is a low-risk, time-saving approach to bringing old code into the modern era. To learn more, surf this very website.
* To be clear, "Assembly" refers to the language while "assembler" is the actual internal system that converts Assembly language to machine code that the processor understands. Assembly language is one small step removed from pure numbers.
** Not to diminish the role of BASIC here (after all, it was a BASIC interpreter for the Altair in 1975 that was the beginning of Microsoft). But serious applications and system software (compilers, operating systems, networking stack) were 100% Assembly.
*** I was lucky enough to work with some of the smartest people on the planet--the engineers who wrote the C compiler for Microsoft. They could read the output of the compiler--Assembly of course--like I read a cheap novel to find bugs and create optimizations. You won't find people of that ability very often anymore.
**** The last time I said anything about COBOL publicly I was hounded by a rabid Twitter mob. Can't wait for this one. I guess everybody has to feel strongly about something.
