Commands vs Functions

Discuss the future of the AutoHotkey language
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Commands vs Functions

23 Jun 2016, 03:09

I have been updating the v2 documentation, and it has got me thinking again about command syntax vs expressions.

Within the documentation:

Terminology:

For consistency, I'm inclined to use the term "function" (or just its name) when referring to a particular function/command, while a "command" (if the term is used at all) would refer to a partiular line of code that calls the function for some effect. For example, StrReplace is a function, but "StrReplace, MyVar, %MyOtherVar%, `r`n, `n" is a command.

In any case, listing and documenting "functions" separately from "commands" doesn't make sense, so the documentation for each of the functions on the Functions.htm page will be moved; either to its own page or to a page shared with related functions.

Problems with having two syntaxes:

Sometimes choice is a good thing, so choice of syntax might seem like a good thing, too. Unfortunately in this case it translates to redundancy in the documentation, which is not a good thing. Documentation takes time to write and maintain, and it takes time to read. When there's twice as much writing for the same amount of information, it's harder to absorb the information, and harder to find specifics when you need to refer to them.

When you write StrLen, MyVarLen, %MyVar% or MyVarLen := StrLen(MyVar) there seems to be only a few characters difference, but the two different syntaxes seem to represent subtly different concepts that require explaining in different ways. For instance, "OutputVar: The name of the variable in which to store xyz." When the syntax is shown together with StrLen, OutputVar, String and OutputVar := StrLen(String), this description works with both, but it misrepresents the capabilities of expressions (implies that you have to use a variable).

Examples:

Within the examples, do we represent each syntax equally, pick a syntax to stick with overall, or go with whatever seems most natural for a given function?

Duplicating each example would be useful for someone trying to learn the differences between commands and expressions, but they wouldn't need to in the first place if we had only expressions. It's more work to write, and adds considerable length to the documentation.

The choice of syntax for a given function may be subjective, so the "whatever seems natural" option might not be suitable for every reader.

There are reasons to promote the use of expressions (which I won't go into just yet), but I think that if the examples focused on expressions, it might put more pressure on beginners to learn them. If beginners are basically required to learn expressions anyway, I think there is less value in keeping the command syntax.

Why commands anyway?

Some say that commands are easier to learn.

I don't understand the argument well enough to deny it. What makes commands easier to learn than expressions?

Is it hard to understand that literal text should be enclosed in quote marks? If so, is it easier to understand that variables should be enclosed in percent signs?

Is the problem more fundamental, with beginners having difficulty distinguishing between literal text, numbers, variables, functions and operators? Perhaps they're just lacking proper learning materials.

Given that even assignments and if-statements in v2-alpha require some knowledge of expressions (i.e. use quote marks, not percent signs), does having command syntax really benefit beginners?

I think that part of the perception that commands are easy to use or learn comes from a) users having started with commands in v1; and b) that the particular commands users start with are simple (by contrast, DllCall and RegEx are incredibly complex) and often give immediate visible results (WinActivate, Send, WinMove, etc.). Expressions can do a lot more, so perhaps users are more likely to be overwhelmed by the possibilities and the amount of information in the documentation. If so, that might simply be a failing of the current documentation.

If the comparison is limited to just what commands can do without expressions - literal text, variable substitution and output variables - there's nothing inherently more difficult about the expression syntax. If anything, it could be easier since it is more uniform.

Some say that commands are more convenient.

The main point is that commands don't require quote marks for strings. A command-heavy script might require "lots of useless quote marks" if converted to expressions. But these characters really aren't useless - they clearly delimit text from everything else.

Commands require percent signs for variables (and expressions), so if you have more of those, commands end up with "lots of useless percent signs".

Anyway, what's the problem with writing two quote marks for each text value? Part of the problem might be commands that were designed with the string-oriented command syntax in mind. For instance, WinGet, WinSet and Process have already been converted into sets of functions, mainly for consistency but also because the old syntax required more quote marks.

Commands don't require parentheses around the parameter list, but they sometimes require a comma after the command name. If you use commands, you either consistently write this "useless" comma, or you sacrifice consistency and write the comma only when needed: e.g. MsgBox Text vs MsgBox,, Title, Text.

Some of the "convenience" lost by requiring quote marks around strings with commands would be gained by allowing variables and expressions without percent signs, or in other words, not requiring parentheses for a function's parameter list.

