A year and a half ago I put together a list of personal comments found within the R18 Pro/E compiled code. Pro/E seems to be the only major software application in the world that includes these comments in the code distributed to customers, apparently other vendors usually remove them.
So, seems time to check on R20 and see what’s there. All the indented lines below are exact text from the R20 compiled code, extracted with the Unix ‘strings’ command. I’m also attaching the R18 comments, for anyone who didn’t read them at the time.
Good to see all the familiar names are still there on R20: Lev, Piotr, Anton, Jatin, Konstantin, and Mike. You might think from this list that PTC programmers must be at least 80% Russian, but probably not, seems the Russians are just more polite than other nationalities, they’re always calling each other by name: “Please tell Piotr”, “Please tell Konstantin”, and so forth.
On R20 there is a new person, Maxime:
- Please tell Maxime
In a preliminary message I said Maxime was a woman, but since then I’ve been corrected, no, he’s a man. Maxime is just an English version of a Russian male name, Maksim.
Although a lot of companies are nervous about publishing the names of technical people, worrying about headhunters, apparently not so PTC. Why, you can even get the internal phone extension of a programmer:
- Duplicated entity id %d found, please tell ET x5098.
There’s a regular flow of polite requests:
- update me please !
- MAX_ALLOC_CHUNK is wrong, please fix
But sometimes politeness gets strained, perhaps even among the Russians:
- Please yell at MIB
Why bother about all this stuff? Well, take this message in the R20 code:
- Crashing ! Have a nice day 🙂
If it was your Pro/E session which was crashing, wouldn’t you like to know? And the cheerful farewell message might just improve your mood.
Now the experienced programmer has tricks to avoid a crash:
- Filling data with complete NONSENSE just to avoid crash.
Although it’s not quite clear that this is an total solution for the end user, who may find that his data has suddenly become complete nonsense.
And there are other ways to avoid problems, even if you have to regress and be bad:
- failing, resorting to old bad behavior
Or how about this, as a message before you crash:
- bad end points!!! probably we will crash soon.
That might at least leave you time to fasten your seatbelt.
Here’s another warning message which the end user might find informative:
- VERY bad inconsistency – further actions random
Would be good to know that, so when your input has no visible effect on what is happening on the screen at least you know why, and you know it’s not you who is going crazy.
At times there is frank bafflement:
- What did I forget?
- I can’t work with NULL resource!
- hey, I should never be called no more!
- I have no idea what to do with position (%d)
- GPU is outside; how the hell did we get here?
Or small triumphs:
- just found it, didn’t I ?
We’re all human, you or I might forget to close the door, a programmer has similar problems:
- Forgot to close it.
Some of the programming terms have very descriptive names:
- The heylistenpipe socket is %d
In programming as in life, crap happens:
- crappy input
And even worse:
- shit, flow line is NULL
Sounds like a sewer leak, perhaps, seems as if the flow line broke somewhere.
Confusion may abound:
- say what?
- GuessWhat
- Mark what??
- what — no input!?
- I have no idea what to do with position (%d)
But still there’s a strong determination to succeed, keep on trying:
- We still try it.
- Longer new jump, but I think it is OK.
- One piece loop ?? (Let’s see what happens…)
Things get crazy at times, just like in any other job:
- crazy surface
- crazy geometry
- crazy option string
- Crazy visibility options
- crazy param from entity param
And you might just have to depend on sheer luck:
- No luck finding another end edge.
- illegal number %d in old ids. Good luck.
Not clear here, whether the ‘Good luck’ message is for some fellow programmer, or for the end user. If it’s for the end user, would be nice to see it printed out on the screen too.
These programmers can be pretty hard on each other at times, they can be quite critical of each other’s work:
- Stupid type
- Stupid mode
- Stupid value
- Stupid input
- Stupid parameter
- stupid model type
- Stupid param type
- Stupid action type
- Stupid column type
- Stupid dialog type
Although there are some more polite comments:
- I think this function never works. OSH
It can be difficult to follow the train of thought:
- THERE ARE FOOLOWING BEND TABLES ASSOSIATED WITH PART :\n
And things go bad too:
- bad call!
- Bad value type !
- Name is too bad. [although this might be complimentary]
- Bad pointers !!!
- Bad select data !
- selection looks bad
- Bad entity selected !
- called with bad stuff
- about to produce bad cache.
- So bad, I have to fail the slice.
- Cannot recreate onesided surfaces – very bad error!!!
And bad can even be amazing:
- Wow, really bad silhouette.
It’s true, sometimes you might not want to know just exactly everything that can go wrong with the software you are using:
- corrupted data
- corrupted info
- corrupted item
- Corrupted table!
- corrupted entity
- corrupted database
- cache is corrupted.
- pointer is corrupted.
- Corrupted model list.
- draft item is corrupted
- Corrupted file database.
- data corruption detected
- Stack has been corrupted.
- feature list is corrupted
- encountered corrupted data
- Component model is corrupted.
And corruption can get into the computer itself too:
- Disc corrupted.
- Memory corrupted.
Although sometimes a professional programmer can still keep that positive upbeat attitude:
- Just corrupted feature list!
Why does everything get corrupted like this? Here’s one attempt to explain:
- last user corrupted me
That sounds like a typical programmer, just blaming it all on the poor user.
You can hear a note of apology in some remarks:
- oops
- oops!
- oops, bad assumption
- broken edge disappear from loop, oops!
- is_chain_edges_closededge disappear from loop, oops!
- **OOPS!!** hash = (%d), not due to collision resolution
Something can still be a problem on R20, just as on R18:
- !Something is not correct!
- Something strange happened…
- something fishy is going on!!!
- msg_get() people have changed something again.
- Something goes wrong with Pro/E deregistering!
Although sometimes with a literary allusion:
- Something wicked this way comes! [Shakespeare]
And the long arm of the law can affect programming too:
- Sorry, there are legal restrictions on arithmetic coding
Worth concluding with the last two lines from my R18 report, still there in the R20 code. A question from one programmer to another:
- how could we have survived this?
And the affirmative answer:
- But we created it!
Sun Microsystems