Wednesday, May 18, 2011

Techjargon and Nomenclature


The title of this post combines two entries from my old Tough Guide to the Known Galaxy. We're in no rush, so read them and report back for further discussion.

Nomenclature

Techjargon

These subjects are brought back to mind by the comment thread on Space Warfare XIII, which has now reached a preposterous 836 comments, taking it past the mere 820 of Space Warfare XII. I have no moral grounds for ragging on the commenters for being bloodthirsty, given that I served up the topics. One of the many subthreads of the discussion turned to language, particularly (of course) military language, in all senses of the phrase.


How soldiers (or even civilians) talk is an issue that science fiction, fantasy, and historical fiction all face on much the same terms. Roman legionaries presumably swore in Latin, but surely not Ciceronian Latin. Nor was it even Caesarian Latin - at any rate not the Latin of De Bello Gallico, though Gaius Julius could no doubt express himself eloquently in good centurions' Latin when he needed to.

In a few cases we have direct evidence of how soldiers spoke: English troops in France during the Hundred Years' War said "God damn" so much that goddams, or godons, became French slang for the English. This is rather reassuring.

Contrary to a popular trope, most military swearing is not actually very imaginative. Yes, there is the occasional CPO or sergeant with Shakespearean mastery of English invective, but service field language relies mostly on a few very basic concepts, generously repeated.