Hypothetically, some new syntax could provide both convenience and flexibility. For example, hwnd := WinExist'My window, Some text' would pass two parameters to WinExist, and Array' red, green, blue ' would create an array of three strings (commas and whitespace would be handled as they are for a v1 command). However, I'd rather keep that in the realm of ideas and experimental languages.

Commands are part of AutoHotkey's identity.

But what exactly is AutoHotkey's identity, and does that benefit its users?
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Commands vs Functions

23 Jun 2016, 07:26

As someone claiming that Commands are easier to learn I want to show you my opinion before making the final decision on AutoHotkey V2.

1) Required-Knowledge:
Before you even start getting into programming, before you even learn about the existence of Expressions and Commands and the like, you know nothing.
You don't know of types. You don't know of variables. But you do know text.
In order to learn what an Expression really means - even for a simple WinMove - you need to know of the existence of quote marks and their meanings.
When you just downloaded AutoHotkey where are you supposed to learn them from?
The help file won't deliver any good results when searching for ".
That also means that you need to know when to use " and when it is a number, meaning you need to know the difference between 2 types before being able to use a command.
Isn't that exactly the thing the entire AutoHotkey type system tries to prevent?

2) Readability
Most people (at least before starting to program) don't give the small characters any really special meaning.
Even when you just learned about expressions and you try to start programming with them or try to read more complex scripts then you just won't understand them.
In comparison to that it is really easy to advance from simple MessageBoxes and WinMoves to a more complex and dynamic approach by slowly learning the meaning of % and :=.

3) Advance
When learning AutoHotkey you can slowly progress from static content - that you can create with almost no background info - to completely dynamic OOP code.
You can take it in little steps at a time - although you still need to jump from Commands to Expression and from Labels to Functions...
The point and I think the identity of AutoHotkey is one of a tool.
A tool someone with almost no experience can use. But a tool that once mastered is an extremly powerful one.

Regarding the documentation.
Why not make a page to describe the difference between Expression and Command Syntax and then describe the Interface that's before them in each page?
Recommends AHK Studio
Coco
Posts: 771
Joined: 29 Sep 2013, 20:37
Contact:

Re: Commands vs Functions

23 Jun 2016, 09:24

Terminology:
Commands are functions anyways, I don't see any problem with using one term, especially for v2. As for the differences between the two forms(Command syntax & Expression syntax), Expression syntax can be called something like "traditional form" and Command syntax can be called something like "simple form" or "unorthodox form". Ditching one of them would definitely simplify everything.

Problems with having two syntaxes:
  • Having two syntaxes promotes confusion.
  • I assume would require additional dev effort when trying to fix/improve/extend the language. An example would be the current limitations(or shortcomings) to the parser (again my assumption - e.g.: due to the need to consider literal text/strings in command syntax in the script code, is the parameter a literal text or an expression?, etc.)
  • More effort when providing (sophisticated) AHK support for text editors
  • And more - I reckon
Some say that commands are easier to learn
Personally, I think that this is a misconception. They are easier because the majority of the examples in the help file are written in command syntax. This is inevitable for v1 since majority are "commands" anyways. New users are introduced to that syntax. If commands in v1 are available as functions and if the examples in the docs are written in function syntax, function syntax would probably be easier to learn.

Some say that commands are more convenient
Only when dealing with simple script requirements. Sooner or later, a user will have to learn expressions, functions. They would need RegEx at some point anyways...

Commands are part of AutoHotkey's identity.
More like part of AutoHotkey's lack of foresight. IMO, the feature of commands that treats parameters as literal text unless forced expression is used should have been ditched or altered the moment AHK started supporting user-defined functions. AHK is easier to learn not because of this(literal text command parameters) feature but rather of the amount of high-level functions/commands that are available built into the language that makes automation as easy as possible - e.g.: WinMinimizeAll/WinMinimizeAllUndo, etc.

Having the choice between command syntax and functions syntax for v2 is definitely a plus. But if supporting only one of them, say function syntax only, makes development/maintenance of AHK easier or convenient, which means potential improvement/growth for the language, then I have no issues with the removal at all. As for compatibility (or even nostalgia for the command syntax), one can write a transpiler that outputs valid AHK v2 code(akin to TypeScript, CoffeScript or any of those languages that outputs JavaScript).
Last edited by Coco on 23 Jun 2016, 09:49, edited 1 time in total.
toralf
Posts: 868
Joined: 27 Apr 2014, 21:08
Location: Germany

