Commands vs Functions

Discuss the future of the AutoHotkey language
func
Posts: 47
Joined: 20 May 2016, 20:52

Re: Commands vs Functions

24 Aug 2016, 11:36

From the original post by lexikos,
"Hypothetically, some new syntax could provide both convenience and flexibility."

This new syntax provides convenience (ease of understanding and application, and unifies everything into functions) and allows for the flexibility and power of function-syntax

If a user wants to move the mouse down 10 pixels, all they have to do is
Mouse(ry 10)
It doesn't matter what order the parameter would be in, you don't need to worry about all the other commas, where in the Command syntax the y for y offset or r for relative goes, you don't need to type or look up all that unnecessary stuff, you just pass what you need in the order that makes common sense to you in real time.
Without having to worry about order of operations, can you imagine how much simpler math would be (even though it's not possible, of course, my point is that accounting for the order of things is a burden on newbies)

How many times have you found yourself "counting commas" or using an IDE's ability to show you the command or function parameters so you can find out or make sure your parameters are in the right order?
This is what makes commands and functions "hard" to learn, along with having invisible names like MouseMove,100,200
We all know x comes first then y, but when you're brand new, you don't, you learn it through repetition. The first time you use it, you don't know if it matters that you can't specify y first then x, you also don't see the x and y, just numbers, so you aren't reinforcing the x,y coordinate offset behavior each time you read MouseMove commands (as a newbie), you're reinforcing that MouseMove commands are 'mysterious magical things' that take symbols (numbers) and apply it to the "mouse", rather than the x and y plane on the screen.
User avatar
tank
Posts: 3122
Joined: 28 Sep 2013, 22:15
Location: CarrolltonTX
Contact:

Re: Commands vs Functions

24 Aug 2016, 17:05

how many times have i had to go back to the help file to look up the existing parameter labels y yn ys section, god damnit i understand how we got there but its fucking difficult to keep track of all of them. Flexibility like what your referring to just adds to sloppiness. Yes Named parameters solve this problem but as nnikkk suggested that to creates vomit cancer. commands with a gagillion parameters need some sort of overhaul.
By the way what does ry stand for?
If you think parameter indicators cor commands are fun then ask yourself why more people dont learn unix commands. you know for things they dont want to actually have to learn how to do. Try to remember, a great deal of our user base doesnt want to have to remember much if anything. whatever the syntax it should have more in common with sql than named params. move down 10 pixels is far more clear than mouse (ry 10). but only if your an English speaker. This community is global. this is an indication more for conforming to syntax styles by other popular newb friendly languages.
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter
func
Posts: 47
Joined: 20 May 2016, 20:52

Re: Commands vs Functions

24 Aug 2016, 17:31

- ry, r stands for relative, y stands for y-coordinate. More thought for the naming should be put into these parameter prefixes when actually implemented, you are on to something that "ry" is too abstract, it would have to become something like MouseMove(offset y 10). Mouse() handling clicks and mousemoves is probably combining too much into one function. There should probably instead be MouseMove() and MouseButton() as seperate functions.

- It's only hard to remember something when it's abstract, like a phone number, or not very useful. You can remember long parameter names like "LeftButton" because they represent something your brain can associate with something useful. A phone number vs an idiom is a perfect example of this, the phone number is a useless group of symbols that is hard to remember, a famous idiom like "birds of a feather flock together" is naturally easy to remember. ry and ys etc are just as useless as digits unless you know what they symbolize, since such a short string is not very distinct, and is hard to search google/the documentation for, it's not a good implementation to use those short names in that case. In a code editor with code-completion ability, all you would have to remember is to start typing "Left" to find "LeftButton", and then the memory clicks, you don't need perfect recall of if it was "LeftMouseButton" or "LeftButton" or "LeftMB", you just need to get it approximate.

- When programming, you spend far more time reading code, others and your own, documentation, etc. than you ever do writing code. The more self-documenting code is, the more readable it is. That doesn't mean lots of comments everywhere, it should be explanatory and compact. The only way to do this is some sort of meaningful functions & parameters hybrid. Every function and parameter should explain what it's doing, or if there is only one parameter for a function, the function name should explain what is going on such as in the case of abs(). All you have to remember is that abs is short for absolute value, which is a lot easier to do than to remember that 294() means absolute value, or some other non-contextual name. Similarly, it's a lot easier to remember an aptly named "ParamName" than it is to remember "The parameter after the third comma is for X thing" because the "ParamName" explains what it's for AND removes having to remember the order of parameters. I'd argue that the most powerful language to write in is Lisp, yet it is considered hard by a lot of people, and even ugly by many lispers, because the quantity of parentheses and expression syntax (+ 1 2) instead of (1 +2) make it hard to read. Readability is far more important for learning a language than writing-ease. If you can't read Esperanto/Lisp/any other language, it doesn't matter how good the grammar & alphabet are, or how short the words are, or how you can express powerful complex ideas in a short time, it's useless to you because there is a barrier of "it's confusing".

- More words should not automatically mean the syntax is going to make things worse, as long as those words aid in reading the code for you and others, and it is no longer than it has to be to convey the idea so that they can read it without a heavy burden of memorization; asking a user to memorize "ry" means "relative y-coord" is twice as hard as asking them to memorize "offset y" means "offset y-coordinate", half of the latter is self-explanatory, and the final half in "offset y" is mostly explained by the context of "offset" prefixing "y".

- The idea that english words help only English readers understand how to code in AHK is a little ridiculous, since English is built into the language already. For example it's harder for a non-english speaker to understand the Gui command means Graphical User Interface (which helps you remember that when you want a Graphical User Interface, you should look up "Gui" in the docs). Whatever "Graphical User Interface" translates to in other languages, there is no AHK command abbreviated for that (google translate turns Graphical User Interface into Графический интерфейс пользователя for russian, which I guess would be abbreviated Гип, so there is a clear English bias already. It's true that if we turned this into Calculus, or just 1's and 0's like the computer reads, the language would be much more global, that achieves equal user friendliness across most languages, but the user friendliness is close to 0 for everybody. A code editor could auto-translate parameter names into Russian, then back into English at run/compile time, to accommodate foreign language users, to actually make the language easier for them rather than to handicap everybody just to keep things equal.
User avatar
tank
Posts: 3122
Joined: 28 Sep 2013, 22:15
Location: CarrolltonTX
Contact:

Re: Commands vs Functions

24 Aug 2016, 20:14

your missing my point i think
AHK was founded on the principle of being not for code writers and that people dont need to spend any much time looking at or reading code to understand it.
Fundimentally i think we agree on what would aid a good scripting language. but that doesnt necesarily have good implications for AHK's base user
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Commands vs Functions

24 Aug 2016, 21:28

guest3456 wrote:But this thread is not about changing the existing function syntax.
Exactly; this is off-topic.
func wrote:The newbie's brain simply does all the work as it currently is in translating, when reading or writing this code, even though both "up" and "right" are "directions", the newbie has to keep track mentally that one is an up/down behavior of the mouse button, and one is which mouse button they are talking about.
Firstly you need to know what the function does. Once you know that, it's pretty obvious that "up" and "right" are talking about different things. If not, simply renaming "right" to "rbutton" (as it is named for hotkeys/send) would void your point without drastically changing the syntax.
The way it is now, you have to either memorize the parameters for functions and what they signify
With your proposal, one would need to memorize that and the exact spelling of the parameter. I expect that latter part will be a problem for many people, unless it's limited to simple letters (as with the current Gui options and similar).
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Commands vs Functions

25 Aug 2016, 01:58

tank wrote:AHK was founded on the principle of being not for code writers and that people dont need to spend any much time looking at or reading code to understand it.
I've read this or similar statements so many times in so many discussions and still I think it's rather impossible to use any kind of scripting/programming language without fundamental programming knowledge a basic understanding of general programming terms and logic respectively the intention to learn and also to read the documentation. It may have been a good argument at times when the AutoIt development started. Obviously, AutoIt has changed and they still have a larger user base for a reason. To address the "not code writers" permanently, AHK would need to be a kind of "macro recorder" in first place.

Edit: Wording.
Last edited by just me on 26 Aug 2016, 03:00, edited 1 time in total.
User avatar
Xeo786
Posts: 759
Joined: 09 Nov 2015, 02:43
Location: Karachi, Pakistan

Re: Commands vs Functions

25 Aug 2016, 03:43

just me wrote:
tank wrote:AHK was founded on the principle of being not for code writers and that people dont need to spend any much time looking at or reading code to understand it.
I've read this or similar statements so many times in so many discussions and still I think it's rather impossible to use any kind of scripting/programming language without fundamental programming knowledge respectively the intention to learn and also to read the documentation. It may have been a good argument at times when the AutoIt development started. Obviously, AutoIt has changed and they still have a larger user base for a reason. To address the "not code writers" permanently, AHK would need to be a kind of "macro recorder" in first place.
But I think its possible, I have no knowledge of fundamental programming, :wave: and I am using Com Object with excel, web and AHK many features, you just need an idea where and how to utilized AHK. I think I am using AHK in weird way :mrgreen: after long time , i.e. I have written ahk code into excel workbook and using AHK to save as that workbook into ahk and run recently saved script.
"When there is no gravity, there is absolute vacuum and light travel with no time" -Game changer theory
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Commands vs Functions

25 Aug 2016, 04:22

Xeo786 wrote:... I have no knowledge of fundamental programming, :wave: and I am using Com Object with excel ...
It must be hereditary, then. ;)
User avatar
tank
Posts: 3122
Joined: 28 Sep 2013, 22:15
Location: CarrolltonTX
Contact:

