[WP34s] Pauli, is this serious?



#35

Latest SVN: "move BACK & SKIP to internal catalogue"

Oh my god, I hope I'm misunderstanding something here!

Do you really intend to move these 2 commands (which are some of the most used commands at all in programs) to this (almost) hidden catalog [CPX][h][CPX]?

Then you could just as well also move all conditional commands there!?

If this is really done then the current build will be the last version that I use. :-(

Franz


#36

Blame Walter -- he feels they are better there. I tend to agree -- their potential for harm & confusion is great.

They definitely aren't going away and the assembler still treats them as first class commands.


- Pauli


#37

I'm with Franz here. Especially when used with small offsets these are very useful and should stay in P.FCN. I agree that they are problematic with larger distances (such as generated by the assembler JMP instruction) but hiding them in the internal catalogue will not help at all with this problem. I vote for putting them back in P.FCN, honestly!

#38

I'm just asking, not having checked the manual and being not very fluent in WP-34s programming, if this is already possible: Could a USER CAT be implemented, in which every user can put his favourite commands?

#39

Quote:
Blame Walter -- he feels they are better there.

I almost knew that it would be his idea. :-(
Quote:
I tend to agree -- their potential for harm & confusion is great.

Harm? What harm?

EVERY command in a program may cause harm if it is used by mistake. Enter COS instead of SIN (by mistake) and you'll get wrong results, too.

What's the difference between SKIP/BACK and commands in other HP calculators that jump directly to a line number (instead of a label)?

I would suggest that you even create a few more 'internal' (or 'hidden') catalogs and spread some other often used commands among them - this way would guarantee that almost no user would find anything anymore without searching first through a 100+ pages manual. :-(

Moving SKIP/BACK is really a good idea - but not today, because today we have April 30th but not April 1st!

Franz


#40

Apart from my question/suggestion above, I very much agree with Franz. Whatever danger may be present in any command, there is no need to protect users from jumping head first into it. Those chosen few should know fully well what they have committed themselves to, don't you think? The only question should be: what way is the most convenient to those users who actually use it. As Franz is probably 98% of the user base, he should necessarily have a say in this issue... ;-)


#41

Quote:
As Franz is probably 98% of the user base

What? Only 0.02 WP34s users except me?

Oh my god, I'm feeling so lonely ... ;-)
#42

These two are back in the programming catalogue.
There seems to be more than sufficient desire to include them.


I have also finished rewriting the statistical distributions as xrom code. A huge space saving and no doubt lots of new bugs introduced.


- Pauli


#43

Quote:
These two are back in the programming catalogue.

Thanks for bringing them back home again. :-)
Quote:
I have also finished rewriting the statistical distributions as xrom code. A huge space saving ...

That's indeed a nice side-effect, I've already thought that something went wrong in downloading the new binaries, because they're now 5-6 kB smaller.
Quote:
... and no doubt lots of new bugs introduced.

That's not so good ...

Franz

#44

Quote:
These two are back in the programming catalogue.
There seems to be more than sufficient desire to include them.

One man, one word ;-( So much about firm opinions when a little breeze rises, started by one complaining always. GTO covers this field perfectly, blind jumping is not really needed. And for those absolutely devoted to writing unmaintainable code, the internal catalogue had been the perfect location. We're far from structured coding anyway, this was a modest attempt to avoid teaching bad habits to the next generation. Didn't succeed, sorry :-(

#45

Quote:
started by one complaining always

No, not always, but just when such bad (or should I say stupid) changes are made.

And as you can see from the other replies: I'm not the only one with this opinion about this special topic.
Quote:
GTO covers this field perfectly

And needs an extra label for each jump!

The space for user-code is quite limited in the WP34s, and so every saved byte counts - but how should this know someone who hasn't even written a single WP34s program yet (at least none that I would be aware of).

Franz


#46

Quote:

And as you can see from the other replies: I'm not the only one with this opinion about this special topic.


Now, please don't exaggerate. My response is the only other one. And I was not making a point for keeping said commands but merely against a change simply for educative reasons.

Walter, a command's position in this or that catalog is not teaching good or bad programming techniques. One who learns RPN programming will do so from a teacher, from example programs or from a textbook. As the Master of the Manual you have your lectern right in front of you to make things right.


#47

Quote:
Now, please don't exaggerate. My response is the only other one.

Then you seem to have overlooked Marcus' reply.
Quote:
And I was not making a point for keeping said commands but merely against a change simply for educative reasons.

For keeping is not the same as against a change???

Indeed a strange kind of logic ... ;-)

Franz

Edited: 30 Apr 2012, 9:42 a.m.


#48

Quote:

Then you seem to have overlooked Marcus' reply.


You're right, I hadn't seen that. I'm sorry.

Quote:
For keeping is not the same as against a change???
Indeed a strange kind of logic ... ;-)

The logic comes from

Quote:
against a change simply for educative reasons.

and I could have added "or for safety reasons". I can think of reasons that would justify the change, but the arguments given by Walter (education, user's protection) don't do that for me.


#49

Remember Pascal as invented by Niklaus Wirth didn't even support a GOTO. It was a classical educational programming language. And it was a huge progress in readability and maintainability compared to Fortran and earlier languages with all their spaghetti code, and yes, I'm convinced it also made programmers thinking clearer and focussing on maintainability of software.

So why should we *foster* going exactly the *opposite* direction by promoting labelless GOTOs? Remember these commands were *not* going to be deleted by us but only moved from the shopping window into a catalogue in the background. What's the problem? With 100 local labels and some 3000 global labels, don't tell me you're running short on user program labels. Such labels will pay with every program change - don't tell me you don't modify your programs. You may use SKIP and BACK if you prefer, but then do so at your own risk and don't expect us reading your routines and supporting your debugging efforts (good luck!). With a program space of several thousand steps in total a minor fraction may be taken by label steps - the space available will still cover the real life needs of 99.x% of all RPN programmers. Not of 100% apparently, but we've to decide for keeping the WP 34S maintainable for all of us instead of trying to make a few particularily loud persons happy (which we'll never achieve for one leaving us frequently, I bet). This should give sufficient reason for our decision moving these two commands to the internal catalogue instead of displaying one of them at the very first position of P.FCN.

For the record: I've written many thousand lines of assembler code using all sorts of nasty tricks. And I was responsible for developing and maintaining SW systems several thousand people accessed and worked with at places all over the world, in different languages. So believe me I know what I'm writing about.


#50

Quote:
Remember Pascal as invented by Niklaus Wirth didn't even support a GOTO.
[...]

Walter, I'm all with you, no need to convince me that SKIP, BACK and even GOTO are potentially harmful programming techniques, that render code hard to read or understand. Personally, I have a brain too old to figure out the meaning of code containing them on a one line display. For that matter, I can hardly grasp the meaning of code beyond ten lines... ;-)

Quote:
You may use SKIP and BACK if you prefer, but then do so at your own risk and don't expect us reading your routines and supporting your debugging efforts (good luck!).

No one expects you to read, debug or maintain their SKIP-BACK-code.

Quote:
instead of trying to make a few particularily loud persons happy

In all honesty, we have to admit, that this one particular person seems to use the WP-34s quite a lot and by doing so found a lot of bugs. Ignoring the loud part of him will just help the entire project... ;-)
And given the fact that "The Loud One" helped a lot, why shouldn't he be allowed some leeway and be given a special treat once in a while? Like choosing his favorite commands for the catalog...
(Have you thought about the "USER CAT" I mentioned earlier in this thread?)

Quote:
This should give sufficient reason for our decision

Any reason is sufficient, since the project is no democracy (and I'm not saying it should be). Your reasons just didn't convince me, although they are all very good, sound and convincing reasons.

Quote:
And I was responsible for developing and maintaining SW systems several thousand people accessed and worked with at places all over the world, in different languages.

This is true for the WP-34s system as such. It should be understandable to all its users. But this isn't a necessity for the code written by the users for their own purposes. We're all free to write entirely cryptic code on our machines, that no one else will ever be able to understand or that doesn't make any sense in the first place.


Well, I think I should not have argued for or against anything here, because to me it doesn't really matter. I'm not working with the WP-34s on any professional basis but merely exercising my brain for fun. I find it fascinating that something like this is possible and that it gives me a reason to do some math exercises and wield my soldering iron in the near future to install the IR diode. But that's it, I don't do anything serious with it.


#51

Quote:
In all honesty, we have to admit, that this one particular person seems to use the WP-34s quite a lot and by doing so found a lot of bugs. Ignoring the loud part of him will just help the entire project... ;-) And given the fact that "The Loud One" helped a lot, why shouldn't he be allowed some leeway and be given a special treat once in a while?

Where is the limit? If I was just for me to decide, I would totally ignore him. Because finding bugs is no excuse for despising people.

He once went ballistic because I implemented a function he wanted in less than 24 hours but not exactly how he wanted it.

And I do not want to publish my resumé here but like Walter, I know a few things about IT & computer programming.

So I'm having a hard time undestanding why we should have to be frequently insulted by someone for a project we are doing freely. None of my paying customers ever talked to me like he does. That says a lot about him.


#52

I totally agree with how you feel. It is very unpleasant, indeed. I will act towards him here like I would in real life: use the useful part, ignore the unpleasant part.

#53

Quote:
I don't do anything serious with it.

Same here. :-)

