Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

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

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

09 May 2019, 18:37

I disagree with the points of view that any part of v1 is easier or less confusing. v2 requires learning a few trivial things earlier on (like how to quote strings), but in the process removes so many points of confusion that v1 retains.

Label, Gosub, Return are easier to understand and use than functions, [...]
That is frankly absurd.

Labels are more verbose and more error-prone. Gosub is the same as a function call. Labels are the same as function definitions, except that their bounds are not clearly defined and they are effectively always assume-global. Users often fail to return at the appropriate point, or misuse Gosub as a form of Goto.

If you have some problem with the concept or use of local variables, get help or use assume-global.

More importantly, it sounds like parties on both sides of the debate believe that labels have been taken away, or will be. I have no intention of removing labels in v2.0.

I don't clearly recall my reason for changing SetTimer, Menu, OnX, etc. to not accept labels; it probably related to local labels. The ability to call a label inside a function from outside and refer to local variables while that function is not running (or while a different instance of that function was running) was strange and error-prone. Nested functions are not subject to the same problems.

Assuming I don't restore the capability for SetTimer etc. to call global labels, you can work around it with a simple helper function:

Code: Select all

SetTimer Label("There"), -1
return

There:
MsgBox A_ThisLabel
return

Label(n) {
    LabelCall() {
        gosub(n)
    }
    return Func("LabelCall")
}
Label(n) => () => gosub(n) doesn't work because gosub is a control flow statement, not a function.


You don't need to fully understand classes, OOP concepts or objects to use objects, any more than you need to understand the syntax of every single command to use just one command. You can just memorize the syntax for a given task; except that it's near impossible to completely memorize the awkward Gui command syntax. Breaking things down into simpler, more common patterns makes the whole easier to learn.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 May 2019, 04:36

lexikos wrote:
09 May 2019, 18:37
More importantly, it sounds like parties on both sides of the debate believe that labels have been taken away, or will be. I have no intention of removing labels in v2.0.
Lexikos, thanks for taking this under consideration. It's great that labels can stay. The debate went a bit wider, to include g-labels and hotkey labels. The fear was the entire construct of labels were going to be removed, to include g-labels and hotkey labels, for only function calls.

In AHK v2, it appears that g-labels are gone. The AHK v1 g-labels are simple to use, when the person knows what the letter g stands for, and easily connects to the concept of using labels.

That an AHK v2 GUI syntax would call only functions, and not a label, is what set off the debate. If labels will stay, didn't see why they couldn't be accessed from a GUI control (like say a button) in a direct manner. Though the helper function for labels in AHK v2 is great, it would appear not something normally used. Like it kind of defeats the purpose to have labels, if only accessible through a helper function where they have to be "turned on". Something I doubt many users of AHK v2 would be aware of.
Label, Gosub, Return are easier to understand and use than functions, [...]
lexikos wrote:That is frankly absurd.
It's not that simple or parameterless functions are so much harder to understand than labels, it's more about what comes along with functions (classes, methods, objects, etc...). Labels, when understood, are often all the user needs to create programs to do various simple tasks. The concept of labels, g-labels, and hotkey labels are similar and once understood create a kind of "bubble" for doing simple tasks. Usually there is no need to go into functions, methods, classes, objects, or OOP-ish concepts. They can enjoy programming in that "label concept bubble" and be happy, until they seek to come out of it. Many AutoHotkey scripts from the old forums and Google search show this.

In briefly explaining AutoHotkey to non-programmer friends and associates (to help them or start them on their way), they often find all the nerd programming gobbledygook overwhelming enough. Imagine talking to a secretary about AutoHotkey, and briefly showing how it can make things a bit easier for her, in just 1 hour. Hotkey labels and labels are an easy sell. If we go down the path of objects, arrays, classes... There will just be blank looks. It's just too heavy to take in all at once, or arguably for the week(s). Spending time or going to school for in depth programming knowledge, for adults with day jobs that have no background in programming or IT, isn't something they would usually be interested in unless they are highly motivated and can get obvious benefits.