Re: Commands vs Functions

25 Aug 2016, 05:51

@just me
While i do understand your statement, maybe even agree. When we refer to many of these command structures, we are appealing almost entirely to the previously described user base. we are not suggesting limitations on the rest of the language. we are refering to users that are so 12 years ago today. the gamers and script kiddies and office users looking to add a few shortcuts. Time and needs will force them to learn later to use more advanced capabilities. but at first it must appeal to that crown that doesnt need or want to understand
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter
User avatar
Xeo786
Posts: 759
Joined: 09 Nov 2015, 02:43
Location: Karachi, Pakistan

Re: Commands vs Functions

25 Aug 2016, 08:52

just me wrote:
Xeo786 wrote:... I have no knowledge of fundamental programming, :wave: and I am using Com Object with excel ...
It must be hereditary, then. ;)
still you are wrong :eh: . My father don't even know computer, mmm :D if I make him understand code he will get understand very quickly coz he is fine tailor 8-)
My forefathers might be good mathematician, that may be why, I understand codes easily ;) . if ability to do Math is fundamental of coding then yes I inherit and "it must be hereditary" :superhappy:
"When there is no gravity, there is absolute vacuum and light travel with no time" -Game changer theory
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Commands vs Functions

25 Aug 2016, 10:23

Xeo786 wrote:... if ability to do Math is fundamental of coding ...
It's a rather good prerequisite. Both need some logic. ;)