Scroll down this old Language Log post (it isn't long) for what, from my recollection, is a very good summary of gruntspeak.

The example of godons also reveals another basic truth - styles in swearing change, over time and from culture to culture. In particular, while the Fourth Commandment still surely comes in for very frequent violation by service personnel, at least in 'Murrican military service the pride of place - as reflected in the Language Log example - now surely goes to what, with a delicate nod to spam filters everywhere, I shall call 'the eff word.' Even simpler military evolutions than passing pliers would be impossible without it.

Of course the eff word is no recent coinage. While its use by medieval English grunts went unrecorded, it surely did not go unspoken. (Shakespeare makes a sly grammatical reference to a 'focative case.') But it probably was used only in a fairly literal sense. In particular, acronyms such as FUBAR and the now-generalized SNAFU - like most other military acronyms - seem only to have become widespread during World War II.

And this is the point at which things get tricky. "Eff you!" strikes me as fairly timeless, nearly as home in the 31st century as in the 21st - or even in the 11th century, if the speaker is a Viking, given that "Odin damn!" somehow just doesn't work in our era. On the other hand, "all effed up" has - to my ear - a bit too much contemporary flavor, as though the speaker is not just a universal grunt, but specifically a current era 'Murrican grunt.

In this case, not only the YMMV principle but intended audience comes into play. Much military SF is, let's be honest, not just war porn but specifically Ameriwank war porn. Thus, for the stereotyped Baen audience (by no means identical to the full Baen readership, but surely a non-trivial part of it), 31st century espatiers who sound like they just shipped out from Camp Lejeune are a feature, not a bug. Note that this probably applies to an audience with inverse Ameriwank politics as well.

And it applies with even more force when we move away from swearing like a soldier to the more technical aspects of military language, such as names for weapon systems. SPQR may evoke Rome, but SPQ-31B evokes recent era Western militaries, and particularly (again) the 'Murrican military.

(Somewhat off message, but it surprises me that no one else seems to use USAF style sequential type numbering. Even the Soviet era Russians used manufacturer-centric aircraft designations, e.g. TU-95.)

Alphanumeric designations strongly evoke the recent era - great if the connection is intended, awkward and even frame-jolting if the setting is meant to have a more distant flavor.


More ambiguous are generic terms for weapons or ship classes, such as battleship and cruiser for combatant spacecraft. I have tended in asides and comments to come down fairly hard on such terminology - perhaps more so than is justified. For one thing, the opposite extreme of renaming familiar items can be horribly clunky. I've been unable to track down, among hundreds of comments here, a brilliantly devastating invented example, weapons with an imaginary name, described as "like swords, but more awesome." (Whoever wrote that, step up and claim your well-earned prize.)

Looking at different eras is, alas, rather unhelpful. Older terms for ship types, such as carrack or galleon, seemed to refer not to the ship's functional role but to structural features that are often now thoroughly obscure. (On the other hand, a 17th century Florentine type was called a bastardella, 'little bastard' - an expression that may not clarify its mission, but is timelessly nautical.)

Battleships and cruisers, by comparison, at least refer to familiar missions, at least in their 'classical' usage. (And by SF convention, cruiser seems to retain the sense of a large, fast independent patrol craft, not a heavy escort type.) I have argued against the automatic lifting of this nomenclature, as introducing a bias into our thinking about space warfare. But having said that, it is hardly implausible, in operatic settings, to have some heavy spacecraft, optimized for fighting power, that operate in main-force constellations, and somewhat smaller ones, optimized for mobility, that operate independently.

Details of an imagined technology come into play here. If the 'cruisers' are individually larger than 'battleships,' as is plausible (more propellant, larger crew), the classical terminology becomes a bit misleading. But this does give you a great excuse for battlecruisers, and the Rule of Cool is hard to resist in this case.

Another consideration is particulars of a future history. My old 'Human Sphere' setting was a variant on the standard First and Second Empire theme, and centered on nascent 'Second Empire' trade federations in the 28th century.

The 'First Empire' had no heavy space force in its salad days because it needed none. (Who was it going to fight?) So that particular setting should display a great discontinuity in military affairs. People might well cast back into history books to revive terms like frigate, but on the whole their combatant spacecraft and military institutions would more likely be adapted from police, exploration, or other activities and organizations that have some quasi-military features. Thus, in this particular setting, survey ship comes to have nearly the usual connotation of cruiser.

On the other hand, if your setting has space militaries established by terrestrial Great Powers in the 22nd century, with the latter having substantial continuity with the present day, your nomenclature jumps through a very different set of historical hoops, and cruisers can just be cruisers.



Discuss.


The image of a space battlecruiser comes from this SF website. I nabbed it via Google Images - one of eight space battlecruiser images that come up before the first image of the seagoing kind, HMS Hood. Not until the second page do you find any image of a ship that fought at Jutland.

231 comments:

«Oldest   ‹Older   201 – 231 of 231
jollyreaper said...


Jollyreaper:

"*IF* we develop strong AI, and by that I mean human-equivalent, I think that will be the end of programming."

Do you count programming done by the strong AI?


I mean the end of programming done by humans. It's just like if we have a strong robotics and strong AI utopia, that doesn't mean work no longer needs done, it just means that it's no longer done by humans except by choice.

Some people call the idea of strong AI and strong nano a cornucopia machine. I personally would call it the genie in the lamp society and in this case you really can wish for more wishes.

Remember, the moment something has strong AI, you need to start treating it as a character rather than a tool.


Right, which is why storytelling with strong AI becomes so exceedingly difficult. Really, you run into the same problem if you're writing a story populated by super-geniuses. How do you convincingly write someone who is smarter than yourself? I think that's the primary reason why we see so many dumb protagonists -- it's easier to write someone dumber than yourself and if you're not all that bright to begin with, the bar is lowered.


Future programmers might make use of a tool that automatically optimizes an algorithm for a given objective, but first you need to explain in terms the computer can understand what your objective is. That's coding.


The way an early programming teacher explained it was asking us how to describe to a moron the steps in changing a tire. He put a huge flowchart on the board and delighted in doing the wrong thing every time we forgot to specify something. "The computer can't think, it only does. It won't do anything out of malice but any oversight on your part is not going to be happily fixed by a second set of careful eyes. You ask a servant to draw water for a bath, you don't have to remember to tell him to turn off the water when the tub is full."

With strong AI -- or a really tailored expert system -- it's not going to feel like programming, it's going to be a request. Especially with natural language processing. I reserve a car over the phone with the computer agent, it'll know to ask about what color I want if I don't specify. It didn't think of that itself, it was programmed to. Of course, it can only take car reservations and if they want it to take train reservations instead, most of the software remains the same but the dialog script will have to be modified. Programming!

In the plausible mid-future, someone's going to have to write some code to make it go from cars to trains. In the strong AI future which I think would have to come after the plausible mid-future, you tell it it's taking train reservations and it says "Righty-o." And even more likely, you won't be the one telling it to change jobs because it will already have identified the need and spawned a new instance to handle it.

jollyreaper said...

re: washing machine example

I get what you're saying here. A lot of this tech is moving faster than I realize so it's really hard to have a common sense and intuitive feel for the possibilities. I'm still blown away by the CAD stuff from 15 years ago where they could design the engine and run a 3D model simulating motion and stresses for analysis.

Frankly, I'm amazed at how good handwriting recognition has gotten. I can put a written check in an ATM and it will scan the check, orient it right side up, and read the amount off of it. 15 years ago these problems would have seemed 50 years off for a solution.

Here's something else that's pretty crazy.

Digital whiteboard.
http://www.youtube.com/watch?v=usYFG7ffJHA

The guy is able to draw simple shapes on the board just as any physics teacher would when talking about basic mechanical problems. The trick here is that the computer recognizes what he's drawing and can then run a physics simulation based on it! It feels like an old Loony Tunes like Duck Amok where you see the cartoonist's pencil reach in and draw something that then behaves realistically like the anvil sketched in over Daffy's head that then falls and hits him on the head. And this is from five years ago. Heady stuff.

There are two big mistakes when looking at futurism. The first mistake is in overestimating how far things will go. The second mistake is underestimating how far things will go.

jollyreaper said...


How computers will evolve seems to be a bit of a mugs game; current computers are essentially brute force devices and supercomputers mostly rely on harnessing even larger clusters of processors and hard drives to the point of diminishing returns. Some sort of "Cambrian revolution" may take place where one or more breakthroughs allow radically different hardware and programing architecture(s) to replace digital computers. If holographic computers or quantum devices take over from digital computers, then our entire way of thinking about computers will also have to change.


As far as futurism goes, there's the difference between "It's powered by applied mcguffinite locked in this black box. No idea how it works but here are the consequences." The positronic brain is one of the all-time best examples of this. But there's that magic point between "I have no idea how we could do this so let's pretend" and "No, wait a sec, I think we can actually do this!" I'd say plausible mid-future tech is when we begin to have a clue how it can be done. Far future tech is when we can't even begin to imagine how we could start doing it. O'Neill Cylinders are mid-future. Positronic brains are far future.

Tony said...

Re: SA Phil

My argument is not a red herring. It's just not what you want to hear. I keep being accused of imagining a static future, but what you're imagining is the true static future -- endless variations on stuff that's already been done. As long as that's all you require, I can see your vision working out. But the second you start building stuff that nobody's built before -- and to draw this back to the original argument, that's what military technologists do all of the time -- then you can't rely on autoprogramming based on previous experience. The algorithms haven't been invented yet. And without known algorithms, no autocoding system can do anything, because such a system of necessity follows pre-built templates.

jollyreaper said...


My argument is not a red herring. It's just not what you want to hear. I keep being accused of imagining a static future, but what you're imagining is the true static future -- endless variations on stuff that's already been done.


I was talking with my uncle about tractor builds and I think there's a point of comparison.

You've got someone buying a Cub Cadet out of the store. Ok, fine. It's sold as-is. You can work on it with parts you get from the same store. Someone else says no, I want to build my own tractor. The frame is custom-welded. But where's the engine come from? Oh, from the store. He might do something unusual like use a bigger engine than the usual lawn tractor. Hell, there's motorcycle customizers who managed to put Corvette engines in their bikes, don't ask me how. So where did the the tires come from? The store. The lights? The store. Gas tank? The store. Everything already exists, he's just putting it together in a different way. The real kicker is he can overbuild it.

The Cub Cadets these days are china-built and awful. The old ones back when they were built by International Harvester, they had some balls. If you're building your own tractor, you choose the quality of the parts. You get what you want. But at the same time, you're not sitting down with milling and stamping machines and trying to build the engine from scratch.

A lawn tractor isn't going to be on the cutting edge of anything. The military vessel is likely going to require the invention of new technologies and a ton of R&D before the parts ever go together UNLESS we've hit a very solid tech plateau.

A good tech plateau example with a design library would be something like the Dune universe. Despite being ten thousand years in the future, we're still talking about humans fighting each other rather directly, mainly infantry combat but also the use of military vehicles. And because every planet is different, every planet will need different kit. So if the Sardukaur find themselves sent off to Arrakis, they're going to need vehicles and weapons suitable for that environment. They find themselves fighting on an airless moon, a whole different set of weapons and equipment. Even on Earth we often find that our weapons and tactics that work great for one theater are unsuitable for another; sometimes it takes minor modifications, sometimes it takes swapping out one vehicle for another.

And even as far as the Dune universe goes, the static technology was an artifact of the culture. Remove that anti-development imperative and tech takes off in weird new directions.

Tony said...

jollyreaper:

"I was talking with my uncle about tractor builds and I think there's a point of comparison."

Another point of comparison is point-of-sale (POS) terminals. How many different POS interfaces does the average American encounter within the same week? Even when encountering the same hardware model, one might find different interfaces in different places. Gee, same hardware, different software? Say it ain't so!

But that's a reality of the software world. You ask ten programmers to write to a specification? One spec, twenty different solutions. All of them work, and each of them may be the besat at optimizing for something in the spec, while adequately andwering all of the other requirements.

We can't develop the optimum POS interface solution, that everyone can agree on, but the future of software is going to be dominated by standardize algorithms that can be autowritten to any spec?

jollyreaper said...


We can't develop the optimum POS interface solution, that everyone can agree on, but the future of software is going to be dominated by standardize algorithms that can be autowritten to any spec?


The only possible solution I can imagine are the neural nets and learning algorithms. That robot I linked to above, it's teaching itself how to walk. The old model of programming says you have to teach it how to walk on every terrain. Inside on a carpet, fine. Outdoors on wet grass, especially on an incline? You don't program that, it can't walk it. But this one can learn how through trial and error.

That strikes me as something I might buy in a novel 20 years out but wouldn't but it for Next Sunday AD. Except it's here and working. It's real.

There's certain levels of disbelief you can run with for a story. Zombies, so long as nobody tries to explain them as natural creatures, you can run with that. Working out the implications of telepathy and mind-reading in the modern world if it suddenly existed can be fine. There's a very rich history in scifi of adding one impossible thing to the world and exploring the implications. But there's a sort of agreement between the author and readers about whether or not they're saying it's really true. It's the difference between "let's pretend" and "no, seriously, I think this could happen."

Anonymous said...

Tony,

the future of software is going to be dominated by standardize algorithms that can be autowritten to any spec?

----------
Those algorithms are just associations based on the underlying physics.

Which is already standardized, see: design of the universe.

You basically just need a computer that is "a whiz" at Differential equations and making those associations.

Herring, thy color is red.

(SA Phil)

Anonymous said...

(SA Phil)

I agree the computer future I imagined/ described makes for an aweful boring Sci Fi story.

In a sci fi story I think on-the-fly programers and custom software solutions would be far more interesting.

Tony said...

SA Phil:

"Those algorithms are just associations based on the underlying physics.

Which is already standardized, see: design of the universe.

You basically just need a computer that is "a whiz" at Differential equations and making those associations.

Herring, thy color is red."


Okay...tell us why an abstract data type is "abstract".

"I agree the computer future I imagined/ described makes for an aweful boring Sci Fi story.

In a sci fi story I think on-the-fly programers and custom software solutions would be far more interesting."


Red herring. Once again, on-the-fly programming was never an issue. You created it out of a misinterpretation of something I said about the prudence of humans supervising automated systems in combat. If you wish to persist in this misinterpretation, that's a you problem, not a me problem.

WRT custom software solutions, custom hardware (i.e. military systems) => custom software solutions. If you don't think so, can you provide a formal description of a programming system in which general purpose software can be tailored to custom solutions without human intervention?

Anonymous said...

Tony,

Red herring. Once again, on-the-fly programming was never an issue. You created it out of a misinterpretation of something I said about the prudence of humans supervising automated systems in combat. If you wish to persist in this misinterpretation, that's a you problem, not a me problem.

==========

How is this a red herring? - this was me describing a preference in story telling.

I didnt say "Tony's model is more interesting in sci fi stories"

Since you said you didnt go with the on-the-fly stuff that I misinterpreted you saying before.

However,
A programer struggling against time as hail of incomming missiles nears to adjust how the point defense system's logic could be pretty dramatic in a Sci fi story.

(SA Phil)

Tony said...

SA Phil:

"However,
A programer struggling against time as hail of incomming missiles nears to adjust how the point defense system's logic could be pretty dramatic in a Sci fi story."


Who'd believe it?

Tony said...

BTW, Phil, were you going to tell us about abstract data types or weren't you?

Anonymous said...

(SA Phil)

Was in the middle of that - but ran into an issue on the floor.

===========

I have an advanced, working computer model, the abstract data will be availible.

For a more specific instance, For automotive control systems we use data lookup tables precisely because there are thousands of holes in our Mathmatical models.

Thus, fill those holes, the need goes away.

Tony said...

SA Phil:

"I have an advanced, working computer model, the abstract data will be availible.

For a more specific instance, For automotive control systems we use data lookup tables precisely because there are thousands of holes in our Mathmatical models.

Thus, fill those holes, the need goes away."


Okay, but what about abstract data types?

Teleros said...

Milo: "It's like I said before. To get a computer to do something for you, you need to be able to explain to the computer what you want. Explaining to a computer what you want is, per definition, coding."

"Yesterday I had this document that needed filing, so I coded a subordinate (human) worker in my office to file it for me, as I was busy."

Doesn't sound right. I suppose you could try and distinguish between strong AIs with no free will being "coded" to follow an order ("file this document"), and fellow sapients (that just happen to exist as software in a computer) being ordered / asked / whatever to do something.

IOW, whilst coding may technically be the correct term to use, I suspect it'll fall out of favour the closer we get to having strong AIs, which is probably what the debate over "coding" strong AIs here is about.

Anonymous said...

Tony,

Who'd believe it?

=====
Weber put something like that in his first Honor Harrington book.

Cardones reprogrammed a nuclear warhead missile on the fly to get it past the Q ships defenses.

Of course -- Weber isn't really the most "believable" but it can be entertaining.

Most Science Fiction fans will believe almost anything though. Just look at all the people who try to justify the science of Star Trek, or those who claim Babylon 5 was realistic because some of the space fighters obeyed Newtonian physics in space.

jollyreaper said...

B5 was pseudo-realistic. Not entirely realistic but made the right nods to reality and excursions from reality seemed intentional rather than from pure ignorance or apathy. C'mon, newtonian fighters, rotating hab sections? It's a frickin' bone and they're throwing it to us. ;)