So keeping it simple in an introduction is best, while giving some core usefulness, and the concept of labels allows for that. If they become more motivated and curious, they can then go out of this "label concept bubble". Which appears to be somewhere around when they need to do advanced things with arrays or COM. That of course brings up the debate of pseudo arrays vs real arrays and objects, but often if they progressed to that point, they have been digging their heads into the AutoHotkey help files, blogs, YouTube videos, or got on a forum (like here or Reddit).
lexikos wrote:You can just memorize the syntax for a given task; except that it's near impossible to completely memorize the awkward Gui command syntax.
AHK v1 GUI syntax might not be so awkward to a lot of people, because of tools like AutoGUI and SmartGUI Creator. This bypasses issues with coding GUIs by hand. In that context, the user just drags and drops to create the GUI. So after having the GUI created, they are just adding code for what the controls will do. Thus g-labels are very easy to use. Users can/are simply assigning actions to labels. And will usually be familiar with the concept from hotkey labels, in terms of assigning something to do an action.

The issues of namespace pollution and local vs global variables, is arguably something more for advanced and formally trained programmers. Of course any level of programmer must track use of variables, but using global is less of a concern for smaller scripts and projects. As a person becomes more advanced in programming or are creating programs for wide spread use or distribution, they will be likely learning and using the more advanced features of AutoHotkey and will have a greater understanding of programming in general, so then would concern themselves with such.

Note- edited for small spelling and grammatical mistakes.
Last edited by SOTE on 10 May 2019, 07:39, edited 2 times in total.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 May 2019, 06:29

I think Id have less issues explaining someone the new v2 GUI syntax in under an hour than the old ones.
Im also not fully present on the forum and assumed that I missed some progression regarding the removal of labels when I read the posts here.
To be frank I dont see why you want to keep them - I also dont see why they would be the effort to maintain.
The only reason I could see they would be worth the effort to actively remove them is cleaning up - which I thought was the point of v2.

I see - I thought that labels were already removed from these commands. It doesnt make sense to keep them around since they limit the possibilities and clutter the possible syntaxes of these functions.
I dont understand at all why youd want to keep that syntax in the first place.
Its good since the newbie tutorials now dont have to lead ew users into the label dead end before going into AHK itself.
Recommends AHK Studio
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 May 2019, 08:11

Frosti wrote:
09 May 2019, 13:04
Now I agree with SOTE. Don't throw labels away! Don't open new gates and close others. I would love to have a language of freedom. I'm a bit afraid about the rising object syntax in AHK. I haven't the time, knowledge and experience to plan what is needed. I react on daily needs and want to write something at now in one or two hours. It's no good idea to study a whole book if you only want to build a small bird box. It's then better to buy one. Maybe this not what you talk about, but that I observe the last months.
Actually Frosti, it is what I'm talking about, and I agree with your point. "Don't open new gates and close others." I think it's fantastic that AutoHotkey provides the freedom be both an easy to use automation language, that also has advanced features for general purpose programming.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 May 2019, 10:11

nnnik wrote:
10 May 2019, 06:29
I dont understand at all why youd want to keep that syntax in the first place.
Its good since the newbie tutorials now dont have to lead ew users into the label dead end before going into AHK itself.
Why would syntax that works together conceptually, and is at the core of the very name of the language (AutoHotkey) be a dead end? Many users would be attracted to the language by using the Hotkey labels. From there, using labels and g-labels in a GUI would be extensions of that concept.

Code: Select all

Gui, Add, Button, x50 y50 w100 h100 gMyLabel, Hi
Gui, Show,  x300 y300 w200 h200 , Hello

Hotkey, ^a, MyLabel
Return

^b::
Gosub MyLabel
Return