Probably my (English) wording is wrong again. Would "... without a basic understanding of general programming terms and logic ..." be more clear?

BTW: I'm a trained programmer (even though not on Windows machines and mainstream languages), but still having my problems with COM! So kudos to you! :)
tank wrote:... we are refering to users that are so 12 years ago today. the gamers and script kiddies and office users looking to add a few shortcuts.
Looking at the "Ask For Help" (and also other sections) it doesn't seem to be that easy for them to accomplish it, even if they use the "easy to learn" traditional command syntax. If they would only find examples using expression syntax, they would use them without complaining. Additionally they would have less proplems when starting to go one step further. But as long as most of the examples for simple tasks found by new users in the web are written in 'traditional command syntax', they'll just take them as they are. And as long as AHK supports the 'traditional command syntax', this won't change. And the conclusion will be: New users need/like this syntax.

(I think we are going in circles.)
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Commands vs Functions

25 Aug 2016, 14:59

just me wrote: If they would only find examples using expression syntax, they would use them without complaining. Additionally they would have less proplems when starting to go one step further. But as long as most of the examples for simple tasks found by new users in the web are written in 'traditional command syntax', they'll just take them as they are. And as long as AHK supports the 'traditional command syntax', this won't change. And the conclusion will be: New users need/like this syntax.
+1000000