Anonymous said...

(SA Phil)

You haven't heard the one about how Babylon 5 is entirely real spaceships because supposedly NASA wanted permission to use the Star Fury design?

heh

jollyreaper said...

Real world interest

Around 1995 ("two years into the show"), NASA expressed an interest in the design as a work vessel for the International Space Station. They apparently consider the design to "make the most sense" for zero-g work due to the thruster and wing setup. They approached the shows co-executive producer (J. Michael Straczynski) for permission to use the design, which was given provided the Starfury name was not altered.[13]


That's from the wiki. I remembered reading that when the show aired. Doesn't seem unreasonable. We're not talking about building a real starfighter here, just a tug using the same engine configuration.

Anonymous said...

(SA Phil)

Heh .. yes .. but the fans I am speaking with wont/cant/are unable to see the distinction.

They see the entire thing as an endorsement of the show's realism.

they see Star Fury and insist it means the fighters.

Aaron Lee said...

Reading the very first .00001 percent of this massive, massive comment thread got me thinking about lingual complications in neo-medival space cultures.

Mostly I used it as an excuse for them to not have an ISO-9000 compatible standard for class names. The standoff and defense focused Earth forces tend to call nearly every class not in their own ranks 'ship destroyer' because it doesn't matter whether it is small, large or armed with missiles or LASERs so long as it is still roaring at you on an assault vector and loaded down like a gargantuan long firework.

