Thank you for your enlightenment.
My thought is: those are “conventions”. i++ could have been named “i+" or “i>” or whatever; you have to map conventions to maths to use them.
With “i=i+1”, you don’t have to remember an “arbitrary convention” to know what it does.
Somewhat like when you see something, you don’t have to speak the actual world to know what the object is…
i++ and i-- are just short hand
IF they were added there would probably never be a requirement to use them 
My take is that ++ and – are very old ideas from the C days. I think {Operator}= is a better way, and then you don’t really need the ++ – syntax.
Don’t forget that you also have other handy things like:
*= /= >>= <<= ^= &= |= etc.
The pre and post increment & decrement are indeed very old
As far as I know they mapped almost directly onto specific instructions in the PDP-8 where K & R worked on C
Personally IF I was implementing something like this I would maybe add the suffix forms only
i++
i--
as short hand for
i += 1
i -= 1
which are of course shorthand for the verbose ones
The ++i and i++ operators by themselves have the same effect, add +1 to i.
In C they are often used to increment and test at the same time. When they are used inline with another statement, The difference is when the ‘test’ is evaluated.
While they look similar, they can also obscure what is going on.
A simple example:
if ( i++ > 5) ...
– vs –
if ( ++i > 5) ...
Starting with i = 5.
The first test is false, test first (5), then increment (6).
Where the second version would be true, increment first (6), then test (6).
By themselves they are mostly harmless. Hidden in a line/statement an they can cause no end of grief.
1000%
++i++ was perhaps the worst thing I ever saw
now most compilers flag that as a warning if not an error
That’s just begging for bodily harm. 
better support for multidimensional arrays (rather than arrays of dictionaries that are arrays of dictionaries etc)
Xojo has multi dimensional arrays.
If needed I could do some functions to work on them via plugins.
Pretty much…
But also thinking of ease of use – sorry if i keep harping on about LiveCode but multi-d arrays are one of my favourite features of the language and integral to practically everything there. There is no such thing as one-dimensional arrays in LC.
examples:
[rootArray][users][id][firstName] = theName
theSurname = [rootArray][users][id][lastName]
theMeetingDate = [rootArray][meetings][id][date]
if rootArray or any of the associated arrays do not exist they are created on the spot and the value is assigned. Incredibly flexible and easy to use… i imagine dot notation would be more in XOJO’s style?
Works really well in liveCode anyway and I would really miss it if i came back to XOJO 
multi dimensional arrays are not “arrays of arrays” which seems to be what has been requested in some comments
ie/
dim a(10,10) as integer
dim b() as integer
b = a(0) // b _could / should be a single dimension array referring to a row in a
that would be handy
this would probably end up having to be added as extension methods via a plugin
multi dimensional arrays are not “arrays of arrays” which seems to be what has been requested in some comments
Lately I have been finding that i need arrays of arrays fairly often and don’t like using variants for that, so i have been creating classes for several of the basic datatypes.
Long ago i used a basic like proprietary language with that capability… It comes in handy!
-Karen
Being a bit of a purist, I’ve been using the Is operator, instead of the overridable Operator_Compare operators (=, <, >, <=, >=, <>)
In the spirit of this forum’s name, I would like an IsNot operator.
' Currently doing:
If Not( obj Is Nil ) Then
' Sometimes doing
If obj Is Nil Then
...
Else
...
' Ideally would do
If obj IsNot Nil Then
FYI, it appears // comments break the site’s syntax highlighting, and Nil should be a keyword.
ah FWIW for now IsNot is ((obj Is Type) = false)
Type? For type don’t you need IsA?
-Karen
yeah mistyped
IsNot Nil is ((obj Is Nil) = false)
since Is Nil is ((obj Is Nil) = true)
for a lot of tests you can wrap them in () and then check for true / false explicitly
in some cases it might aid readability