Re: Commands vs Functions

23 Jun 2016, 09:41

When i started with AHK I had some experience with other languages. So the concept of function was known to me.
Still I liked to start off with command syntax. It really was easy to grasp.
Currently I mainly write functions. But that is due to experience with larger projects (encapsulated variables). Otherwise I could have stayed with commands.
Thus IMHO it would be great if AHK could maintain both syntax.
ciao
toralf
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: Commands vs Functions

23 Jun 2016, 11:32

lexikos wrote: Is it hard to understand that literal text should be enclosed in quote marks? If so, is it easier to understand that variables should be enclosed in percent signs?

Is the problem more fundamental, with beginners having difficulty distinguishing between literal text, numbers, variables, functions and operators? Perhaps they're just lacking proper learning materials.
^^yes!

i came to AHK after having experience in other languages, and it was not easy to understand what was going on with commands. i would say i only really grasped them after learning that i could force epxressions with %.

more and more people are learning programming daily, the world is moving towards it. might as well do it properly

or just release v2 as-is and remove Commands altogether in v3
nnnik wrote: Regarding the documentation.
Why not make a page to describe the difference between Expression and Command Syntax and then describe the Interface that's before them in each page?
i suggested something similar in the past. you could simply only show the Function/Expression syntax in the v2 docs. but early on in the v2 docs, you could have a page showing the transition between Commands and Functions, and why the latter is encouraged but the former is still supported

HotKeyIt
Posts: 2364
Joined: 29 Sep 2013, 18:35
Contact:

Re: Commands vs Functions

23 Jun 2016, 16:49

How about to have both syntax on the help pages like AHK_H currently does, e.g. StrReplace?
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: Commands vs Functions

23 Jun 2016, 21:18

HotKeyIt wrote:How about to have both syntax on the help pages like AHK_H currently does, e.g. StrReplace?
you actually only have the command syntax shown, but you have examples for both

having the function syntax also would mean something like this:
StrReplace, OutputVar, Haystack, SearchText [, ReplaceText, OutputVarCount, Limit = -1]

OutputVar := StrReplace(Haystack, SearchText [, ReplaceText, OutputVarCount, Limit = -1])
thats what lex means about the duplication

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Commands vs Functions

23 Jun 2016, 22:29

nnnik wrote:When you just downloaded AutoHotkey where are you supposed to learn them from?
Where do you learn anything from? No matter how simple it is, you have to learn the command syntax from somewhere - at least the name of the command and the order and meaning of its parameters. A new user isn't just going to download the program and immediately start writing valid code, commands or otherwise. They would most likely learn from examples, either from a script they found somewhere or from the documentation (perhaps the tutorial).

I don't think that a new user really needs to understand the symbols all that deeply; they just need to see that, for example, MsgBox("Hello, world!") shows the message Hello, world!. That can be reinforced many times over by other examples.

I don't think the current documentation for v1 or v2 does the best job of introducing either syntax to new users, but I haven't had the motivation or inspiration to attempt to improve on it.
The help file won't deliver any good results when searching for ".
I imagine one would only search for " (if ever) while looking at a script which uses it and wondering what it's for. I find it hard to believe that anyone would actually do that - wouldn't the meaning be fairly obvious within the context of the example, especially if the user has ever read a book (in any language which uses quote marks, at least)? When to write a quote mark in the code might be less obvious, but anyone should be able to learn from the examples (if the examples were consistent).

The help file (CHM) and online documentation index (not search) allows any string - for instance, there's already an entry for :=. Perhaps all of the expression operators should be added.

The online documentation sorts the items according to string value, but the CHM keeps it in whatever order was specified in the source. For instance, "functions (defining and calling)" is intentionally placed above "Func object" in the CHM.
That also means that you need to know when to use " and when it is a number, meaning you need to know the difference between 2 types before being able to use a command.
I'm quite certain that some users don't know the difference, and they get by anyway. Specifically, I see users passing quoted literals like "0x8000" to functions that expect numbers. They can basically use quote marks for all literal values, without needing to know the difference. Even more so in v2, since in v1 quoted literals are considered strictly non-numeric in some contexts (e.g. math).
Most people (at least before starting to program) don't give the small characters any really special meaning.
If a user reads code and ignores special characters because they don't understand them, that's a problem they will need to overcome. Command syntax or no, there are plenty of "special characters" in scripts: hotkey modifiers, hotstring options, Send syntax, labels: or functions(), { blocks }...
When learning AutoHotkey you can slowly progress from static content - that you can create with almost no background info - to completely dynamic OOP code.
I think that's one area that the current documentation could use improvement. For instance, by introducing syntax by skill level, instead of just in one big table ordered by operator precedence.
Why not make a page to describe the difference between Expression and Command Syntax and then describe the Interface that's before them in each page?
Sounds good. Why haven't you done it yet? ;) I suppose it would be useful for v1 regardless of how v2 develops.
just me
Posts: 9406
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Commands vs Functions

24 Jun 2016, 05:05

IMO, the mix of the two syntaxes is the most important "common source of confusion" in AHK. Commands might be easier to understand for new users without programming knowledge. But what will they imagine reading terms like 'can-be-an-expression' or 'force-an-expression'? Also, errors like MyVar := MyFunc(%AnotherVar%) are legion when they try to use functions later.
lexikos wrote:Given that even assignments and if-statements in v2-alpha require some knowledge of expressions (i.e. use quote marks, not percent signs), ...?
So what remains if you don't understand the expression syntax?
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Commands vs Functions

24 Jun 2016, 06:43

just me wrote:IMO, the mix of the two syntaxes is the most important "common source of confusion" in AHK. Commands might be easier to understand for new users without programming knowledge. But what will they imagine reading terms like 'can-be-an-expression' or 'force-an-expression'? Also, errors like MyVar := MyFunc(%AnotherVar%) are legion when they try to use functions later.
Those are issues of the current documentation not the way the program works.
Also a little confusion is bound to happen when they change syntaxes. However that could be addressed by adjusting the help file.
Due to the impression that it is easy to learn a lot of people choose AutoHotkey.
Without new people choosing AutoHotkey the language will just slowly die.
I'm not going to say that this will automatically happen if we remove commands in fact the opposite could happen.
But IMO making it easier to learn takes precedence over reducing said confusion.
Recommends AHK Studio
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Commands vs Functions

24 Jun 2016, 07:51

lexikos wrote:
The help file won't deliver any good results when searching for ".
I imagine one would only search for " (if ever) while looking at a script which uses it and wondering what it's for. I find it hard to believe that anyone would actually do that - wouldn't the meaning be fairly obvious within the context of the example, especially if the user has ever read a book (in any language which uses quote marks, at least)? When to write a quote mark in the code might be less obvious, but anyone should be able to learn from the examples (if the examples were consistent).
I used the search :headwall:
Also it's not like I didn't understand that this is text. I think I encountered an escaped quote mark.
lexikos wrote:
Most people (at least before starting to program) don't give the small characters any really special meaning.
If a user reads code and ignores special characters because they don't understand them, that's a problem they will need to overcome. Command syntax or no, there are plenty of "special characters" in scripts: hotkey modifiers, hotstring options, Send syntax, labels: or functions(), { blocks }...
Let me fix what I said here. When you are new to programming you will often read over small characters like dots or quotation marks.
While programming you will slowly start to get skilled in finding these and not reading over these in codes from other people.
The static command syntax only uses , to seperate it's parameters. All other special characters either have a very special place that is often followed by a new line.
The dynamic command syntax then introduces the multiple uses of % and with it expressions.
Expressions bring all kinds of special characters that are easy to miss. And in the case of the ternary these little characters might even take effect on the execution order.
Having both syntaxes allows the user to slowly grow accustomed to paying attention towards little characters especially when having the middle step of Msgbox Static Text %Dynamic_Text%.
lexikos wrote:
nnnik wrote:When you just downloaded AutoHotkey where are you supposed to learn them from?
Where do you learn anything from? No matter how simple it is, you have to learn the command syntax from somewhere - at least the name of the command and the order and meaning of its parameters. A new user isn't just going to download the program and immediately start writing valid code, commands or otherwise. They would most likely learn from examples, either from a script they found somewhere or from the documentation (perhaps the tutorial).