Conversely, the Martians call light craft 'speedboats' due to their annoying tendency to rush past their ranged weapons and duck through their poor point defense nets. So you would hear "Motora de mierda!" A lot.

Tony said...

Thucydides:

"The actual problem with the Babbage machine and the Analytical Engine turned out to be mid Victorian machine technology wasn't advanced enough to make the precision gears needed for the thing to run smoothly...If an accurate gear cutter existed, we might be talking about the IT department as the "black gang", and your introduction to working in IT would be shoveling coal as a stoker or lubricating the gears."

I don't think so. Before electronic digital computers there was a wave of electromechanical analog computers, particularly for naval and lad artillery fire control applications. They were precision instruments that required a lot of skilled TLC. I don't think you could describe their operators and maintainers as "black" in the steam engineering sense.

"...current computers are essentially brute force devices and supercomputers mostly rely on harnessing even larger clusters of processors and hard drives to the point of diminishing returns."

The whole "brute force" thing is an old school mainfrma programmer's attitude about modern computing. He sees elegance and compactness as virtues, because they were in his day. But elegance and compactness come at the cost of requiring preconditioned data and limiting output to text only. With 21st Century computing resources, the programmer has the power to programatically validate the data. For example, any program I write that uses human-generated data is at least half defensive code, designed to catch data input errors and go back to the user for correction. And when it comes time to output a response, I can rely ont the user's web browser to display a wide variety of style combinations, fetch numerous images, and even do some computing for me locally on the user's machine.