as i've said before, you can have some early docs "getting started" or "v2 whats new" pages, which onboard the users. one page explaining the difference in syntax, with a big note somewhere on there, "while v2 can still supports the old syntax in some areas, its use is strongly discourged, and all examples in the manual will be using the new syntax"

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

Re: Commands vs Functions

25 Aug 2016, 18:27

Xeo786 wrote:I have no knowledge of fundamental programming, :wave: and I am using Com Object with excel, web [...]
On the surface, your post looks like it is supporting the view that AutoHotkey v1 is good for non-programmers. However, this topic is about commands vs functions. To use COM objects you must be using functions/expressions - the command syntax doesn't deal with COM objects at all in v1. So in other words, you've shown that the argument that command syntax is better for beginners doesn't really hold any weight, at least for users like you.
func
Posts: 47
Joined: 20 May 2016, 20:52

Re: Commands vs Functions

25 Aug 2016, 18:58

if you really want new users to understand easier,
then teach them better (better documentation),
to help teach them better (more concise documentation),
don't try to teach them two things (commands and functions)
just teach them one or the other,
since you can't remove functions without destroying the language,
remove commands (make them functions).

then, spend twice as much effort making clear instructions on how to use functions, with good examples, since they are now the whole enchilada

what a newbie has to learn with commands and functions:
command syntax & percent signing variables a.k.a non-expression syntax
function syntax & expression syntax

what a newbie has to learn with functions only:
function syntax & expression syntax

it should be obvious the second way is easier, if those two things are taught clearly, concisely, etc, because it requires 2x less learning


AFAIK newbies dont even have to learn expression syntax
if you made MouseMove() into a function, they could just do MouseMove(100,200) without using expressions like MouseMove(50+50,100+100)

They could use expressions without learning expressions.. aka use "simple expressions", then later learn how to use their power

It would be even simpler since variables dont need the % signs
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Commands vs Functions

25 Aug 2016, 23:43

We don't teach them 2 things at once.
1st we teach them the easy Command Syntax.
It is easy for several reasons we don't understand and the ones mentioned in this thread. Then if they ever need to they can understand more. The next step would be to learn about variables and %-sign Syntax. And so on...
Recommends AHK Studio
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Commands vs Functions

26 Aug 2016, 03:43

New users won't be able to do more than simple key-binding without learning at least a subset of expressions, because assignments and if-statements both require expressions.

I don't buy this "it is easy (to learn) but we don't understand why". Any decision that I may make based on how easily the language (even just the essentials) can be learned will not be in favour of keeping command syntax, unless someone can convince me that it really is (and that will require explaining how).
iseahound
Posts: 1434
Joined: 13 Aug 2016, 21:04
Contact:

Re: Commands vs Functions

28 Aug 2016, 02:33

Honestly, learning in AutoHotKey isn't really done by digging through the documentation, it's by copy pasting existing scripts and double-clicking them. Most people start by modifying others' scripts and the most accessible of them include hotkeys and commands.