I don't think that a new user really needs to understand the symbols all that deeply; they just need to see that, for example, MsgBox("Hello, world!") shows the message Hello, world!. That can be reinforced many times over by other examples.
That is only if adequate examples are present.
I think that you can still understand a lot about the syntax of the commands by looking at whatever example available. From that point on you can try to recreate it...
I think it is a lot easier to learn about commands from almost any example than about expression syntax.
I think that it might be possible to fully learn the command syntax without ever having to touch the documentation just from examples.
I think that the same thing is impossible for the expression syntax without proper examples.
lexikos wrote:I think that's one area that the current documentation could use improvement. For instance, by introducing syntax by skill level, instead of just in one big table ordered by operator precedence.
It might be a good time for an complete overhaul of AutoHotkeys documentation - at least if we get enough people to help with that.
lexikos wrote:
nnnik wrote:Why not make a page to describe the difference between Expression and Command Syntax and then describe the Interface that's before them in each page?
Sounds good. Why haven't you done it yet? ;) I suppose it would be useful for v1 regardless of how v2 develops.
May be I didn't express myself properly here.
That's an solution to fix the issue of having to describe each and every command/function in both syntaxes. How exactly would that help v1?
Recommends AHK Studio
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Commands vs Functions

24 Jun 2016, 11:44

All I can say is... When I first start using AutoHotkey, I was confused as to what I was supposed to use not necessarily which was better in terms of syntax uniformity.
I thought to myself are commands slower or faster? (In v1.1) The most annoying problem was to choose the StringReplace command instead of using the RegExReplace() function because I did not need the complexity such as RegEx could provide. Since I was mostly using Functions/Expressions instead of the Commands/%Vars% syntax, StringReplace just felt like that one (possibly not the only one of its kind) exception that bugged me the most. Then again, if I compare AHK to C, the functions provided in C LIbraries are not actually part of the syntax itself (except for a few keywords here and there). In AHK, the luxury of having many built-in functions (like in Python) becomes part of its syntax. However, I am no longer sure. Are built-in functions part of the syntax (per se)? That said, many are confused by the choice, some frustrated and others feel liberated.
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
User avatar
cyruz
Posts: 345
Joined: 30 Sep 2013, 13:31

Re: Commands vs Functions

24 Jun 2016, 15:05

Let's talk about time. Time, like the delta of time spent by a user to grasp the concept of function compared to the concept of command. It is negligible and it's only a "one time" job. Everybody willing to learn some programming will be capable of this feat. Eventually this can be helped writing a "function for dummies" article in the documentation. If newbies lose interest on AutoHotkey because of the function syntax, they will be, anyway, users not willing to do that small step required to understand functions. Why caring about them?
ABCza on the old forum.
My GitHub.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Commands vs Functions

24 Jun 2016, 18:46

cyruz wrote:Let's talk about time. Time, like the delta of time spent by a user to grasp the concept of function compared to the concept of command. It is negligible and it's only a "one time" job. Everybody willing to learn some programming will be capable of this feat. Eventually this can be helped writing a "function for dummies" article in the documentation. If newbies lose interest on AutoHotkey because of the function syntax, they will be, anyway, users not willing to do that small step required to understand functions. Why caring about them?
Because you need to check whether it is worth it or not for you.
Proving that it is worth it by making function syntax available for each and every new member is much more powerful than the claim that you are able to use it once you learned it.
A few of the most important people here within the forum started with command syntax only.
Are you saying that these people aren't worth it?
Recommends AHK Studio
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Commands vs Functions

24 Jun 2016, 18:51

nnnik wrote:Having both syntaxes allows the user to slowly grow accustomed to paying attention towards little characters especially when having the middle step of Msgbox Static Text %Dynamic_Text%.
You make a good point, but it comes at a cost; and what about the all-important hotkeys and Send, which are probably where most beginners start? They must pay attention towards little characters from the very beginning.
That is only if adequate examples are present.
Of course adequate examples would be present. If command syntax was removed, all of the examples formerly using command syntax would be using expressions. There are countless examples in the documentation, and most of them would show how to use quote marks etc.
I think it is a lot easier to learn about commands from almost any example than about expression syntax.
I don't understand. How does this apply to (for instance) my MsgBox examples?
I think that it might be possible to fully learn the command syntax without ever having to touch the documentation just from examples.
Perhaps if they pay attention towards the little characters. ;) For instance, it's easy to miss (or fail to understand) `,, `` and `%.
I think that the same thing is impossible for the expression syntax without proper examples.
I interpret this to be saying basically nothing, because the condition "without proper examples" won't be met. It's unreasonable to compare commands and expressions by assuming there will be proper examples for commands but not for expressions. A more realistic comparison would be between documentation with some of each (commands and expressions) and documentation which is focused on expressions.
That's an solution to fix the issue of having to describe each and every command/function in both syntaxes. How exactly would that help v1?
In the same way that it helps v2!