Thucydides said...

The black gang reference to the Babbge machine is a half joking hat tip to the power supply of the device, which in the mid 1800s would have been a steam engine. By the turn of the 20th century (in this scenario) IT would have been steam powered for almost half a century, and a server farm would feature a drive shaft running across the ceiling and pulley belts going down to each individual Analytical Engine. even with electric motors being substituted for steam I can still see the terminology of steam engineering remaining.

The second point was addressed to the various arguments about programming. I can see no break in current programming conventions simply by piling on more CPU power, and ended by suggesting that the situation could not change unless some sort of totally different device arises (I suggested holographic and quantum devices. I should have said "photonic" in place of holographic).

I hope I was clearer this time around...

Tony said...

Thucydides:

"The second point was addressed to the various arguments about programming. I can see no break in current programming conventions simply by piling on more CPU power, and ended by suggesting that the situation could not change unless some sort of totally different device arises..."

I understood that. I was just contextualizing the "brute force" terminology. Brute force means you are either not expert enough to find an elegant solution, or there is no elegant solution for the problem. It is also used in connection with "bloat code" to suggest that microcomputer software practices are inefficient. I was just pointing out that "brute force" and "bloat" are what makes the rich computing environment we have nowdays, because that's just how it has to be done.

Anonymous said...

Something occures to me; some commenters have assumed that even if a space service starts out with Air Force type ranks it would later switch to Navy type ranks. That makes little sense to me; once a military service is established, it actively works to build its own traditions and individual identity; I would expect any military space force to follow the same path, to a greater or lesser extent. So, it would seem reasonable to assume that after a period of adaptation, a military space service would evolve a unique system of ranks and structure, and traditions and procedures, driven by circumstances, experiance, and necessity.