The serious thing about the project is that it might help others to do serious (or just fun) stuff and it's an honour for us to have made it happen.

#54

Quote:
Remember Pascal as invented by Niklaus Wirth didn't even support a GOTO.

Actually, it did.


- Pauli


#55

Quote:
Quote:
Remember Pascal as invented by Niklaus Wirth didn't even support a GOTO.

Actually, it did.

...but you got an electric shock whenever you tried to type it! ;-)

Bruce.

#56

Quote:
And it was a huge progress in readability and maintainability compared to Fortran and earlier languages...

Again not quite true: Algol-60, Simula-67 & Algol-68 all predate Pascal. Certainly the first does.

:-)


- Pauli

#57

The original Pascal was also considered a terrible failure that couldn't be used for real world programming - I wouldn't suggest following that model is a good idea if you want users of your calculator.

Borland had to add a lot to make a passably practical version, and I only used it for their extensions, and would have preferred that had started with C or C++ (much like C# is now).

In any case, anyone who is programming the calculator should be responsible enough to avoid constructs they don't understand.


#58

Quote:
The original Pascal was also considered a terrible failure that couldn't be used for real world programming -

I remember it being designed to teach programming. And I used to for some real world programming, even for the first program I sold.

Quote:
Borland had to add a lot to make a passably practical version, and I only used it for their extensions, and would have preferred that had started with C or C++ (much like C# is now).

One can argue that C & C++ are not exactly the best languages to copy nowadays. CPU & memory are not as scarce as they were when C was designed. And compilers are much better at optimizing.


#59

Quote:

The original Pascal...

And I used to for some real world programming, even for the first program I sold.


Well, "Original Pascal"! What a coincidence!!! ;-) There is no way YOU could not have used it.

Edited: 2 May 2012, 3:09 a.m.

#60

Quote:
One can argue that C & C++ are not exactly the best languages to copy nowadays. CPU & memory are not as scarce as they were when C was designed. And compilers are much better at optimizing.

C was still a good choice to program the firmware for WP 34S. We even stepped away from C++ because C++ does things "under the hood" we had preferred to control ourselves.

Large systems are better programmed in languages like Java. A friend of mine has a big Ruby project up and running. You have to do too many things manually in C which are readily available in higher level languages. Think of associative arrays (or Maps).

#61

Quote:
but how should this know someone who hasn't even written a single WP34s program yet (at least none that I would be aware of).

However considered or ill-considered the change, there is no need for this kind of comment. Please keep the forum civil and constructive.


#62

Quote:
there is no need for this kind of comment. Please keep the forum civil and constructive.

Sorry for being such a 'bad boy'. ;-)

Unfortunately I'm used to say what I think, but not what others would like to hear.

Franz


#63

Franz, der Ton macht die Musik.


#64

Quote:
Franz, der Ton macht die Musik.

I can't remember having included a WAV file in my posting. ;-)
#65

Quote:
Unfortunately I'm used to say what I think, but not what others would like to hear.

It is perfectly possible to say what you think without being rude. It is called "good manners".


#66

Quote:
It is called "good manners".

Ok, it seems that many members here can't stand me because of my "manners".

So it's time to spare this forum from my presence - it's enough now!

Nevertheless I wish all of you much fun with the WP34s project in the future.

Cheers,

Franz


#67

Quote:

Ok, it seems that many members here can't stand me because of my "manners".

So it's time to spare this forum from my presence - it's enough now!

Nevertheless I wish all of you much fun with the WP34s project in the future.


You said that already a few weeks ago and came back as quickly. How can we take you seriously?

#68

58 and counting ;-)


Possibly Related Threads...
Thread Author Replies Views Last Post
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 322 10-04-2012, 04:59 PM
Last Post: Paul Dale
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 1,178 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 385 12-04-2011, 10:49 PM
Last Post: Les Wright

Forum Jump: