embracing retro 'puters

[Ulsyus]

I would argue that decompiling the official program to see what tricks they used would eliminate the Critical Flaw, and enable the programmer to complete it in 5x8 with a very high likelyhood. It is, of course, contrary to the EULA to decompile and learn their secrets, but that's not your problem if you're buying the discount program off the grey market.

The problem doesn't seem to me to be one of just coding for a series of functions within one machine, it's integrating multiple systems and their inputs and outputs via the Model x. computer on board any particular vessel.

I've seen some large applications blow out significantly in time, cost and manpower input due to system integration problems. I reckon that the same would be the issue on board a starship. Using the program would be business as usual for a character with prior experience and knowledge from the military or merchant services, but there'd be a lot fewer individuals with experience writing the software for all the systems and then integrating them together. As mentioned, that could be a job for VI machines.

 

[AnotherDilbert]

Sorry, let me clarify. I'm saying that MM didn't use or study project management to establish man-hour requirements, it was just made up whole cloth.

Of course it was just made up.

I would believe that, after working in the game publishing business, MWM (or whomever the author of this chapter is) would be quite familiar with the difference between a 40 h work week and a calendar week, regardless of what process (or lack thereof) he used.

I believe he did know enough about computers to know that being able to write a program in one week with a chance that it debugs successfully means it was a very small project.

I have no idea what the author knew. I can only go by what he wrote: It takes several highly competent people on average one or two months, with a slim chance that it might go quicker. Less than highly competent people have no chance whatsoever.

That does not say "small trivial project" to me.

It is obviously not a huge project, but neither is it likely to be 400 lines of trivial glue on some libs.

No. For example, when laying out requirements for stewards an 8-hour day is specified, without detailing any allowance for overtime, or the fact that there is nowhere else to go and nothing else to do in jump.

Do you have an actual quote for that? I can find nothing of the sort in the LBBs.

What necessary tasks exactly is the Pilot or Navigator performing for 8 h a day in jumpspace, that suddenly does not need to be performed when the calendar says Saturday?

I'm pointing out the glaring error in assuming there is a huge difference between "professionally produced software" for which the poor schlubs are paying kidnap ransom price, and "self-written software" when the requirement is one guy with Comp-3 ...

and one guy with Nav-4. This IS rocket science. You have to develop a mathematical model, implement it, and then test it in the real world to be sure that it accurately describes and accurately implements extra-dimensional physics.

The difference between home-written and purchased software is not just that it is debugged but that it is run in the real world jumping many different ships many different routes.

It is the budget for testing and the size of the work force. On the latter, the requirement for writing Generate clearly removes the work force size because a single worker can produce a finished product in as little as a week, or in four months with 95% confidence.

The man-power requirement for writing software doesn't necessarily have anything to do with the cost of testing it. Say a couple of post-docs have closeted themselves for a few months, come out with a piece of software that describes how a solar flare forms. How do you test it without billions in hardware looking at the Sun?

Are all possible jump spaces easier to model than a solar flare?

The variance there is the debugging process.

That is your assumption, that I do not recognise from actual development. Good programmers do not write code for a week, then spend months debugging it.

A large part of any project is design, whether you do it separately or not. E.g. while implementing a numerical solution to a mathematical problem you might discover that the method you have chosen is numerically unstable in some cases you are trying to solve. This might well mean that you have to toss a lot of code and start over.

Maybe it requires some really high-falutin, multidimensional math... that would be available in a professional programming library. Granted, it might require Nav-4 to understand the math enough to properly use it. But it is math, and it has a right answer and a wrong answer.

It is physics. The maths describe a solution to the physical problem with some degree of accuracy. Whether the accuracy is enough or even if the maths solves the right problem might not be obvious. Until you jump...

 

[JimMarn]

I reckon you're right in the last line. The concept could be the same as illustrated with an Amiga, but I imagine that even a Model 1 being used to run a large (we know they start around 747 size) space-going vessel run off a nuclear fusion reactor and capable of Jumping into an alternate dimension in order to undertake FTL travel is going to have a few more complicating factors than what we started to learn programming on as kids.