Ferrell

Anonymous said...

=Milo=



Realistically, army, navy, and air force ranks tend to be pretty parallel, just with different names. As for space, this is where things like "translation convention" and "limiting made-up words" come into play.

If a space force starts off air force-like and later turns navy-like, you're likely to have officers whose titles are derived from air force ranks (with some centuries of sound change obscuring them), but which in practice have navy-like duties.

Thucydides said...

Conjecture is difficult to do, and we are often misled by supposed historical examples.

Earlier upthread, someone stated "Tanks are the best way to deal with Tanks". This is accepted "common wisdom", but likr the "Thin Red Line" turns out to be untrue. Historical examples and operational research going back to the Russio-German "Great Patriotic War" of 1941-45 demonstrates the best way to deal with tanks is prepared positions armed with tank killiing weapons. In the 1940's it was a PAK 75 or 88, in Lebanon the Hezbollah used Koronet ATGM's against Isreaili Merkavas but the effect is the same. Tanks are best used for mobility, thrusts and counter thrusts.

Computer programming may well have the same received wisdom, and while I can't comment directly on what that might be, I am sure lots of people work under those assumptions and are therefore putting themselves in the wrong box to think outside of.....

Tony said...

Thucydides:

"Earlier upthread, someone stated "Tanks are the best way to deal with Tanks". This is accepted "common wisdom", but likr the "Thin Red Line" turns out to be untrue..."

