Slosh
… is not a word that you’ve likely encountered too often. It happens to be an alias for the ubiquitous backslash.
\
Now as a programmer, I’ve come to react to certain ASCII characters instinctively:
| # |
“Smells like a comment” |
| / |
“Looks like a path component delimiter” |
| . |
“Wants to be in a namespace” |
| \ |
“Careful … things aren’t as they seem” |
That last one is special … it transcends ordinary meaning. That’s because its scope extends beyond just itself … to what follows it. And that, with little argument, is generally accepted the world-over. The backslash character is the universal escape character. Why then, is it so difficult for Microsoft to get in line?
Larry Osterman sums up the origins of the gross misuse of the backslash character:
Many of the DOS utilities (except for command.com) were written by IBM, and they used the "/" character as the "switch" character for their utilities (the "switch" character is the character that’s used to distinguish command line switches – on *nix, it’s the "-" character, on most DEC operating systems (including VMS, the DECSystem-20 and DECSystem-10), it’s the "/" character" (note: I’m grey on whether the "/" character came from IBM or from Microsoft – several of the original MS-DOS developers were old-hand DEC-20 developers, so it’s possible that they carried it forward from their DEC background).
The fact that the "/" character conflicted with the path character of another relatively popular operating system wasn’t particularly relevant to the original developers – after all, DOS didn’t support directories, just files in a single root directory.
Then along came DOS 2.0. DOS 2.0 was tied to the PC/XT, whose major feature was a 10M hard disk. IBM asked the Microsoft to add support for hard disks, and the MS-DOS developers took this as an opportunity to add support for modern file APIs – they added a whole series of handle based APIs to the system (DOS 1.0 relied on an application controlled structure called an FCB). They also had to add support for hierarchical paths.
Now historically there have been a number of different mechanisms for providing hierarchical paths. The DecSystem-20, for example represented directories as: "<volume>:"<"<Directory>[.<Subdirectory>">"FileName.Extension[,Version]" ("PS:<SYSTEM>MONITR.EXE,4"). VMS used a similar naming scheme, but instead of < and > characters it used [ and ] (and VMS used ";" to differentiate between versions of files). *nix defines hierarchical paths with a simple hierarchy rooted at "/" – in *nix’s naming hierarchy, there’s no way of differentiating between files and directories, etc (this isn’t bad, btw, it just is).
For MS-DOS 2.0, the designers of DOS chose a hybrid version – they already had support for drive letters from DOS 1.0, so they needed to continue using that. And they chose to use the *nix style method of specifying a hierarchy – instead of calling the directory out in the filename (like VMS and the DEC-20), they simply made the directory and filename indistinguishable parts of the path.
But there was a problem. They couldn’t use the *nix form of path separator of "/", because the "/" was being used for the switch character.
So what were they to do? They could have used the "." character like the DEC machines, but the "." character was being used to differentiate between file and extension. So they chose the next best thing – the "\" character, which was visually similar to the "/" character.
And that’s how the "\" character was chosen.
Everywhere else we instinctively know that a backslash escapes things … everywhere … except for Windows/DOS path names.
In defence of Windows, the OS is perfectly happy to interpret slash (“/”) as it would slosh … and for the most part application software observes this. There are occasional heretical instances where this is not true though and the application software writer has (<<shudder>>), deliberately chosen the backslash as a categorisation delimiter.
So, today I battled through an instance of this, trying to call sqlcmd.exe from within a Bash script. Now I realise that this is largely a function of the implementation (which was re-expanding parameters multiple times before they were eventually passed to sqlcmd.exe), but oh how this would so have been a non-issue if someone, somewhere had simply respected the good ‘ol escape character and left it to only ever escape and nothing more.
What was needed in the invocation of my Bash script:
… to eventually get into the form that sqlcmd.exe desires:
What a wonderful place the world would be if we could all agree on one thing: slosh is for escaping … nothing more, nothing less.
The Skill to Learn
I’ve been working now for some fifteen years, and I think that for someone who’s had a bit of experience, they can honestly look back and draw some valuable conclusions on “what’s important”. By implication, there are also a whole bunch of things that are not important.
Today, sitting with a prospective hire, I was asked what I thought of courses. I interpreted it is a question about the value of courses, in general. That’s a tough one. Any academic endeavour, ultimately, is only worth it’s level of recognition, presumably by a body or group of bodies whose opinion one values. The only truly worthwhile “course”, in my opinion, is one that you get through a reputable university. Ultimately, it then boils down to what is meant by “reputable”.
In IT, there will always be a market for courses. At first this statement seems obvious—after all, isn’t the way one learns how to administer an instance of Microsoft Exchange, or SharePoint, or Microsoft CRM is through a course? Is this the only way? If you’re a corporate charged with maintaining a level of skill within the org, it sure seems like the only way … it sure is the most expedient (at least at first glance).
The course-peddlers know this, and they exploit it. Corporates are easily wooed by the promise of the training silver bullet. It’s money for jam … time away from the office and the shelling out of a few shekels brings you back shiny new Exchange-ready employees the following week. There’s a problem with this though, it’s subtle—they’re Exchange-ready … yes, but they’re not really Anything-Ready, and that’s what we should really be looking for.
Anything-Ready
Anything-Ready is a meta-concept … it’s not about anything particular that you may know, or that you may need to know, but rather how good you are getting to know what you need to know. I’m not looking for Master Exchange Certified, or SCRUM Master Certified … I’m looking for Master UPSKILL Certified, All-Technologies-Applicable. Now that is valuable.
Which brings me back to why I place value in a university degree. When you go to university, you learn how to learn, and if you’re lucky enough to go on to do a post-graduate qualification, you get first exposure to Anything-Ready 101. I’m probably being unfair in that this judgement really has been made through the lens of technical degree … can’t vouch for a BA. Ultimately though, there’s still a whole lot of learning to do before you graduate as “Anything-Ready” and that’s the job of industry. True Anything-Ready graduates are the product of years of industry-grind-mill, post university degree.
So .. what is Anything-Ready?
Apart from getting your daily dose of mental calisthenics, addressing the root cause means that you’re eliminating a fear—that’s because if you haven’t gotten to the nub, you will always remain in fear of what may pop up later on because you chose to shortcut grokking the problem.
You can spot a course-taker a mile away, she tends to shy away from anything not within the ambit of what has been explicitly learned—face your fear and become a polyglot.
A keen study of Anything-Ready knows that the “Ready” part needs constant attention—regular reading is a must to maintain that status.
I continue to be astounded by the number of programmers who haven’t mastered the bread-and-butter of their tools. If I had a penny for every “senior programmer” I’ve met who can’t touch-type… Jeff Atwood says it far better than I could. As for your editor … choose one, embrace it, get to grok it, because if you’re a programmer, it’s the canvas of your craft.
No man is an island. Programming and Autism—two peas in a pod? It doesn’t have to be that way. Humans are computers … just really complex ones, and it does take a while, but every programmer eventually figures out that solving certain problems can be done an order of magnitude faster through a small human interaction than solitary toil. So keep community, not so much for the selfishness of getting what you need quickly, but for the benefit of your own soul.
There’s no barrier to entry with programming. Anyone with a laptop and an Internet connection can do it. More alarming though—anyone with a laptop and an Internet connection can convince Joe Sales Exec that they can do it well. That’s why the keeper of “Anything-Ready” faith knows how important always beats urgent. The “sins of the fathers” is a biblical meme that applies everywhere, not least in programming—careful what decisions you make, because they form more of a legacy for those who come after you than you may think.
It’s incumbent on us to be vigilant about what’s important. If we don’t, we’re in danger of wasting time. Distilling what’s important is about cutting to the chase and removing waste. It’s another way of repeating DRY (the only time you get to repeat yourself and feel good about it). Anything-Ready-practitioners are voracious distillers of what’s important.
Someone who is Anything-Ready knows that it’s tenuous title. They don’t call it the fire hose for nothing. Do you know someone who can actually drink from a fire hose? (no spilling). So keep that ego in check—there’s always someone around the corner way smarter than you. Really.
Back to Courses
Courses aren’t all bad. A good course will:
- Provide a formal, structured means to refocus;
- Expose you to people who you wouldn’t normally have had the chance to meet;
- Put your bosses mind at ease that the “skill issue” is being addressed (definitely a soft benefit);
- Keep the paper mills afloat.
leave a comment