MyLabel:
MsgBox Hello
Return
The concept would only be a "dead end", in the context of them not wanting to do simple automation, small utility, or hotkey scripts, and were looking to do general programming to create applications of significant size or for wide distribution. But to get to that point, such a person has likely invested a tremendous amount of time in studying programming, so we would not be talking about a novice or non-programmer.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 May 2019, 10:13

You need to keep in mind that you also have a function version for hotkeys.
Recommends AHK Studio
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 May 2019, 10:33

delete gosub. demote Label: to being solely the target of a goto statement(or switch if that ever makes it)

there, sanity and peace. no more "label programming". ure giving noobs too little credit - just look how many people have no trouble picking up js, python or hell even autoit - all languages primarily relying on utilizing functions.

oh and delete "command"like syntax while ure at it. I don't even know why it's being kept around tbh. for backwards compatibility with v1? familiarity? just cuz? too lazy to enclose in parens(that's my personal reason for using it but it's used with plain msgboxes exclusively and I certainly wouldn't miss it all that much if it went away, u know, "for the greater good")?
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 May 2019, 14:12

Why must AutoHotkey syntax be a copy of JavaScript, Python, AutoIt, etc...? Different languages, serving different purposes, for different audiences. I don't see anything wrong with AutoHotkey having an unique syntax identity or being different. And if it should be like any syntax, arguably it should be like WinBatch, a long used automation language that's battle tested under commercial circumstances.
gregster
Posts: 8921
Joined: 30 Sep 2013, 06:48

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 May 2019, 15:05

SOTE wrote:
10 May 2019, 14:12
And if it should be like any syntax, arguably it should be like WinBatch, a long used automation language that's battle tested under commercial circumstances.
I fail to see the connection... that would mean that every free, open-source scripting language should copy Winbatch's syntax, because it was/is commercial?!?

I remember to have used a number of commercial and non-commercial programming languages in the last decades - often they had awful syntaxes, but I didn't have another choice at the time. I really can't say that the commercial ones were necessarily better.

I don't know the reasons why Wilson WindowWare ceased operation and for how much they sold Winbatch, but even if Winbatch would be more than a niche product nowadays, this wouldn't say anything about the quality of their syntax and if it makes sense to copy it. People also buy and smoke cigarettes and companies make loads of money with it - you could say, a truly successful and battle-tested industry - but does that mean that it is generally a good idea to inhale addictive carcinogenic fumes?
I thought the idea that the qualities of a "product" can be measured reliably by market success (real and supposed) or failure would be obsolete, looking at today's state of the world... that doesn't mean that Winbatch is bad, but I see no reason to idolize it (or its syntax) just for being commercial.
lexikos
Posts: 9555
Joined: 30 Sep 2013, 04:07
Contact:

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 May 2019, 19:20

@SOTE I think your advocacy of labels relates specifically to the use of labels as subroutines. I do not understand why you believe that label-subs are easier than functions. In general terms, there are two ways to define and call a subroutine:

Code: Select all

name:  ; starting point
    body
return  ; ending point

gosub name  ; call

Code: Select all

name()
{  ; starting point
    body
}  ; ending point

name()  ; call
What's harder about the function? Okay, the author might need to be aware of scope; or not.

Code: Select all

name()
{
    global
    body
}
Using this pattern does not require any understanding of scope or local variables.

On the other hand, maybe the subroutine doesn't need access to global variables, and having automatic access can cause problems. Global namespace pollution is as much or more of a problem for beginners, who aren't aware of it, than advanced programmers. Local variables are a very basic concept.

If you forget to define the ending point of a label-sub, as beginners often do, you will not be notified, and the program will behave incorrectly. It is both less likely that you will forget the ending brace of a function and less likely that the problem will go unnoticed, as the program will alert you to mismatched braces.

Label-subs do not necessarily have a clearly-defined ending point. They end wherever execution ends. That could be inside some deeply nested function call which calls Exit or raises a runtime error. Maybe the subroutine actually never ends (loops infinitely).

Using functions in no way requires any understanding of objects, classes, methods or any other OOP feature. A function is just a subroutine that optionally accepts parameters and optionally returns a value. Functions were implemented long before objects or any OOP feature.
SOTE wrote:
10 May 2019, 04:36
In AHK v2, it appears that g-labels are gone. The AHK v1 g-labels are simple to use, when the person knows what the letter g stands for, and easily connects to the concept of using labels.
OnEvent is simple to use, when the person can read English, and easily connects to the concept of calling a function. :eh:
If labels will stay, didn't see why they couldn't be accessed from a GUI control (like say a button) in a direct manner.
Obviously, if it could be done with a helper function, it could be done in a direct manner. However, g-labels often depend on the presence of global variables for passing parameters such as which gui or control, x and y coordinates, size, the type of event, or something else relating to the event. When a subroutine needs to accept parameters, the appropriate construct to use is a function.

When I added support for functions and function objects in place of labels in v1, I had to give precedence to label names over function names for backward-compatibility. After the addition of nested functions in v2, there is now no compelling reason to recommend a label over a function. That being the case, one advantage of removing label support is that I will not need to explain my recommendation to new users.

Other drawbacks to the v1 implementation of g-labels include: The type of event is sometimes represented cryptically, as a single letter. Some events are used less often than others, so are disabled by default, requiring the use of the obscure "AltSubmit" option to enable them. "gsomething" inhibits visual distinction of the label/function name, finding it with "match whole word only", and selecting the name by double-click or similar.
... it's more about what comes along with functions (classes, methods, objects, etc...).
If a user learns how to use those things, they will be better off, but it is not necessary. One can learn by example how to write GUI code with the new API, without learning all of the details about how objects work. Classes are simply not needed (but some users find it helpful to use them, and can with the new API). If your problem is with OnEvent, the debate of labels vs. functions is tangential. After all, the g-label option also supports functions.
Labels, when understood, are often all the user needs to create programs to do various simple tasks.
If a label is all you need, you can replace it with a function and do not need to use or learn anything extra, other than local variables (or alternatively, the need for global).
AHK v1 GUI syntax might not be so awkward to a lot of people, because of tools like AutoGUI and SmartGUI Creator.
Such tools can be updated for v2. Users who aren't dealing with the syntax won't care whether it uses commands with sub-commands or objects.
Thus g-labels are very easy to use. Users can/are simply assigning actions to labels.
If the user creates a GUI via a GUI and then is only defining the event handler, how is a g-label any easier than a function? With OnEvent, there is a one-to-one connection between an event and a function. The user can select a control and event, click a button in the GUI creator, and it can generate the OnEvent call and function. All the user needs to do is write code that should execute when that event is raised.

By contrast, g-labels often require checking global variables to find out which event happened.
Why must AutoHotkey syntax be a copy of JavaScript, Python, AutoIt, etc...?
Why would you leap to the conclusion that how other languages do things is motivating these changes? AutoHotkey has expression in v1. Expressions can do everything that the legacy syntax can do, so there is no need for the legacy syntax. I reject the point of view that the legacy syntax is easier, especially since it must inevitably be mixed with expression syntax.

Other languages are often very similar because this is the right way to do it.
lexikos
Posts: 9555
Joined: 30 Sep 2013, 04:07
Contact:

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 May 2019, 19:20

nnnik wrote:
10 May 2019, 06:29
I also dont see why they would be the effort to maintain.
You should consider revising that sentence. I'm not sure what you're trying to say, but in any case, if keeping labels required a non-trivial effort, I might consider removing them.
[Labels] limit the possibilities and clutter the possible syntaxes of these functions.
How so?

swagfag wrote:
10 May 2019, 10:33
oh and delete "command"like syntax while ure at it.
"Command" syntax:
  • Uses unquoted strings with percent sign derefs.
  • Uses expressions as well, making the syntax potentially different for each parameter.
  • Contains syntax exceptions for backward-compatibility, making things even more awkward.
  • Uses an initial output variable to receive the return value, if the command has one.
  • Sometimes uses ErrorLevel as a secondary return value (because it wasn't important enough for an output variable).
So you should stop referring to function call statements as "command like". It is just the omission of parentheses.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

11 May 2019, 02:58

gregster wrote:
10 May 2019, 15:05
I fail to see the connection... that would mean that every free, open-source scripting language should copy Winbatch's syntax, because it was/is commercial?!?

I remember to have used a number of commercial and non-commercial programming languages in the last decades - often they had awful syntaxes, but I didn't have another choice at the time. I really can't say that the commercial ones were necessarily better.

I don't know the reasons why Wilson WindowWare ceased operation and for how much they sold Winbatch, but even if Winbatch would be more than a niche product nowadays, this wouldn't say anything about the quality of their syntax and if it makes sense to copy it. People also buy and smoke cigarettes and companies make loads of money with it - you could say, a truly successful and battle-tested industry - but does that mean that it is generally a good idea to inhale addictive carcinogenic fumes?
I thought the idea that the qualities of a "product" can be measured reliably by market success (real and supposed) or failure would be obsolete, looking at today's state of the world... that doesn't mean that Winbatch is bad, but I see no reason to idolize it (or its syntax) just for being commercial.
I referred to WinBatch in the context that it is an automation language, therefore more similar than not to AutoHotkey in that regards. And as a commercial product, if syntax such as Labels, Gosub, Return, etc... were really causing problems then they would be more likely to cut them from the language. Open source projects are more subject to the whims of it's developers, so that if something is debatably bad, there is usually no counter balance except forking the project. Where commercial products must often be more responsive, helpful, or useful to it's customers or suffer more direct consequences (like going completely out of business).

In your analogy, which on the surface is a good one, there is a debatable flaw. That is, cigarettes companies keep making such an addictive carcinogenic product because there is a huge demand for it by their customers. We can definitely say that it's not healthy for the body, but clearly it's satisfying for their customers, which is partially why cigarette companies remain in business. To include that responsiveness to their customers and the market is why some cigarette companies are more successful than others.

My other point was that AutoHotkey shouldn't feel obliged to copy syntax simply because other languages are doing it, particularly if those languages have different audiences and different purposes. Because something is a fad or popular at the time, doesn't always mean it's good or best.

“I invented the term object-oriented, and I can tell you I did not have C++ in mind.” and “Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to happen to computing since MS-DOS.” -- Alan Kay.

This has debatably become the case with OOP. It was all the rage in the 90s and early 2000s, but people have become more sensible and critical about it. Unfortunately, languages like Java and others had gotten so carried away with their version of OOP, that it's seen as a liability. Where say other languages like Object Pascal, were more moderate in their implementation, so don't get such complaints. I don't see anything wrong with a language going against the trend, and down it's own path, because that's more helpful or useful for it's users. And if AutoHotkey were to copy or be inspired by syntax from any other language, debatably it should be from more similar automation languages, in addition to just the usefulness or helpfulness of the syntax in general.
User avatar
Flipeador
Posts: 1204
Joined: 15 Nov 2014, 21:31
Location: Argentina
Contact:

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

12 May 2019, 22:06

I wonder what can be done with labels that can't be done with a function, I mean, I've never needed to use labels in my scripts, in fact I don't like them and I don't use them at all.
Cons of the labels:
  • They use global scope, this is very bad, you can easily overwrite other variables or classes by mistake, plus the variables used are not freed when returning.
  • You can't pass parameters or return a value. So you can't use Func, a very good functionality.
  • There is no concept of static variables (without using a global variable).
With regard to the positive: I agree with swagfag.

I agree that labels are no easier to use than functions, and in the long run they cause more problems than anything else.
With respect to the command like syntax function call without parentheses, it doesn't bother me, although it's true that things like classobj.methodnamecall (just that in a line) doesn't look good at all.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

22 May 2019, 14:33

Flipeador wrote:
12 May 2019, 22:06
I wonder what can be done with labels that can't be done with a function, I mean, I've never needed to use labels in my scripts, in fact I don't like them and I don't use them at all.
Cons of the labels:
  • They use global scope, this is very bad, you can easily overwrite other variables or classes by mistake, plus the variables used are not freed when returning.
  • You can't pass parameters or return a value. So you can't use Func, a very good functionality.
  • There is no concept of static variables (without using a global variable).
With regard to the positive: I agree with swagfag.

I agree that labels are no easier to use than functions, and in the long run they cause more problems than anything else.
With respect to the command like syntax function call without parentheses, it doesn't bother me, although it's true that things like classobj.methodnamecall (just that in a line) doesn't look good at all.
Management of variables has to be done, regardless of using labels or functions. It's not so much a matter of which is superior to the other (labels vs functions), but whether or not it's possible to support both labels and functions with the AHK v2 GUI syntax, just like they are both supported in AHK v1, and the conceptual ease of learning and using the label concept (label, g-labels, hotkey labels) for non-programmers and casual programmers. Taking away an easy to use feature in AHK v1, debatably diminishes the attractiveness of AHK v2. If you can use both (labels and functions) with the AHK v1 GUI, then arguably for many casual programmers, the benefit of switching to AHK v2 GUI is reduced.

I'm not sure that it's wise to force a "pro-function" choice in AHK v2, when both are optional (labels and functions) with the AHK v1 GUI and the user can use whichever they like.
lexikos
Posts: 9555
Joined: 30 Sep 2013, 04:07
Contact:

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

22 May 2019, 22:31

I think your argument is based on the opinion that labels are easier than functions. I believe that to be a fallacy.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

09 Jun 2019, 23:25

lexikos wrote:
22 May 2019, 22:31
I think your argument is based on the opinion that labels are easier than functions. I believe that to be a fallacy.
That labels are easier to understand might not be such a fallacy as you believe. I ask yourself and others to give this some further thought. I talked to another secretary about using AutoHotkey (who works for a friend of mine), looked into this topic again, and thought about it a bit more. When AutoHotkey is introduced or referred to on the Internet, it's not usually for general programming, but in reference to hotkey labels. People are not teaching or introducing functions in AutoHotkey, but rather are introducing labels first. Hotkey labels, using labels in general (with gosub and return), or both.

These are 3 examples that will come up almost immediately on a Google search of AutoHotkey.

AHK is easy to use: AutoHotKey file tutorial
https://youtu.be/S235EBUqfwc

AutoHotkey For Beginners
https://youtu.be/nxnfFRTAvto

How to Write an AutoHotkey Script
https://www.howtogeek.com/409581/how-to-write-an-autohotkey-script/

Consequently, many people will come to know AutoHotkey code in this fashion. Hotkey labels...

Code: Select all

^b::
MsgBox Hello
Return
This concept then easily aligns to g-labels and labels in general, where subroutines perform some action. Thus we could easily make a GUI for the above hotkey label (or any label). Where the GUI g-label of g^b would activate the hotkey label of ^b::, to do some action.

Code: Select all

Gui, Add, Button, x50 y50 w100 h100 g^b, Hi
Gui, Show,  x300 y300 w200 h200 , Hello
Return

^b::
MsgBox Hello
Return
If you talked to people from a non-programming background and go on about functions, they will usually blank out on you. I know this from experience. It's not that you can't get them to sooner or later understand functions, but often they don't quite get what you are referring to. Where the concept of labels are almost immediately understood by most people. Even if you believe that functions are as easy to understand as labels, they are not what people are usually exposed or introduced to when they first see AutoHotkey. Often they well first learn or see code dealing with labels or hotkey labels. Then from there, they might start to dig a little deeper into programming/automation, which debatably would be creating scripts with gosub, return, and labels. Think about the initial examples shown for hotkey labels (by searching the web), that usually has return included. This is the direction that I came from, and it can be seen quite a lot in the forums. Many posts from the old forums, in addition to now, follows this trend.

Understanding and using functions will probably come to most later, as the person digs more into understanding programming in general. When you see functions in the help forum, it's often by more advanced users, who have made the jump to using AutoHotkey for large scripts or general programming. Let's remember that many people won't get so deep into AutoHotkey (content for using it for simple tasks) or are using AutoHotkey as an alternative to some other more difficult or hard to use programming language.

It's also probably hard to say when people are making the jump to using functions, because they will be learning control flow and automation. Such things as the various versions of Loop, ControlClick, WinActivate, If, Else, etc... So somewhere in that mix will come the understanding of functions, arrays, objects, etc... Debatably because of doing some complex task, where they must now use more complex features. More often than not, unless they took programming in school, many non-programmers would be using labels way before using functions in AutoHotkey. In fact, labels are debatably what makes AutoHotkey easy to use and understand so quickly.

Consequently, it might be better if AHK v2 GUIs can use both labels and functions, and maintain the flexibility of AHK v1 GUIs.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 Jun 2019, 02:34

It doesn't actually matter what the current tutorials look like.
Mentioning one target group of the language is not enough - not all the people that start learning it are non-programmers.
In the end we will have to create new tutorials for v2 anyways.
You have no proof that people will be unable or have a harder time learning the language if the GUIs require function definitions.
You just assume that the biggest target group for the language will be "blanking out on you" when you talk about functions.
Recommends AHK Studio
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 Jun 2019, 06:02

Interestingly, I have not talked to any formally trained professional programmers that learned programming in college that used AutoHotkey, to include AutoIt or WinBatch. The professional programmers with degrees, often had learned C#, C++, Java, JavaScript, Python, etc... The usual suspects. Unless they were older, then I would hear things like Assembly, Visual Basic, COBOL, Pascal/Delphi, C, etc... I remember mentioning AutoIt to some programmers years ago, and they were like... "What?"

When I have met people that used AutoHotkey (including AutoIt and WinBatch), they were self-trained types, with some IT or small business related job. Like system administrators, IT sales, small business owners (wearing many hats/doing many tasks), etc... And often they were using all kinds of things for scripting, macro, or automation purposes. Batch files, PowerShell, VBA, etc..

I'm of the opinion that it's non-programmers or self-taught programmers that would be the most interested in using AutoHotkey, because it's easy to learn and put to use right away, in comparison to traditional programming languages. Probably picking it up accidentally or unexpectedly, after coming across it on the Internet or finding out that some utility they were using was written with it.

Don't get me wrong, you can definitely use AutoHotkey to build applications and do general-purpose programming, but if person has already learned a more popular language in high school or college they would probably be a bit biased or prefer the traditional programming language they were taught. I've played with Object Pascal a bit. But had it been the first programming language I learned and wrote applications in, I might have a totally different view, and possibly would be content to only or mainly use that. In the same way that if a person learned AutoHotkey/AutoIt/WinBatch first, they can be a bit biased or feel more comfortable with it.

If a person is already a formally trained C# or Java programmer, the reasons why they would need AutoHotkey/AutoIt/WinBatch would be less. And if so, likely for a specific purpose or they would use the AutoHotkey.dll or AutoItX DLL. If they know other languages, and were using AutoHotkey/AutoIt/WinBatch, I would guess that in most situations that was their 1st language and what they became comfortable with using, and then they learned other traditional programming languages later. I suppose we might need to do a poll on it, to find out if AutoHotkey was their first programming language or what their level of programming knowledge was when they started to use it.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 Jun 2019, 06:38

I see. I observed the opposite.
Most people that regularily program in AutoHotkey also can program in other languages.
AutoHotkey is mainly used to create small shortcut styled macros and larger automation.
A lot of it is done right in the moment it is needed. It excells at exactly that - and even surpasses advanced programming languages that take a long time just to set up a new project.
(No I would not start a new C/C++ project just to hold shift for the next 3 minutes)

If the rules are similar to whats already known the language will become more useable to the users.
Functions are a concept thats more commonly known to the user base of AutoHotkey - Labels are commonly disregarded, unpopular and people need to read up on them.
Reducing the amount of syntaxes by removing labels would be a viable move in my opinion - then again I dont see the harm in keeping a dead syntax.

SetTimer, Guis and similar are already advanced features imo. If you only want to create basic hotkeys you dont need them.
If you want to crearte advanced hotkeys you need to learn about functions anyways.
Recommends AHK Studio
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

10 Jun 2019, 19:06

nnnik wrote:
10 Jun 2019, 02:34
You have no proof that people will be unable or have a harder time learning the language if the GUIs require function definitions.
You just assume that the biggest target group for the language will be "blanking out on you" when you talk about functions.
In addition to the experience I've had to introducing some people to AutoHotkey that were non-programmers or talking to IT people about what they were doing, I've also taken a look at coding practices on this help forum and on other AutoHotkey forums like Reddit, stackoverflow, etc... I tend to like doing so to see how other programmers solve problems, get ideas on how to do things, etc...

This recent post on the help forum is possibly a good example of what I'm talking about. https://www.autohotkey.com/boards/viewtopic.php?f=76&t=65267

The member joined in 2015, and was unsure how to use a function correctly with their GUI. But, they could do what they wanted by using the GUI with a g-label and label. The point of view that I'm presenting on this is that:

1) People are likely to have learned to use labels first because it's easier or they were originally introduced to hotkey labels and labels.

It's not a sin that people learn functions later, particularly since AutoHotkey is usually seen or used as an automation language, before being thought of as a general-purpose language. Labels excel at simple and for automation, which is probably why they were used in WinBatch, then AutoIt, and then AutoHotkey.

2) It doesn't have to be one or the other in regards to functions, as both labels and functions can be used together.