On that I fully agree. I first wrote software on a one kilobyte ZX-81. later got the 16kb ram pack. I made a dice roller using that machine's tokenized BASIC.

At university my senior year, we wrote an assembler, next class a compiler. About 5,000 lines of code each class. It wasn't easy, but some of the other students turned out some nice code. This was on a DEC VAX 11/730.

So I can see Jump software taking a significant amount of time and resources.

 

[whartung]

One year, over Christmas vacation, I wrote a CPU simulator, and an associated Assembler for said CPU, with the primary goal of running a language implementation (which I did not write) written for the CPU.

Let me extol the joys of debugging software when NONE of your assumptions may be valid.

When you run in to a problem, is it the software thats wrong? Did the assembler not assemble it properly? Is the CPU executing the instructions properly? Buggy code on a buggy assembler on a buggy CPU. Good times, indeed.

This was but a microcosm of what I encounter every day. People of good will, trying to implement specifications and interoperate -- with all parties having a different understanding of what's supposed to be done -- even though they've all read the same documents.

Just because the software I wrote does exactly what I told it to do, doesn't mean the software will actually work when it encounters the real world.

Bad payloads, underspecified interfaces, described in detail in English which can be lousy at expressing detailed semantics. "Oh, you interpreted XXX to do YYY? We thought it did ZZZ."

Since today software is but a component of that larger integration, and the larger integration is what matters in the end, it's easy to spend "months" debugging code that was written in days.

The problem with writing Jump drive software is that we know nothing about Jump drives. We have absolutely no idea what's involved in navigation, the nitty gritty parts that happen after the navigator moves the mouse to the Regina icon and clicks "JUMP".

What we do know, while a lowly Model 1 can do the work, it seems that the Model 1 is rather big. And not only is it big, it's been big for HUNDREDS OF YEARS, long past the collapse of Moore's Law. Long past silly technological advancements. And it's still big.

