nnnik wrote: ↑17 Nov 2018, 03:27
Command Syntax has been removed in v2.
According to my understanding of the changes, that is misleading.
Foo(X, Y) can be called as
Foo(1, 2) or
Foo 1, 2. Given that, one could reasonably argue command syntax is alive and well.
This situation also creates 'fun' mental puzzles...
Consider the (perfectly reasonable) line
Foo A, B . Bar D, E.
I know the answer to how this should be parsed is
Foo(A, B) . Bar(D, E), but I do not look forward to having to untangle that. That requires me to keep in mind that
commas immediately after command names are now forbidden. If I forget that, I might misunderstand it as
Foo(A, B . Bar, D, E) or if I was used to v1
Foo(A, B . Bar . D, E).
Now consider the fun when one starts using the
, operator to splice lines together.
I already have to remember how to cope with the
% plague and that
! has the wrong precedence, copied from C (so always use
not instead). Then there are all of the bad ideas that I should never use in real code, like assignment in an expression, including
++ and
--, also copied from C. Good luck puzzling out the order of side effects, especially if more than one assignment is used in an expression!
And those are just AutoHotkey's bad parts involving syntax!
This is anything but 'easy'. Will a description of how parsing works be in the manual? Will we finally get to see the excuse for being told to shove everything onto one line to get a 35% speed boost? Do you really expect
beginner programmers to
understand this and
keep it in mind along with everything else relevant to solving the problem their program is meant to solve?
I wish the developers would stop trying to be clever with syntax. At this point I would suggest they just rip off C syntax like every other new programming language. C syntax is bad, but it is still better than AutoHotkey's. If you can't beat 'em, join 'em. And what I just described is definitely
not beating 'em.
I wish they would stop trying to be clever with semantics too. The behavior of the
~ operator, arrays with missing elements (consider the fun with array length when sorting or reversing such arrays), and every object is a dictionary with unreliable indexing that conflates its interface and contents, except built-in objects (gotta keep you on your toes), are just a few examples of things that should have never happened. If nobody else did something or everyone else says something is bad (e.g.
goto in a high-level language), do not do it unless you can prove it is an improvement. There is a really good reason that most modern programming languages do not have operators that behave differently depending on the value they operate on, their arrays do not have missing elements, their dictionaries do not change the values of their keys or conflate their members and contents, their built-in constructs behave like user-defined constructs, and they do not have control flow constructs that can bypass initialization.
That new behavior where everything is 'truthy' or 'falsey' makes me want to scream. It is bad enough that I have to remember that true and false are 1 and 0 (respectively) in certain contexts (e.g. when trying to visualize a data structure to do some debugging because the debugger is inadequate and there is no REPL), but now they could be
anything. There are alternatives you know. Some languages, like Scheme, Python, and C#, have dedicated boolean values. If you want a null coalescing operator, introduce a new one (probably
MaybeEmptyString ?? Default) with a high priority (after object access and before
new or anything else;
do not repeat C#'s and Swift's mistake of making it low priority) instead of abusing
or.