LoginLogin

New realization re: documentation frustration

Root / General / [.]

SquareFingersCreated:
I just figured out another aspect of how SmileBasic's poor documentation is bugging me. It's clear that it is disrespectful to the customer: "We have your money, but we're not telling you what you got in return for it", but it is also disrespectful to their own dev team. Someone took the time and trouble to, e.g., make the KEY function. They did this so that SmileBasic programmers could have something nice. Failing to document that devalues that person's work. If I worked at SmileBoom, I'd be fuming. I have worked. I am trying to make things better for other people. And the doc team, by not doing their job, is thwarting that. EDIT: Someone actually made the system so that every command (and user-defined procedure!) with one OUT parameter can be called as a function, and vice-versa.

Now it's my turn to speak out of ignorance, but what do you mean by "the KEY function"? Is it the same as the KEY *instruction* which I suppose was already documented in the manual and in-game help icon? Or is it doing something that isn't documented (which is out of my scope of comprehension)?

I think that the doc team and the code team may be one and the same. I've got no source, of course, but the way it's written just gives that impression. I completely agree that it's not cool how many of the features are left obscure like they are, not towards the customer and not towards the developers who implemented said features. But if it's really the same team like I suspect, then it's a little bit more forgivable - wouldn't you, as a developer, prefer to add more features and work on code, rather than perfect the documentation? Edit: I also think KEY was a bad example, as it is actually documented under Data: http://smilebasic.com/en/reference/#data strange choice of category but still! Edit 2: ninja'd by Lumage below :/

The KEY command is, at least, detailed in http://smilebasic.com/en/reference/. If you are referring to the in-game manual, I cannot provide any comment, but as far as I am aware the manual is a complete set of instructions. If it is a matter of the English manual being out of date with the Japanese one, one could check the dates of http://smileboom.com/special/ptcm3/media/pdf/reference.pdf and http://smilebasic.com/en/media/pdf/InstructionList.pdf. English gives me Last-Modified: Tue, 08 Dec 2015 03:17:19 GMT and Japanese gives me Last-Modified: Mon, 03 Aug 2015 00:24:30 GMT but maybe I've forgotten and I'm looking at the wrong date.

Well, I'm still confused. Would a meticulous documentation perfectionist like SquareFingers overlook the KEY command/instruction? It's also in-game. But his exact words were the KEY function, which somehow makes me think he's talking about something else.
strange choice of category but still!
If we're talking about the KEY command, Japanese creators love to use those to temporarily place kanji for easy typing. Since it's for assigning an arbitrary text string, it makes sense to me that it's in the data category, just like DIALOG.

NeatNit, Lumage: You actually help prove my point. Even the enthusiasts, people who post here, are unaware of the KEY function, which as lohadl realizes, is different from the KEY command. It is not in either the English or Japanese docs. KEY(5), for instance, returns the string value associated with 'key 5' at the top-right of the touchscreen.

Even the enthusiasts, people who post here, are unaware of the KEY function
I think we just got rekt. I blame the documentation.

Someone mentioned before we should just make our own wiki so that the enthusiasts can get their semantically accurate documentation, and I think that's the only way to satisfy everyone now. The Japanese fans did just that with their unofficial wiki: http://petitcom.net/3gou/manual/key As a translator, I would like to remind everyone that a perceived concept can be different across countries. For example, SquareFingers said that "to experts, bugs can mean programming flaws or documentation bugs", and I believe that applies to English-speaking countries. But in Japanese, the loanword ใƒใ‚ฐ (bagu) only means programming flaws (trust me on this). To them, KEY is a ๅ‘ฝไปค (command), and SB might not even try or feel the need to try to make the distinction like SquareFingers. The unofficial wiki also just said that you can obtain the content of the key by typing "var = KEY(no)", but there's no name for that. What I'm saying is, the presence or lack of a concept adds to another layer of complexity. SB's English team merely translates from SB Japan, and if they don't make the distinction due to the nature of their spoken language, complaining here sadly won't help. It's like buying stuff that's made in China :P

Lumage: You actually help prove my point. Even the enthusiasts, people who post here, are unaware. . .
>I mean it's pretty easy for me to not know these things, seeing as I don't even have SmileBASIC It's weird because this was in Petit Computer, right? And... also wasn't documented. Okay then.

It's weird because this was in Petit Computer, right? And... also wasn't documented. Okay then.
It was documented in Petit Computer. Maybe not many people looked in the "Simple Alphabetical Listings" section of the PTC manual, but KEY number,"string" is listed in there. Granted, it doesn't have a description of what it does, but it isn't that hard to try it out for yourself and find out.

It's weird because this was in Petit Computer, right? And... also wasn't documented. Okay then.
It was documented in Petit Computer. Maybe not many people looked in the "Simple Alphabetical Listings" section of the PTC manual, but KEY number,"string" is listed in there.
No, I think that was the command that is in both versions' manuals.

It's weird because this was in Petit Computer, right? And... also wasn't documented. Okay then.
It was documented in Petit Computer. Maybe not many people looked in the "Simple Alphabetical Listings" section of the PTC manual, but KEY number,"string" is listed in there.
No, I think that was the command that is in both versions' manuals.
Right. I looked, the setting command is there, but not the getting function.

Oh, sorry. I got confused between the KEY command that assigns a value and the KEY$() function that returns a value. The KEY$() function doesn't seem to be in Petit Computer, though. I tested it with PRINT KEY$(1), which didn't print anything, even after using the KEY command. Still, it doesn't give a syntax error, so I might be wrong about that.

In Petit Computer, there is no KEY$ function. If you type PRINT KEY$(1), the system interprets this as accessing the element at index number 1 in an array called KEY$.

wait There's a function to return the string associated with a function key? I had no idea this even existed. Goes to show how good the documentation is :P

I feel like KEY() may have been a function that was either forgotten about completely, was meant for debugging purposes, or was unintentional. After all, the function name should be KEY$(), since it returns a string instead of an integer. EDIT: Although, now that I think about it, String=DIALOG( "Initial string", "Caption string" [,Maximum characters]) is like that too.

They're probably lacking $ so their names are the same as their command equivalents. The same is the case with LOAD(), which is used to load a TXT file into a string. At any rate, these errors are almost inexcusable. It's possible they had rushed the documentation out the door since the NA release was so far behind schedule, but we would have to compare with the JP documentation to find out.

They're probably lacking $ so their names are the same as their command equivalents.
Meaning there is no correspondence between suffix and data type for some functions, but they kept it on INKEY$(). Another poor choice, I feel, an unnecessary inconsistency.

I hate the lack of documentation for things like this, like the VAR function or KEY function. It's harder to get a feel for what an error is if you don't know what the specifications of the function is. I wish that there was better documentation, but I guess the one now is at least better than in PTC (for most things at least).

They're probably lacking $ so their names are the same as their command equivalents.
Meaning there is no correspondence between suffix and data type for some functions, but they kept it on INKEY$(). Another poor choice, I feel, an unnecessary inconsistency.
INKEY$() doesn't have an associated command form though, like DIALOG and LOAD do. It's a strange naming convention but I guess it simplifies things.