But we do know that "How to navigate Jump" is, by our terms, "Ancient" knowledge. Like sailing. Despite the advent of diesel motors, and GPSs, and robot controlled ships -- sailing is sailing. We've been sailing the world for thousands of years. We've been drawing carts with livestock for thousands of years. Outside of, perhaps, material, has there really been a ton of innovation in animal tack and bridles and what not in the past 200 years? If you needed 4 horses to pull something several hundred years ago, you pretty much still need 4 horses today (assuming you're using horses). While odds are you and I couldn't go back 200 years and hitch up a team, if we brought someone back then forward, they could probably do it today with the gear we have now.

So, Jump is, truly, ancient knowledge. Since the Imperium isn't like Warhammer 40K, I'm guessing that there are lots of papers and studies and books on mundane Jump navigation. "Jump for Dummies".

That doesn't mean its simple. But it is available. Whatever secrets there are to Jump have been out of the bag for some time. Whatever you can't get in the 3I, I'm sure the Vargr will sell you. And if you pay them double, the data will even be accurate.

But knowledge is not simplicity of implementation.

We KNOW (actually, we don't, we just get better at it over time) how to calculate and estimate Lunar orbits. But have you ever seen the math involved? It's staggering. There's a reason we just let the Navy figure it out.

So, it's easy to look at Jump the same way. Yea, you can write your own system. But -- why? Are you really going to risk you $100M ship investment on piece of software written by a guy that may have had one to many Red Bull's that day?

Similarly, arguably, why would someone take on the task of writing that system? "Sure, I'll write it. You get to test it and let me know if it worked when you get back."

How much liability does the software company take on selling you Jump software? Perhaps thats part of the reason it costs 1MCr.

 

[Straybow]

The problem doesn't seem to me to be one of just coding for a series of functions within one machine, it's integrating multiple systems and their inputs and outputs via the Model x. computer on board any particular vessel.

I've seen some large applications blow out significantly in time, cost and manpower input due to system integration problems. I reckon that the same would be the issue on board a starship. Using the program would be business as usual for a character with prior experience and knowledge from the military or merchant services, but there'd be a lot fewer individuals with experience writing the software for all the systems and then integrating them together. As mentioned, that could be a job for VI machines.

So, was there any chance that these projects could have been completed by one programmer in one week? I daresay not a snowball's chance in the lake of fire.

 

[Straybow]

OK, here's what my LBB1 says:

Computer programs (especially space combat programs called for by Book 2) may be written by characters with expertise. Each of those programs indicates a throw or throws necessary, on a weekly basis, to write such a program. DMs: +1 per level of expertise. Individual must have access to a computer, and have no other duties or responsibilities during each week of work.


Nonetheless, there is always the possibility that such a program will have a fatal error and not function when actually used in space combat (referee throw secretly 7 exactly for fatal error to be written in) or that such a program will have a negative DM when used (referee throw secretly 5– for a negative DM. Half chance that DM will be –1 or –2). Expertise will serve as a DM affecting program quality, +1 per level of expertise. Flaws generally remain hidden.

Now, my LBB2 has absolutely no mention of computer programming requirements. For each program it lists size and cost and whatever game effect it has. So I don't know where you get the Comp-3 plus Nav-4 to write Generate.

 

[Straybow]

The difference between home-written and purchased software is not just that it is debugged but that it is run in the real world jumping many different ships many different routes.

Not if it can be written in a week.

The man-power requirement for writing software doesn't necessarily have anything to do with the cost of testing it. Say a couple of post-docs have closeted themselves for a few months, come out with a piece of software that describes how a solar flare forms. How do you test it without billions in hardware looking at the Sun?

You're comparing a huge scientific simulation (which by definition doesn't have a closed form solution) with an application of known math and space. That can be written in a week. Apples, oranges.

That [the variance in time requirement is the debugging process] is your assumption, that I do not recognise from actual development. Good programmers do not write code for a week, then spend months debugging it.

A large part of any project is design, whether you do it separately or not. E.g. while implementing a numerical solution to a mathematical problem you might discover that the method you have chosen is numerically unstable in some cases you are trying to solve. This might well mean that you have to toss a lot of code and start over.

It doesn't matter whether you are tossing the code and rewriting every single week. It is still debugging. And it still can be completed in one week, every single attempt made. There is no dependence, nor benefit, nor penalty for how many weeks prior the effort has gone.

It is physics. The maths describe a solution to the physical problem with some degree of accuracy. Whether the accuracy is enough or even if the maths solves the right problem might not be obvious. Until you jump...

That's the reason why we use math libraries and don't write our own. I've written a matrix solution algorithm exactly once, for a TRS-80 that didn't have a professional library. It isn't that writing a matrix solution is particularly difficult. Why reinvent the wheel?

And while we're talking professional libraries, decompiling the code of the expensive program and copying it (legally or not) is pretty much the same as copy-pasting library code. It's already done and that part doesn't need to be tested.

 

[AnotherDilbert]

OK, here's what my LBB1 says:

Now, my LBB2 has absolutely no mention of computer programming requirements. For each program it lists size and cost and whatever game effect it has. So I don't know where you get the Comp-3 plus Nav-4 to write Generate.

1977 edition?

The 1981 edition has the skill requirement and throw in the software table on p42:

So, Generate requires Comp-3 and Nav-4 for a throw of 10+.

 

[aramis]

Just to give the non-programmers a sense of scale...

Implementing the treasure tables in the D&D Cyclopaedia took about 10,000 lines of rather simple code. Took me three days to write in C++, using only the standard libraries, including pretty good debugging. Porting it to an actual GUI interface took me more than 3 days, as I gave up trying at 3 days.

Much of the skill required is interface. Coding the processes, once understood, is rather easy.

I know guys who can get the gui up and running no problem - but won't get the underlying functionality right. Different skillsets.

 

[mike wightman]

The computer programming rules were left out of 77 edition IIRC, they were included in an early JTAS and best of JTAS.

 

[AnotherDilbert]

Not if it can be written in a week.

What does that have to do with it? We will not know for sure if the generated jump space solution is good until we have used it to jump a few times.

You're comparing a huge scientific simulation (which by definition doesn't have a closed form solution) with an application of known math and space. That can be written in a week. Apples, oranges.

Is Jump Space simple and well-known maths? I believe not. If it's a trivial well-known problem why do we need Nav-4 skill?

