Ah, but get a group of programmers who have never programmed in anything but COBOL, and see how many of them come up with such a scheme.
Databases? We didn't need no steenking databases. Flat files; many of them on 9-track tape since online storage was reserved for 'current' data. Mount up a whole bunch of tapes, and run the big strip-sort-print batch jobs that could run for a full shift or longer.
(At that point in my career, I'd spent more time
in operations than in programming.)
I don't think we bothered to document it because "everybody knew" the limitation. And it wasn't unique to any single program or system; it was widespread.
It would be like having the program documentation include "Warning: you cannot store values larger than 255 in a unsigned 8-bit field", or "This Microsoft software may contain security bugs".
I worked in banking during the late 70s and early 80s, and we were well aware at the time that there
was an issue with dates that would require changes to software before the year 2000.
People seem to think that this was some unexpected oversight; it was nothing of the sort. Given the cost of storage at the time, and the millions of records that had to stored with one or more date fields, it was a purely economic decision to save money at the time. I don't have the numbers needed to do the math, but I suspect it was actually the right choice. If you compare the cost of additional required storage to the eventual rework cost, discounting for time, maybe it doesn't look so stupid. Especially since many programs really did cease to be used before the problem arose (although probably far fewer than we would have predicted)
We all joked at the time that, along about 1998 or 1999, we would take jobs in other industries until the changeover was complete.
I agree that Newton's HWR got better as time
went on. I had the original model, and found
the recognition to be poor enough that I
replaced it with Graffiti when that option became
available.
In the 120, recognition was improved somewhat, but it seemed to really get good with the MP2000/2100. I used printed, rather than cursive, characters and found that it did a
very good job.
The data sharing capability between applications on the Newton has also yet to be equalled by any other device I've seen.
Chipwits, for the original Mac, allowed you to
program a robot by hooking together various
bits of code that sort of resembled ICs. A
google search turned up a Chipwits web site, but it doesn't appear to have
anything to say at this point.
Another was "The Incredible Machine", where you
solved problems by putting together various
components to build Rube Goldberg-esque
contraptions. It appears that some version of
this game is still in existence, see
this page from Sierra
The MPE/iX OS has an internal structure called the File Access Rights Table. I've never seen the obvious acronym appear anyware in either the code or the documentation; it's instead usually referred to as the FAR table.
I use several different titles, dependent on context. As far as the HR department is concerned, I'm an 'Engineer/Scientist', which has always seemed a bit pretentious to me, and so unspecific as to be completely useless. That gives HR a convenient bucket to lump lots of folks together for purposes of compensation, promotion, etc., but has never been the way I've titled myself either inside or outside the company.
A while back during a re-org, a group of us were allowed to decide our own titles for purposes of business cards, and we all decided on 'Senior Consultant'. That describes what I do a little better, but is still general enough that I don't need new cards printed every time there is a minor shift in my responsibilities.
Recently I've been using 'Java Architect' as my title, since that is the role I've filled for the last 5 years or so. Our lab generally equates the 'architect' moniker with a particular pay grade range. Nobody assigned me the title 'Java Architect', I just took it on at some point after taking responsibility for JDK porting activities as the best description of what I actually do.
When presenting at user group meetings or submitting articles for publication I find this preferable to a more general title.
I think of this as similar to Navy (or Star Trek, if you prefer) practice of calling the master of a ship 'Captain', regardless of actual rank. Describe the role you fulfill as broadly or specifically as appropriate in various contexts, while letting the HR folks continue to treat everyone as 'member of technical staff'.
I suppose letting everyone pick their own title could lead to a free-for-all of
title one-upsmanship, but I've actually never
seen it happen in the groups I've worked with.
Databases? We didn't need no steenking databases. Flat files; many of them on 9-track tape since online storage was reserved for 'current' data. Mount up a whole bunch of tapes, and run the big strip-sort-print batch jobs that could run for a full shift or longer. (At that point in my career, I'd spent more time in operations than in programming.)
It would be like having the program documentation include "Warning: you cannot store values larger than 255 in a unsigned 8-bit field", or "This Microsoft software may contain security bugs".
People seem to think that this was some unexpected oversight; it was nothing of the sort. Given the cost of storage at the time, and the millions of records that had to stored with one or more date fields, it was a purely economic decision to save money at the time. I don't have the numbers needed to do the math, but I suspect it was actually the right choice. If you compare the cost of additional required storage to the eventual rework cost, discounting for time, maybe it doesn't look so stupid. Especially since many programs really did cease to be used before the problem arose (although probably far fewer than we would have predicted)
We all joked at the time that, along about 1998 or 1999, we would take jobs in other industries until the changeover was complete.
In the 120, recognition was improved somewhat, but it seemed to really get good with the MP2000/2100. I used printed, rather than cursive, characters and found that it did a very good job.
The data sharing capability between applications on the Newton has also yet to be equalled by any other device I've seen.
Battery life has to improve drastically (currently about 2 hours in developer's model)
Standard apps (calendar/address book) need to be as good as the standard ones available on Palm
Without those basics, the 'Wow' applications make neat demos, but won't win market share.
Chipwits, for the original Mac, allowed you to program a robot by hooking together various bits of code that sort of resembled ICs. A google search turned up a Chipwits web site, but it doesn't appear to have anything to say at this point.
Another was "The Incredible Machine", where you solved problems by putting together various components to build Rube Goldberg-esque contraptions. It appears that some version of this game is still in existence, see this page from Sierra
Now I may have to actually try the new IM.
... or has actors in it.
(Greedy Capitalist Pig, and proud of it!)
I'd post pics, but I did the job so well that it doesn't show up in pictures. And now I can't remember where I put the dang thing.
The MPE/iX OS has an internal structure called the File Access Rights Table. I've never seen the obvious acronym appear anyware in either the code or the documentation; it's instead usually referred to as the FAR table.
A while back during a re-org, a group of us were allowed to decide our own titles for purposes of business cards, and we all decided on 'Senior Consultant'. That describes what I do a little better, but is still general enough that I don't need new cards printed every time there is a minor shift in my responsibilities.
Recently I've been using 'Java Architect' as my title, since that is the role I've filled for the last 5 years or so. Our lab generally equates the 'architect' moniker with a particular pay grade range. Nobody assigned me the title 'Java Architect', I just took it on at some point after taking responsibility for JDK porting activities as the best description of what I actually do. When presenting at user group meetings or submitting articles for publication I find this preferable to a more general title.
I think of this as similar to Navy (or Star Trek, if you prefer) practice of calling the master of a ship 'Captain', regardless of actual rank. Describe the role you fulfill as broadly or specifically as appropriate in various contexts, while letting the HR folks continue to treat everyone as 'member of technical staff'.
I suppose letting everyone pick their own title could lead to a free-for-all of title one-upsmanship, but I've actually never seen it happen in the groups I've worked with.
"a niche in high performance computing" == "programs I need to run more than once"