Many people (where AutoHotkey was their 1st or only programming language) would likely call the function from within a label, versus the other way around, use functions that contain labels. This make sense in context to how they learned to use AutoHotkey, if starting with hotkey labels, labels, g-labels, and then progressing to using functions.

Of course the order in which people might have learned things in programming can be different, depending on their previous exposure to other languages. If they had learned WinBatch, the way in which AHK v1 uses labels would be readily understood. People from Visual Basic might connect how AHK uses the label to be something like how they use Sub (functions that don't return a value). Regardless, there is no "wrong" or "right" way that it must be done. Labels that contain functions, should be no less valid than functions that contain labels. If AutoHotkey goes about it differently, that can be a good thing, if it's easier for people to use and learn.

3) Not everybody uses AutoHotkey regularly or for tasks beyond automation.

While there can be professional programmers that use AutoHotkey for general-purpose programming, we should acknowledge there are many non-professionals and casuals that only use AutoHotkey for simple tasks and automation. It's great if AutoHotkey has the flexibility to accommodate both types of users, versus many popular or traditional languages that are complicated and awkward to use.

Example of the coding style from the help forum. I would say that this style and progression is more typical, than atypical.
Note- GUI of original modified so that both versions would have the same appearance.

Code: Select all

Gui Add, Edit, w200 vv1 gg1
Gui Add, Edit, w200 vv2
Gui Show
Return

g1:
gui, Submit, NoHide
GuiControl,,v2, % v1*100
return

Code: Select all

Gui Add, Edit, w200 vv1 gg1
Gui Add, Edit, w200 vv2
Gui Show
Return

g1:
gui, Submit, NoHide
fn("v2", v1)
return

fn(param1, param2) 
{
    GuiControl,,%param1%, % param2*100
}
ExitApp

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 35 guests