It's a physics problem, not a math problem. A physics problem can be estimated with maths, but that is not the absolute total truth. Maths may be exact, physics never is.

So, is a physics problem (flares) that took a few months to model and code vastly different from a physics problem (jump space flight plan) that on average takes a month or two to model and code?

It doesn't matter whether you are tossing the code and rewriting every single week. It is still debugging.

If you have to write new code because the specification is wrong is not what I would call debugging.

And it still can be completed in one week, every single attempt made. There is no dependence, nor benefit, nor penalty for how many weeks prior the effort has gone.

That is a simplified game mechanic, just like that we only roll one attack roll every 1000 s in space combat.

That's the reason why we use math libraries and don't write our own.

What does it matter if we use well-tested math libs if we apply them incorrectly to a physics problem?

And while we're talking professional libraries, decompiling the code of the expensive program and copying it (legally or not) is pretty much the same as copy-pasting library code. It's already done and that part doesn't need to be tested.

If we already have Generate why would we want to write Generate? It can hardly be assumed that we already have software we are trying to write?

Reverse engineering compiled code is very far from using well documented libs.

 

[nobby-w]

[ . . . ]
Bad payloads, underspecified interfaces, described in detail in English which can be lousy at expressing detailed semantics. "Oh, you interpreted XXX to do YYY? We thought it did ZZZ."

Writing specifications is an art and it's much harder to do it well than do it badly. Unfortunately, many folks don't see the value.

[ . . . ]
What we do know, while a lowly Model 1 can do the work, it seems that the Model 1 is rather big. And not only is it big, it's been big for HUNDREDS OF YEARS, long past the collapse of Moore's Law. Long past silly technological advancements. And it's still big.

I go with the notion that the computer is not just the CPU, but a quad-redundant rad-hardened avionics system with shielding, conduits, sensors, UPSs, networking all over the ship and a whole bunch of other stuff. It's allowed to be big.

[ . . . ]
But we do know that "How to navigate Jump" is, by our terms, "Ancient" knowledge. Like sailing.
[ . . . ]
So, Jump is, truly, ancient knowledge. Since the Imperium isn't like Warhammer 40K, I'm guessing that there are lots of papers and studies and books on mundane Jump navigation. "Jump for Dummies".

And the definitive undergraduate text is Haertel's three volume, 1,750 page Fundamentals of warp field design (Known as Haertel to actual warp physicists or weaboos wanting to sound imporant). IMTU, this book occupies the same sort of niche that Knuth does in computer science. Many more folks own a copy than have actually read it.

Haertel is normally taught as a fourth year paper, with quantum mechanics, abstract algebra and several other 300 level courses as its prerequisites. After that, the courses go into proper postgraduate level work, where most of the texts are actually peer-reviewed journal articles or monographs. Warp theory is considered to be one of the harder graduate programmes - folks of a quiche-eating disposition need not apply.

Generally, when attempting to explain warp mechanics to non-technical folks, the best way to describe it is as a 'Weird quantum effect thing.'

 

[Adam Dray]

I worked on a Department of Defense R&D project that explored the use of BRL-CAD raytracing software to simulate aerosol and vapor infiltration of military vehicles, using finite element methods (FEM) and Monte Carlo simulation.

Simply getting the raytracer to create a 1-mm scale mesh around a vehicle took us months. We banged our head against the FEM math for a long time before I took it to an expert professor at University of Delaware. He said that he could complete the math in 12-18 months, given a grad student or two.

Programming the math would probably be relatively easy, but it involved inverting very large matrices, where numeric stability becomes a huge problem. I was capable of writing a college-level matrix solver, but it would have taken me years to write a proper solver with conditioning and all the other stuff required to handle a problem of the size we were considering. I eventually wrote Sandia Labs and got a license to use their DOE solver.

I guess my point is, never underestimate the complexity of software.

 

[nobby-w]

[ . . . ]
I guess my point is, never underestimate the complexity of software.

I've had several occasions to do solution architecture work on some programme or another and come up with half a dozen or a dozen FTE's in the project estimates. It's not hard to get into sticker shock territory with software projects.

 

[RandyB]

I guess my point is, never underestimate the complexity of software.

Agreed. And never overestimate the competence of programmers.

 