The "thin red streak tipped with a line of steel" was real enough, just misunderstood when taken out of context. So is the assertion that tanks are the best weapon against other tanks. All other things being equal, they are. When one starts talking about prepared positions and such like, one is going out of the context in which the statement was made.

"Computer programming may well have the same received wisdom, and while I can't comment directly on what that might be, I am sure lots of people work under those assumptions and are therefore putting themselves in the wrong box to think outside of....."

There's very little received wisdom in computer science. That's why it's called a "science" -- assertions have to be mathematically demonstrable. When you go to Data Structures class, for example, you don't just learn the mechanics of lists, trees, arrays, hash tables, etc. You learn the mathematical validations of their uses vis-a-vis each other and in realtion to certain problems in data management. Remember, all computing is, is applied mathematics. There's no box to go outside of if you know the math.

Scott said...

"Something occures to me; some commenters have assumed that even if a space service starts out with Air Force type ranks it would later switch to Navy type ranks. That makes little sense to me; once a military service is established, it actively works to build its own traditions and individual identity; I would expect any military space force to follow the same path, to a greater or lesser extent. So, it would seem reasonable to assume that after a period of adaptation, a military space service would evolve a unique system of ranks and structure, and traditions and procedures, driven by circumstances, experiance, and necessity."

The reason I lean towards naval rank structures in a space force (wrote fleet there the first time) is partially because I was Navy. However, I have a much better reason: mission equivalency.

No Air Force has anything equivalent to anything larger than a PT boat, and even the PT boat has several times the endurance of a bomber or transport (days, not hours).

Right now, every spaceship in existence is a specialized airplane. Even the ISS doesn't operate 24/7/365, the crew has a fairly normal 12-15 hour awake period with maybe 8 hours being devoted to whatever projects are going on.

In contrast, a ship has someone standing lookout 24/7 (call him the sensor operator). Now, you might be able to have an expert system wake up the captain to tell him that something weird has happened (there's certainly enough other computer programs that do just that), but there are so many non-routine tasks and events that it's easier to keep a larger crew awake in shifts than it is to have a minimal crew waking up every 60 minutes when something goes weird. And I wish I was exaggerating about the time between out-of-parameters events on something as complicated as a submarine or starship.

Anonymous said...

Scott, I agree with you on most of your points, but I still think that their are enough differences that no matter if the hypothetical future space service starts out with either Navy or Air Force type ranks and structure, it will eventually evolve into a unique system, due to it having unique needs and requierments. Whichever Service it uses as a starting point will of course influance its developemnet, but the end result will be different than either one.

Ferrell

«Oldest ‹Older   201 – 231 of 231   Newer› Newest»