The differences between command syntax and expressions are just as important in v1 as in v2, if not more so because users are forced to use both. The page only has use if it explains something that the reader doesn't already know, and if they need to know it, it doesn't matter why.

To be clear, I'm talking about "describe the difference between Expression and Command Syntax" in general, but I suppose that in v2 it would also be important to describe how one translates to the other for any given function. However, I don't think that would solve the problem fully; at minimum, each function page needs to indicate both what it's return value is and whether it gets an OutputVar. (There are some functions which return a rarely-used value when used as a function but have no OutputVar.)
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Commands vs Functions

24 Jun 2016, 20:23

A little history. AHK started as a fork of AutoIt v2 back in the day. As far as I can make out AutoIt was designed to have similar syntax to DOS, presumably to make it easy for the language to be picked up by someone who was familiar with DOS. Thus we have command-type statements, non-quoted literals and references to environmental variables enclosed by % signs; all very familiar to someone who has used DOS.

Meanwhile AHK v1 and 1.1 has moved on with its development. We now have expressions, functions (both built in and user defined), objects, and OOP (for those who can understand the documentation), all of which uses a new, different syntax. But, to preserve backwards compatibility, AHK still provides for the old statement (or traditional) syntax.

I believe that AHK v2 should move on from the past and finally make a complete break from the old statement syntax. New users currently are most unlikely to have had prior DOS experience, therefore keeping the old syntax is just confusing for these users.

However, it is still necessary to provide a means of double-dereferencing (which currently can be done using %s), and the v2 scheme of inserting variables into literals by means of enclosing the variable name in %s should still be provided for.
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
User avatar
boiler
Posts: 16705
Joined: 21 Dec 2014, 02:44

Re: Commands vs Functions

29 Jun 2016, 07:48

It seems I'm a few days late to this thread, but I want to state my opinion that v2 should take the opportunity to make a clean break from command syntax. I think it comes down to two areas:

Ease of use/elimination of frustration
As opposed to making the language easy for beginners to use, I really believe that command syntax (and especially the command/expression duality) is the major cause of frustration for users with no programming experience and those with experience with other languages. Having choice/flexibility is not necessarily a positive. When learning a language, the rigid syntax rules and the resulting error messages when violating those rules help one to quickly learn its proper use. AHK's flexibility can lead to many unidentified/undetected errors that can make both learning the syntax and debugging code very difficult. When your code runs without errors but it doesn't do what you expect because your intended expression-type parameters were happily accepted by AHK as command syntax (but not being interpreted as intended), it can make it very had to find where your code went wrong and why. We see examples of this in the Ask for Help forum every day.

I have used several languages as varied as BASIC, Pascal, FORTRAN, C, and it always seemed easy to learn and move between them. Just learn the syntax and you're off and running; programming is programming. AHK was a different experience. Although it is clearly easy to start using, once you get beyond the absolute basics, you quickly run into command vs. expression syntax and when to use one or the other and when and how to force the use of expression syntax. All this for the benefit of not having to use " characters for literal strings in command syntax? I can't even see how this can even be considered a positive other than backward compatibility.

Would it really be harder for beginners to grasp MsgBox("Hello " Name) and MsgBox(x*2+1) as opposed to MsgBox, Hello %Name% and MsgBox, % x*2+1? Surely the first pair is more intuitive and easier to remember (and understand why) than the latter pair, especially if that's how every example was shown (as opposed to examples of both command and syntax approaches and esoteric discussions on when to use which).

Popularity/growth of the language
I disagree with the notion that the current command syntax has helped draw new people to the language because of its ease of use. It is easy to get started using, but lack of " characters isn't the reason why. Do we really think that if " characters were required, a beginner would find it harder to use, especially when every example would include " characters when a literal string is used?