[atpollard]

I am going to have to interpret most of the recent posts as a “NO” vote for the OP suggestion on ‘embracing retro computers’. :rofl:

 

[Grav_Moped]

....

But we do know that "How to navigate Jump" is, by our terms, "Ancient" knowledge. Like sailing. Despite the advent of diesel motors, and GPSs, and robot controlled ships -- sailing is sailing.
...
So, Jump is, truly, ancient knowledge. Since the Imperium isn't like Warhammer 40K, I'm guessing that there are lots of papers and studies and books on mundane Jump navigation. "Jump for Dummies".

That doesn't mean its simple. But it is available. Whatever secrets there are to Jump have been out of the bag for some time. Whatever you can't get in the 3I, I'm sure the Vargr will sell you. And if you pay them double, the data will even be accurate.

But knowledge is not simplicity of implementation....

...

And the definitive undergraduate text is Haertel's three volume, 1,750 page Fundamentals of warp field design (Known as Haertel to actual warp physicists or weaboos wanting to sound imporant). IMTU, this book occupies the same sort of niche that Knuth does in computer science. Many more folks own a copy than have actually read it.

Haertel is normally taught as a fourth year paper, with quantum mechanics, abstract algebra and several other 300 level courses as its prerequisites. After that, the courses go into proper postgraduate level work, where most of the texts are actually peer-reviewed journal articles or monographs. Warp theory is considered to be one of the harder graduate programmes - folks of a quiche-eating disposition need not apply.

Generally, when attempting to explain warp mechanics to non-technical folks, the best way to describe it is as a 'Weird quantum effect thing.'

TravWiki describes Jump Drive as "poorly understood" -- even after thousands of years of practical use!

And it pretty much is. Jam an incredible amount of energy into a capacitor bank, then do something gravitic with that energy and some exotic particles through a Zuchai Crystal and a lanthanum hull grid, and bang -- you're in jump space for a week and come out some integer number of parsecs away (up to six, depending on how deep a hole you can punch in spacetime).

Why a Solmani week (mean duration), rather than a Vilani one? Unknown.
Why exactly an integral number of Solmani interstellar distance measurement units based on Terra's orbital radius? Unknown.
Why is a map of Jump destinations effectively two-dimensional, arraying those destinations as though they were constrained to a hexagonal grid? Unknown.

If one were superstitious, one might believe Jumpspace was the product of someone on Terra picking arbitrary numbers and units and there is no actual consistent system of physics underlying it all.

Code a way of navigating that!

(Ok, in-universe, Jump Space was something artificially enabled by an entity with a strange fascination for Terra, of a species with a fixation on the number six. Still...)

 

[coliver988]

Agreed. And never overestimate the competence of programmers.

And never underestimate the incompetence of programmers...

(speaking as a developer for the last 30+ years...)

 

[BwapTED]

TravWiki describes Jump Drive as "poorly understood" -- even after thousands of years of practical use!

And it pretty much is. Jam an incredible amount of energy into a capacitor bank, then do something gravitic with that energy and some exotic particles through a Zuchai Crystal and a lanthanum hull grid, and bang -- you're in jump space for a week and come out some integer number of parsecs away (up to six, depending on how deep a hole you can punch in spacetime).

Why a Solmani week (mean duration), rather than a Vilani one? Unknown.
Why exactly an integral number of Solmani interstellar distance measurement units based on Terra's orbital radius? Unknown.
Why is a map of Jump destinations effectively two-dimensional, arraying those destinations as though they were constrained to a hexagonal grid? Unknown.

If one were superstitious, one might believe Jumpspace was the product of someone on Terra picking arbitrary numbers and units and there is no actual consistent system of physics underlying it all.

Code a way of navigating that!

(Ok, in-universe, Jump Space was something artificially enabled by an entity with a strange fascination for Terra, of a species with a fixation on the number six. Still...)

Grandfather was a Solomani/Archon.

Jumpspace is man-made.



:devil::smirk:

 

[BwapTED]

I am going to have to interpret most of the recent posts as a “NO” vote for the OP suggestion on ‘embracing retro computers’. :rofl:

Indeed, even my recent posts.
LOL