While commands are limited, that shouldn't be thought of as a hindrance because 1) all commands are AHK-defined, so a new user would not have to differentiate between user defined functions and system functions. In fact, I would say that new users expect that the command/function they are trying to make work is defined by AHK. 2) they're easy to modify. People from non programming backgrounds always forget quotes and stuff so it's more natural. Until they start using variables and they have to deal with % syntax. It's a nice stepping stone though. 3) commands feel absolute. I can't imagine having to write Sleep(), ExitApp(), or Send(). These aren't the best examples, but they do provide a contrast between the "simpler" commands and more difficult functions.

Of course this is all rather subjective, so it's rather important that users are able to make their own choices. From my perspective, commands are nice, if commands make no sense, and for more customized actions with object inputs and nested functions, functions are the way to go.

It's probably best to emphasize the constraints of commands, they're descriptive and difficult to write, but the new users aren't completely writing their own scripts from nothing, they have by example what fields go into which command in what order. And of course if they do decide to look up the documentation they will find the relevant page. Contrast that with functions which may or may not be documented or might be separated in an #include file, etc.

And just a bit of philosophy: it took me a while to understand that freedom and creativity are actually inversely related to each other, having more freedom stifles creativity, whereas being constrained shows the user the available actions, such that if they wish to do more, they have to make that jump to function syntax. That's not to say it's zero-sum, freedom and creativity go hand in hand when the user realizes their own capabilities and limitations.
func
Posts: 47
Joined: 20 May 2016, 20:52

Re: Commands vs Functions

28 Aug 2016, 03:28

As an AHK newbie with no previous programming experience myself at one point, what you said is true, except the examples I used were from the documentation. User made examples were habitually messy and too confusing to even learn from, although I did use them to see what possible and explore.

Sleep(10) is more unnatural than Sleep 10, it contains more unfamiliar contextual symbols (whitespace is familiar), but having both functions and commands and needing to use both of them to do anything meaningful in AHK makes putting it all together harder

If all functions could be made into a simple command syntax, without severely breaking the power of AHK, then it would be the way to go. But we can't, so functions even though they are more obscure at first, lead to an easier understanding of the language.

As for user functions vs AHK functions, I agree there needs to be a way to tell the difference. I think in 2016 everyone using AHK even semi occasionally should have an AHK editor with syntax coloring which would show this, but if that is unacceptable, just prefix system functions with A_, such as A_Sleep() in v2

again, simple IDE functionality to differentiate it would be much better IMO..
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Commands vs Functions

28 Aug 2016, 05:13

I know it's not a vote, but I think commands are a nice feature of AHK.
lexikos wrote: 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?
[...]
But what exactly is AutoHotkey's identity, and does that benefit its users?
What is easy to learn is of course subjective.
I think commands looks more like real scentences, hence they are easy to read, and write, and, I guess, are much more inviting towards the non-programmer, stumbling over AHK via a google search. I believe this is the reason that we have posts like this in the ask for help section:
Fictional AHK-forum member wrote: I know nothing about ahk or programming, I want to make this really elaborate program, this is what I have so far:
...
Instead of only these types of questions,
Fictional C-forum member wrote: I'm new to programming and trying to calculate the sum 1+2+,...,+100 what is wrong with my loop?
...
In my opininion, this defines at least part of AHK's identity.
OT:
Spoiler
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Commands vs Functions

28 Aug 2016, 07:09

iseahound wrote: While commands are limited, that shouldn't be thought of as a hindrance because 1) all commands are AHK-defined, so a new user would not have to differentiate between user defined functions and system functions.
func wrote: If all functions could be made into a simple command syntax, without severely breaking the power of AHK, then it would be the way to go. But we can't...
what are you two talking about? have you even used v2?

all functions and all commands are now interchangable, both ways, which is the exact reason for this thread..

this is working AHK v2 code:

Code: Select all

HelloWorldMsg, Jack, Jill
return


HelloWorldMsg(one, two)
{
   MsgBox("Hello World from %one% and %two%")
}


Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 42 guests