User blog:SquareFingers/Disappointed in PTC...

I recently found a second bug in PTC, which I wrote about here: 0.999995 (Numerical Value) (the first I wrote about in -0 (Numerical Value)). This, along with other aspects of the design (like using the value 1 for TRUE, rather than -1), makes me really hope that SmileBoom got some mature developers for V3.

Another issue I have found is the fact that  apparently takes any number of parameters (values) without delimiters, and will output one immediately after another. So,  is a   (shorthand for  ) with two values following it,   and , and the output is...  .  It allows for some shorthand, such as   will give the result   shorter than using the explicit delimiter   in  , but it has other side-effects that are confusing. For fun, I tried. I expected a syntax error, or some other kind of error. Instead, I got. What happened was that the interpreter sees, takes as much of the following input as represents a hexadecimal value , and stops. That leaves. So, what I typed was interpreted the same as, or. Since I had not initialized the variable  to anything, reading it gives the value 0, and   gives.

Next, I tried. I expected either a syntax error, meaning the  recognized that there was a fractional component to the value but was designed only to work on integer values, or , meaning the   recognized that there was a fractional component to the value and converted that fractional value as if it were expressed in hexadecimal. Instead, I got. What really happened is that  recognised that there was a character it didn't want to interpret - the   character - so it stopped interpreting at. This left  as a 'second parameter' to , which gets printed as. So,  was   or   giving. Obvious, not.

Fixed-point representations for numerical values. No need for a closing  at the end of a line where the last syntactic element is a string literal. Mistakes in the documentation (such as  where it should be  ). The rules for  with two string variables is, actually, daft (the presence or absence of a syntax error is not a matter of run-time input). No. While some of these design decisions are merely unconventional (or lazy), rather than stupid or wrong, the weight of evidence is that the design is really quite careless. I'm beginning to question my commitment to buy V3, unless there's some sign that the design team has grown up a bit and made sensible decisions and implemented them properly and thoroughly.

(Yes, the purpose of this blog is really only to get the badge. In fact, I don't doubt that I'll buy V3 the day I hear it's available.)