I have heard several experienced programmers say they avoid learning and using AHK because of its reputation for quirky/frustrating syntax. Clinging to this history could prevent v2 from finally being accepted as a "real" language and experiencing significant growth. These same experienced programmers who avoid learning the language still recognize its value in being able to quickly develop scripts/apps for Windows-related tasks, but they gladly leave it to others who have chosen to take on that quirky language rather than learn it themselves. The fewer reasons that prevent others from learning and using a language, the more popular that language will become.

Overall, I think clinging to the history of the command syntax would be a huge mistake and is throwing away a great opportunity to move smartly forward.
User avatar
mviens
Posts: 43
Joined: 08 Jan 2014, 19:04

Re: Commands vs Functions

08 Jul 2016, 17:25

My quick thoughts are... Since the first time I used AHK, I have hated the Command syntax. I have created function wrappers for most of the commands I wanted to use. I agree completely that needing to know the "little symbols" is more complicated for new users. For those of you who enjoyed it, great. I have been writing code since 1982, and have never been confused by the function syntax.

I agree with TAC109 that the Command syntax should be abandoned in v2.
Mike V.
User avatar
Blackholyman
Posts: 1293
Joined: 29 Sep 2013, 22:57
Location: Denmark
Contact:

Re: Commands vs Functions

14 Jul 2016, 04:06

My take on command syntax vs expressions.

Terminology:
Lexikos wrote:In any case, listing and documenting "functions" separately from "commands" doesn't make sense, so the documentation for each of the functions on the Functions.htm page will be moved; either to its own page or to a page shared with related functions.
This will be great as that is one of the places I remember re-reading multiple times when try to get the use of a build-in function right...

Problems with having two syntaxes:
Lexikos wrote:Sometimes choice is a good thing, so choice of syntax might seem like a good thing, too. Unfortunately... more...
This feels like one of the big issues letting users have that choice as it litters all the examples made by the userbase, making it difficult for new users to know what to do where and when...

Examples:

I say that after learning the expression syntax it's hard to go back and know if it's hard to learn, as AHK lets you get by for a long time ( if you wish ) without having to learn it.

The survey that was done a little time ago showed that over 50% of users found AHK from an internet search

most likely landing them on a forum post about the current issue or inquiry

I've helped enough new users to know that, most starter scripts are copied at least in part from the forum or documenting so I think it comes down to:
that If all examples and user made code snippets, used expression syntax, then new users simply learns that, as that's what is there.


Why commands anyway?

I can't truly know what is easier but did not know any other language before finding AHK and I did start by using something I copied and then modified

I found AHK in February of 2012 and within days I was using both commands and expressions ( first script I posted )

What makes commands easier to learn than expressions?

I can easily understand what makes people feel this way, command syntax does not look that new, but I'm not sure if commands are easier, because as soon as a user wish to use a variable (this comes up quickly for most), there is a true need to learn something new, aka the inclosing with %'s

The Daunting task of learning a new concept is the same no matter what needs to be learned, so needing to learn %'s around variables over "'s around strings don't seem that deferent to me.

also the survey show that:
Usage by someone that has been using AutoHotkey for less than a year

Hotkeys 71%

GUIs 38%

Text Manipulation 33%

Re-mapping of keys 32%

File manipulation / Disk management 31%

Regular expressions 29%

Manip other programs/objects w/COM 26%

Hotstrings 25%

Windows Send & Post Messages 24%

DLL calls 10%

Object oriented 7%

Registry editing 4%
hotkeys don't really fell in to one or the other for a new user

but Gui's on the other hand is command syntax, and not an easy one at that.

the rest can be done with both depending on what is being attempted...

so new users don't seem to be put of by the task (i.e. gui) being hard to do...

Commands are part of AutoHotkey's identity.

This is also one of the things that's making AutoHotkey not look and feel just like AutoIt ( for the most part the functionality and power seems almost exactly the same )

Removing the option to use commands will make the gap very small seen from the outside...
Also check out:
Courses on AutoHotkey

My Autohotkey Blog
:dance:
just me
Posts: 9406
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Commands vs Functions

14 Jul 2016, 05:04

Just to be clear in case I misinterpreted the topic:

I'm not against commands (though I don't like the idea of 'using functions as commands'). For me, 'command syntax' means 'traditional syntax' which I would like to get rid of in v2. All command options/parameters should be (treated as) expressions.

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 22 guests