Citizen developers

No this isnt a rant about segregating developers into groups – maybe that will be a different post.

This is more about a couple recent conversations.

One had to do with how Xojo handles conversion & comparison of unsigned & signed values. Turns out that while I closed the bug report way back when based on info from a compiler engineer I now think that was the wrong move.

Citizen developers shouldn’t be expected to know, and usually don’t want to know, the arcana of why a 32 or 64 bit value compares to another using a specific x86 or x86_64 instruction that performs a bitwise comparison (which IS whats going on).

What they DO know is Xojo compares in a way that appears to them as really really wrong. The following code on 64-bit Mac and Windows, says “Value is greater than 0.” On 32-bit Mac and Windows, the message box says “Value is less than or equal to 0.”

Var Value As UInt32 = 4294967295
If Value <= 0 Then
  MessageBox("Value is less than or equal to 0")
  MessageBox("Value is greater than 0")
End If

Thats not helpful and the explanation is truly arcane and relies on the bit wise representation of the values to explain why it appears so wrong. It might even explain some really erratic an unusual errors that people report that only occur once in a while.

The other issue that another user I was helping recently stumbled into was one I had never even thought about. If you create sql statement that uses prepared statements and dont provide as many bind variables as specified in the query then it can just silently do .. something.. which appears to vary depending on the database in use.

Again, this is not helpful and could quietly be doing harm by inserting bad data.

Thankfully this has been reported & fixed now(that no one noticed until now is a different issue)

But these two point out a specific problem. A citizen developers should be able to rely on the IDE and compiler to point out as many bugs and errors as early in the process as possible AND they should do “sensible” things.

Comparing what looks like a giant positive number and telling me its less than zero isnt sensible. Silently inserting nil instead of reporting a mismatch in the number of bind parameters isnt sensible.

Neither helps anyone, of any skill, write better more bug free code.

Shouldnt that be the goal though ?

2 Replies to “Citizen developers”

  1. Although I am a “Citizen Developer’ i do understand the arcana of bitwise representations from being around so long and seeing it explained so many times…

    But it is is not something that is likely to come to mind while busy coding trying to solve a higher level problem. Likewise I have a reasonable understanding of pointers, handles and dereferencing… but that is not a level I want to have to work at most of the time… though sometimes one has to.

    Not having to worry about such stuff (and OS specifics) most of the time, is why I started using RB over 19 years ago and what makes me more productive and coding more enjoyable. (I once worked with a consultant on a LIMS project who loved doing his own memory management in C … I thought he was crazy! 😉 )

    So yes I whole heartedly agree that whenever possible Xojo code should behave in a way most without a computer science would expect… PARTICULARLY as that seems to be the primary audience it is aimed it…

    That numeric comparison is exactly the type of thing it should handle in the expected manor.

    That said I think Aaron Ballman’s recent post on Bob Kenney’s blog in reponse to me confirming unsigned ints were just tacked onto the framework explains why such things were not dealt with as one would expect.

    RB originally did not support them and the company never made the effort to fully integrate them as with many other features added over the years..

    That is the type of low level stuff that should have been addressed when switching to LLVM if Xojo really wanted to grow up and become and adult language, instead of remaining a petulant teenager that resented not being treated as an adult!

Leave a Reply

Your email address will not be published. Required fields are marked *