Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

[SOTE]

Label, Gosub, Return are easier to understand and use than functions, classes, objects, and OOP concepts. This is definitely not to say that one group should be used over another, but to say they all should be used and have their place. The concern is AHK v2 will eliminate this very convenient functionality that is present in AHK v1, by overly pushing only a certain style of programming.

I happened to have a discussion with an old friend that uses WinBatch. It so happens that AHK v1 use of Labels, Gosub, Goto, Return, Functions, and %% are pretty much aligned with how they are used in the WinBatch language as well. With %% having a long history of usage in Windows (.bat, .cmd, and environment variables). The syntax between the languages (AHK v1 and WinBatch) are not exactly the same, but usage is interestingly similar. Meaning how AHK v1 does things is a little more popular than many might know. There was also an AHK user who talked about converting his WinBatch scripts to AutoHoktey with relative ease (considering it's a different scripting language), upon further investigation, it has become much clearer why this was so. It would arguably be much more difficult to do such a conversion with AHK v2.

In looking at what seems to make AutoHotkey (to include WinBatch that also uses this syntax) easier to learn and understand, is the very use of Label, Gosub, and Return. Debatably, Visual Basic (which some also call easy to learn) could be included in this group, but the way that it uses such syntax is a bit different and more convoluted. They have the syntax Sub (something different from AutoHotkey and WinBatch) and a Label is often referring to a particular line of code or line number, not to a subroutine. Nevertheless, the way that AutoHotkey v1 and WinBatch are using the syntax makes them easier languages to immediately put to use.

This is very easy to understand, when it's explained that the g links to a Label (thus g-label)

Code: Select all

Gui, Add, Button, x3 y250 w75 h50 vHoldIt gDoIt, ClickMe

DoIt:
Do Something
Return

This is arguably not as easy to understand.

Code: Select all

main := guicreate()
main.addButton("x3 y250 w75 h50 vHoldIt", "ClickMe").OnEvent("Click", "DoIt")

main.show()
Return

DoIt(ctrl) {
    ; ... do something
    return
}

Labels also make it very easy to create subroutines that do all kinds of tasks and fit visually and conceptually with hotkeys.

Code: Select all

Gosub MyLabel

MyLabel:
Run Notepad
Return

#n::
Run Notepad
return

A Label does more than a simple function, as it can contain a large section of different kinds of code to do a task. Thus making it's more comparable to a Class, in terms of task(s) performed, than a simplistic function.

Code: Select all

Gosub MyLabel

MyLabel:
Do Lots of Stuff
ThisFunc()
ThatFunc()
MyFunc()
Return

Note- minor spelling and grammatical editing done.

[nnnik]

All things have their specific uses. Using them as a tool gives specific effects and imposes some restrictions.
They also are different on how difficult they are to create and how long they take.
This gives them specific situations they are commonly used in/prefereable - a so called niche if you will.

Labels excel for code that does not take longer than 30 seconds to write and is discarded afterwards.
Other than that they offer no particular advantage over competing elements and in fact always loose in the other niches.

On the other hand labels limit what we can do with the language simply because the syntax they consume could be taken up by something else.
They also need to be maintained which is some work. When new code elements are added they need to be made compatible with these new code elements or throw an error when something bad happens.
Labels are currently pretty incompatible with a lot of the code elements - now we have the choice to keep them for their niche or removing them.

lexikos decided to remove them and I agree with that decision.

[SOTE]

On this we will have to agree to disagree. I believe being easy to understand and easy to use is as important as adding advance features, because many who have learned and those that will decide to use AutoHotkey will be average Joes or not formally trained programmers. It's not like the vast majority of AutoHotkey users were attracted to this scripting language because they are or want to be professional programmers by trade. Looks like many were just interested in automation and simple tasks, then discovered they could do a bit more. If the syntax is a little bit wonky or funky to accommodate non-programmers and casuals, so be it. Don't see it as a bad thing. Oddly or by chance, AHK v1 has somehow managed to marry both the easy and the advanced into the same scripting language. Making itself an interesting ladder from the bottom to the top.

If AutoHotkey will put itself in the category of "just like" any other "OOP-ish" language, then why not just pick up C++, Object Pascal, Java, etc... from the jump. I mean if they are equal in difficulty with similar restrictive syntax and constructs, why not start there? To me, that's a bit sad. I don't see it as a negative, where a scripting language has a nice niche that allows both complete beginners and advanced users to make good use of it very quickly.

[jeeswg]

- I had been concerned that OnEvent could add to the difficulty, however, I did think that events needed more explicit handling versus AHK v1, and was able to think of some ways to explain it simply. Also, OnEvent is similar to OnMessage and other functions.

- Generally speaking, I think any system can be explained simply.
- If something is extra complicated, you can give an overview first, or make some statements that are essentially true (possibly slightly oversimplified, but stated as such), and then fill in the detail.
- There's normally a 'human' or practical way to approach an introduction, where the explanation is driven by 'what someone would want to do', and not 'how the system happens to work'.
- The main point is that the system should be well-designed: simple and consistent where possible, and that anything too fiddly, with too many exceptions is avoided, as this can take a long time to explain and can be difficult to remember.
- For explanation purposes, it doesn't always matter too much what the system is, as long as it's reasonably coherent/consistent.

- I've tried to simplify your example. I split the AddButton line, so that there are fewer ideas per line to understand. Also, by creating a button object, we are being more explicit, versus adding a .OnEvent to the end of the line.
- I use 'o' and 'My' prefixes to make clear what are our variables/functions, versus what's built-in.
- I use UpperCamelCase for function/method names, instead of lowerCamelCase/uglyCase, because it looks better/clearer (and is standard for built-in functionality).
- I used Allman style indentation for the function, as it's clearer, and in large/small code projects, the style results in fewer bugs.
- I added a space to turn 'ClickMe' into 'Click Me', because otherwise it looks like it may be code, rather than a message.
- In general, I try to make examples as self-explanatory as possible, and with as many clues to what's going on as possible.

Code: Select all

oGUI := GuiCreate()
oBtn := oGUI.AddButton("x3 y250 w75 h50", "Click Me")
oBtn.OnEvent("Click", "MyClickFunc")

oGUI.Show()
return

MyClickFunc(oCtl)
{
	MsgBox("hello world")
}

- Here's a version with comments:

Code: Select all

;we create a GUI object:
oGUI := GuiCreate()

;we add a Button control object to the GUI, we specify its position, size and text:
oBtn := oGUI.AddButton("x3 y250 w75 h50", "Click Me")

;we add an event handler for the Button,
;if the Button is clicked, the 'MyClickFunc' function is invoked:
oBtn.OnEvent("Click", "MyClickFunc")

;the GUI (and its controls) is made visible:
oGUI.Show()
return

;a custom function, it receives a control object for the GUI control that was clicked:
MyClickFunc(oCtl)
{
	MsgBox("hello world")
}

[Frosti]

I saw some queries on stackflow like "Is it possible to code a gui with some commands like it's possible in Autohotkey?". This feature is one famous in AHK and in V2 is given more style and logic to that. You can read it like natural language: " Add a Button and on event 'click', do what followed! Objectsyntax is described as easy to to understand, but it isn't in most time (for me). But this syntax is easy to understand! This can be seen as my point in discussion here. I like handling a gui in AHK2.

[SOTE]

- I had been concerned that OnEvent could add to the difficulty, however, I did think that events needed more explicit handling versus AHK v1, and was able to think of some ways to explain it simply. Also, OnEvent is similar to OnMessage and other functions.
- Generally speaking, I think any system can be explained simply.
- If something is extra complicated, you can give an overview first, or make some statements that are essentially true (possibly slightly oversimplified, but stated as such), and then fill in the detail.
- There's normally a 'human' or practical way to approach an introduction, where the explanation is driven by 'what someone would want to do', and not 'how the system happens to work'.
- The main point is that the system should be well-designed: simple and consistent where possible, and that anything too fiddly, with too many exceptions is avoided, as this can take a long time to explain and can be difficult to remember.
- For explanation purposes, it doesn't always matter too much what the system is, as long as it's reasonably coherent/consistent.

It's not that what you are saying isn't valid, but rather we are taking the very simple to understand and use GUI system in AHK v1 (along with simple to use Labels) and making it more complicated in AHK v2, in addition to eliminating the very flexible functionality of Labels to create subroutines for a GUI. Because supporting simplistic syntax has now become burdensome?

A Label can be loaded with many tasks, as opposed to a function. I know you are a student of programming, so here are some quotes from a well known and respected programmer.

"Functions should do one thing. They should do it well. They should do it only." -- Robert C. Martin (Uncle Bob)
"The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that." -- Robert C. Martin

When the GUI calls only functions, it will likely lead to forcing AutoHotkey users into stuffing large tasks into those functions. Instead of getting simple functions, this appears it will lead to convoluted "stuffed" functions, quasi-labels (stuffed parameterless functions), or Classes stuffed with functions (methods). I don't see how this is a better situation than just allowing for Labels, so that your functions can stay simple or you don't force kicking non-programmers and casuals down the OOP-ish slide of functions, methods, class, objects, etc... in order to accomplish a large or complicated task. Rather than allowing for simple automation tasks to be done simply, it appears we are making it more difficult.

Making this....

Code: Select all

MyClickFunc(oCtl)
{
	MsgBox("hello world")
}

Do like the pseudo code below, containing a lot of code logic to do a task, appears to be a backdoor way to force the whole rainstorm of functions, methods, classes, objects, OOP-ish party... When they could have just used a Label and called it a day. To do the same of what a Label can do (task wise), your functions can't stay simple, they instead must mutate into a class, methods, and OOP-ish constructs

Code: Select all

Gosub MyLabel

MyLabel:
variables
If statement
else If statement
else If statement
Sort
Random
variables
If Instr()
ThisFunc()
ThatFunc()
MyFunc()
Return

Can do both the small or large task(s)

Code: Select all

MyLabel:
Msgbox, Hello World
Return

And this...

Code: Select all

MyClickFunc(oCtl)
{
	MsgBox("hello world")
}

Doesn't visually nor conceptually (arguably) match up with hotkeys (will we be taking the Hotkey out of AutoHotkey soon?), where Labels do. I mean if we don't like "colons" anymore. Because the Hotkey construct is quite similar to the Label construct.

Code: Select all

Gosub MyLabel

MyLabel:
Run Notepad
Return

#n::
Run Notepad
return

Labels allow for creative uses not usually done with functions, like breaking a subroutine into steps, thus allowing advancement from any part of the step, not just the beginning. Functions are not Labels, so when we remove Labels, something is indeed lost.

Code: Select all

Step1:
Store =
( 
Goto the store.
)
MsgBox,1, Store, Step1:`r`r%Store%
IfMsgBox Cancel
    Return

Step2:
Buy =
(
Buy a computer.
)
MsgBox,1, Buy, Step2:`r`r%Buy%
IfMsgBox Cancel
    Return

Step3:
Bring =
(
Bring the computer home.
)
MsgBox,1, Bring, Step3:`r`r%Bring%
IfMsgBox Cancel
    Return

[nnnik]

Separation of concern is neither exclusive to functions nor objects or even programming. It applies to any engineering task. Why do you exclude labels here?
If people misuse labels to do what they did before they can just use functions now.
It seems likely to me that lexikos will eventually come up with a new syntax for Hotkeys too.
Can I take that last comment as a hint that you do not want to write comments in your code but still complain that labels are now missing for that visual separation purpose?
Because you can indeed use functions in every place you could use labels before - you now just always have to call the function (use GoSub) instead of just walking over the border of a label.

[jeeswg]

- @Frosti: People like that the AHK v1 GUI syntax is relatively simple and succinct, that much is true.

- @SOTE: AHK v1 used g-labels (like the Sort command used an F label), this isn't so bad, but I did not like the use of A_ variables that came with it. Using the OnEvent method is a solution, and gives you more granular control over events.
- In my GUI functions library, where everything is done via hWnds, and no objects are used, I'll probably have a GuiOnEvent function that uses window/control hWnds.

- I don't use labels/gosub/goto, but they should be kept, they are useful for some tasks, and for translating to/from other programming languages.
- I'm actually happy for AHK functions to call functions only, and not use labels.
- My reasoning is this: it's simpler if only functions or only labels are used by OnXXX functions/methods. Functions offer the significant advantage of making parameters available, labels offer nothing over functions.
- If I'd created AutoHotkey from scratch, I probably wouldn't even have thought that a function would use a label as a callback function, it seems pretty unusual. Does it exist elsewhere?

- Hotkey labels are useful for quick code examples/smaller scripts.
- Interestingly, I'm thinking of removing hotkey labels in my main (massive) script.
- For reasons of script maintenance/choosing hotkeys/code sharing, it's better to have all of my hotkey subroutines as functions. And determine the hotkeys, in one function, at the start of the script.
- Another advantage is to avoid problems(/possible disasters) with polluting the global namespace, where a variable with the same name is used by multiple hotkey subroutines.
- Here is some code re. moving to functions:
log hotkeys, get extended hotkey info, interact with the *right* window (Hotkey command with FunctionObject example) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=29560&p=275685#p275685

- I agree with Uncle Bob that functions should be small. I also agree that high-level functions should only contain high-level code, and that medium-level/low-level code should be moved out to separate functions.
- However, some 'functions', what I might call 'large-scale subroutine functions', are different, and it's fine if they're long. (I.e. functions that are not going to be used by other functions.)

[SOTE]

- People like that the AHK v1 GUI syntax is relatively simple and succinct, that much is true.

Agreed. AHK v1 GUIs were the very reason why I choose the language for scripting and automating tasks that I had. Remember this was years ago. I didn't need any complex IDEs to create GUIs or to get eye burn from any convoluted syntax, when I needed to slap a simple GUI on top of a script or command line program.

And reading/listening to comments from AutoHotkey old timers and strong supporters like Jack Dunning (who has a AHK v1 VS AHK v2 GUI comparison on his blog) or Joe Glines, they don't seem particularly enthusiastic about AHK v2 yet. They can of course speak for themselves as to their reasons, but I suspect it's because AHK v1 is enough for what they want to do (if it ain't broke don't fix it) or they don't see enough benefit yet in switching over. Remixing the syntax to suit a particular style of programming, while also eliminating often used features, is not necessarily a benefit in itself.

- AHK v1 used g-labels (like the Sort command used an F label), this isn't so bad, but I did not like the use of A_ variables that came with it. Using the OnEvent method is a solution, and gives you more granular control over events.
- In my GUI functions library, where everything is done via hWnds, and no objects are used, I'll probably have a GuiOnEvent function that uses window/control hWnds.

I just don't see A_GuiEvent and A_EventInfo, which can do a lot of what GuiOnEvent is doing, or the "A_Variables" as any type of enemy (as I didn't see g-labels or Labels as such). This is what I mean by "remixing", which is a bit different from cleaning up the syntax. We are talking major revisions of the language and fixing what arguably isn't broken. It's of course the prerogative of the developers, but do think if changes are for the users, that their input and what's in their best interest should count. I don't see how taking a simple to understand and use language and making it more difficult to understand and use is for the greater good. I'm no way against change. It's just that when doing so, I would think the benefit of such a change needs to be overwhelming, as oppose to very minor.

- I don't use labels/gosub/goto, but they should be kept, they are useful for some tasks, and for translating to/from other programming languages.
- I'm actually happy for AHK functions to call functions only, and not use labels.
- If I'd created AutoHotkey from scratch, I probably wouldn't even have thought that a function would use a label as a callback function, it seems pretty unusual. Does it exist elsewhere?

A bit contradictory, because labels, gosub, goto, and return work together. If we become primarily a function orientated language, then the other useful constructs end up getting tossed out. We become more C++ Lite, then the easy AutoHotkey scripting language that it was. But what attracted people to using AutoHotkey in the first place (to include it's cousins of WinBatch and AutoIt)? This is why I believe if you make AutoHotkey difficult or more restrictive, then the debate enters in why not use C++, Object Pascal, or Java. It's not like they don't have SendKeys, script variants of the programming language, or can't use the AutoHotkey.dll.

In AHK v1, we can put functions into labels and labels into functions. The users choice isn't forced, they have both functions and labels to play with. And part of that point is that AutoHotkey offers functionality that other programming languages don't, not that we are under the same restrictions as other languages. People arguably use AutoHotkey because it's not like most other OOP-ish programming languages, and want something different.

- Hotkey labels are useful for quick code examples/smaller scripts.
- Interestingly, I'm thinking of removing hotkey labels in my main (massive) script.

I find this a bit contradictory as well. You are acknowledging the usefulness of Hotkey labels, but then are contemplating removing them. I think the Hotkey labels are fantastic. It's the point of AutoHotkey, it goes to the very core of the usefulness of this scripting language. Otherwise, we could suffer through PowerShell or go hard core C++.

- I agree with Uncle Bob that functions should be small. I also agree that high-level functions should only contain high-level code, and that medium-level/low-level code should be moved out to separate functions.
- However, some 'functions', what I might call 'large-scale subroutine functions', are different, and it's fine if they're long. (I.e. functions that are not going to be used by other functions.

Large-scale subroutine functions... Is that like another way to say Classes, and then the avalanche of OOP concepts? Or, are we talking about these awkward humongous parameterless functions that are basically a Label, just we don't want to call it that? How is it that Labels and simple syntax became the "bad guy"? Don't get me wrong, I have nothing against functions, I just don't get this forced choice we have come to. A world where we can have only functions or labels. And I'm just not seeing how this is making life easier for non-programmers that were hoping to use AutoHotkey to do some simple automation task, that could be done easily with g-labels, labels, or hotkey labels.

[SOTE]

Separation of concern is neither exclusive to functions nor objects or even programming. It applies to any engineering task. Why do you exclude labels here?

I didn't say that Labels were excluded from this. I agree that they are included, not excluded from such. Though I do think that Labels makes separation of concerns easier, because they can be more directly linked to the task trying to be accomplished, and are arguably more intuitive for beginners. You can plan out your code as to the tasks it will do, putting a Label to describe what the task is. And this task can have multiple steps, involving a lot of logic.

It's not to say this can't be done with functions, but rather functions usually (or traditionally) have been associated with doing one specific thing and staying simple, not a multi-step task full of logic. It's been Classes (going OOP concepts) that were associated with a large task(s), containing a series of functions (methods) and lots of logic.

If people misuse labels to do what they did before they can just use functions now.
It seems likely to me that lexikos will eventually come up with a new syntax for Hotkeys too.

True, we can "misuse" parameterless functions to create quasi-labels, and stuff them full of logic. But I'm looking at why we would do so. If a person is a "programming purist", I would think this would disturb their sensibilities, more than the use of Labels. Such stuffed parameterless functions and Classes stuffed full of just functions is supposedly bad programming. On the flip, if the style of programming doesn't matter, then there shouldn't be an issue with Labels, Gosub, and Return.

And in AHK v1, we have both Labels and functions, so the user has the choice to program in the style they think suits them best. Which accommodates those that want to keep their programming style simple (thus use Labels, g-labels, and Hotkey labels), and very advanced users that want to lean towards functions and OOP concepts (Classes, Methods, Objects, etc...).

[nnnik]

To summarize it you want to keep labels because:

• Labels require less basic knowledge (e.g. scope)
• Labels are more associated with bad coding practices so people will be less annoyed when they are poorly coded
• People liked labels and used them
• You also want to keep labels since they make seperation of concern possible very easily???? (I dont understand this - labels exclusively use global context and therefore seperation of concern is almost impossible)

I think its good to remove labels because:

• They are a syntax which consumes this spot for other possible syntax so only a beneficial syntax should stay around
• v2 aims to unify the syntax in a lot of regards - labels vs. label-functions is a competition here
• labels are less integrated into the rest of the language in comparison to functions
• labels actually require some additional maintenance to make them compatible with callables, some additional error checking for classes and functions and they behave weird inside functions
  To guarantee a minimal amount of quality this work needs to be done
• labels are easier to learn but actually create code that becomes irrelevant once you switch to more advanced concepts
  Its not only things new users learn but also work new users put in - you seem to completely disregard that
• You assume that a new user will immediately work without any knowledge of variables and still immediately go and understand the g and v names inside GUIs
  I think that assumption is not relevant for AHK v2 anymore - you now need a basic knowledge about variables pretty early on
• You assume that it is completely impossible for new users to get their heads around the new objects or just copy code

So in the end I think the cost and restrictions that labels introduce are greater than the benefits it offers.

You said that AHK was the successful marriage of advanced features where basic users can do basic things.
I very much strongly disagree - AHK 1 created 2 versions of itself 1 more advanced scripting language part and one newbie friendly part.
The parts did not mix well at all - in fact most of it was straightforward incompatible.
If I compare it to a marriage then it would be like a divorced family with a child that only stays together since they both fear they might loose custody.

[Frosti]

["Only believe what you have recognized as true."].Buddha <> Robert C. Martin (Uncle Bob).["Functions should do one thing. They should do it well. They should do it only."]

[SOTE]

I believe there might be a disconnect between what "average Joe" is trying to get accomplished versus formally trained programmers trying to conform to what they learned at school or an ideal of what programming "should be". Maybe this can be looked at as what is practical and convenient vs what is ideal.

"Average Joe", who isn't a formally trained programmer and has little to no aspiration to make it a profession, will be more interested in trying to accomplish a task. To perhaps automate a GUI of some random program or game, slap a GUI on top of a command line program, or say automate repetitive tasks at his job. What they will likely be looking for is an easy to understand and use tool to accomplish the task desired, and wouldn't be interested in following what is "supposed" to be the "proper" style to code or what is someone's subjective belief of it. Thus I refer to the "greater good", or what some would call the "target audience". That AHK v1 can accommodate both the quick and easy, along with very advanced programming concepts, is an advantage and not a detriment.

If we strip the "quick and easy" away from AutoHotkey, this reduces the reason to use the scripting language. A highly motivated user can buckle up and endure the process of learning C#, Object Pascal, Python, Java, etc... Where many such languages, with so-called proper coding practices, have some form of automation tools. Such tools in other programming languages are often less sophisticated on the Windows platform than AutoHotkey, but they have the weight of that programming language (to include libraries and compilers) behind it, so control flow isn't needed. And whatever their tools might lack for an immediate need, they can temporarily use the AutoHotkey.dll or AutoIt.dll, or their users can bear down an create the automation function desired. Even looking at the code or ways of other automation tools as inspiration. WinAutoKey (Object Pascal) illustrates such a point.

To summarize it you want to keep labels because:

• Labels require less basic knowledge (e.g. scope)
• Labels are more associated with bad coding practices so people will be less annoyed when they are poorly coded
• People liked labels and used them
• You also want to keep labels since they make seperation of concern possible very easily???? (I dont understand this - labels exclusively use global context and therefore seperation of concern is almost impossible)

• That Labels, g-labels, or hotkey labels require less basic knowledge is not a negative, put a plus for AutoHotkey. Other languages don't usually offer such easy to use conveniences. The argument is that by taking them out of AutoHotkey, is to reduce it's usefulness.
• Labels are not a bad coding practice. The argument is they are a different style of programming, that's easier to use.
• Labels have been widely used in many AutoHotkey scripts, as searching through the forums and Internet proves.
• You kind of got me on this one, and my answer was confused. And the separation of concerns argument follows along with the global state and namespace pollution argument. However, my rebuttal on these types of arguments is that being able to easily understand how to separate code by the task it will accomplish (divide script by labels/subroutines) is of greater importance than namespace pollution. The user, regardless of style, will need to manage and track their usage of variables, so the use of labels doesn't matter in that context. Using functions or OOP-ish concepts will not remove this responsibility. We can argue that functions are better than labels in this context, but the counter is that for smaller or simple scripts (the majority) it's usually irrelevant, and AHK v1 allows for the usage of both (labels and functions).

I think its good to remove labels because:

• They are a syntax which consumes this spot for other possible syntax so only a beneficial syntax should stay around
• v2 aims to unify the syntax in a lot of regards - labels vs. label-functions is a competition here
• labels are less integrated into the rest of the language in comparison to functions
• labels actually require some additional maintenance to make them compatible with callables, some additional error checking for classes and functions and they behave weird inside functions
  To guarantee a minimal amount of quality this work needs to be done
• labels are easier to learn but actually create code that becomes irrelevant once you switch to more advanced concepts
  Its not only things new users learn but also work new users put in - you seem to completely disregard that
• You assume that a new user will immediately work without any knowledge of variables and still immediately go and understand the g and v names inside GUIs
  I think that assumption is not relevant for AHK v2 anymore - you now need a basic knowledge about variables pretty early on
• You assume that it is completely impossible for new users to get their heads around the new objects or just copy code

• This appears subjective. And AHK v1 is providing both. So what is really being done is removing a well used functionality in AHK v2.
• Response would pretty much be the same as above.
• Is this referring to AHK v1 or AHK v2 (where of course they will be less integrated as the result of removal)?
• This also appears to be the subjective discretion of developers. It's of course your prerogative, my appeal to reconsider is more "big picture" based.
• This is kind of true, and not at the same time. Every programmer will learn and evolve over time. So what they wrote previously, might not be how they will write it in the future. Because they used labels in the past, doesn't stop them from rewriting their code. Even if they started with functions, doesn't mean they won't be dissatisfied with their script(s) later and want to rewrite them, or that some new feature came out that they want to add.
• I've seen first hand, that it's easier to explain labels (to include g-labels and hotkey labels) to people with no programming knowledge. And keep in mind, WinBatch (a for profit company) also uses labels (though a little differently). So there is arguably something to them, that they also decided to keep them around after so many years.
• Again, experienced this first hand. Functions, Methods, Classes, Objects, and OOP-ish concepts are not an easy introductory conversation or even a one day conversation to people that have no knowledge of programming. I think a disconnect might be happening, where formally trained programmers after some years, understands such easily and as second nature, so might forget the length of their learning process. For most average people, they will debatably more intuitively understand labels, because they use them all the time in regular life.

You said that AHK was the successful marriage of advanced features where basic users can do basic things.
I very much strongly disagree - AHK 1 created 2 versions of itself 1 more advanced scripting language part and one newbie friendly part.
The parts did not mix well at all - in fact most of it was straightforward incompatible.
If I compare it to a marriage then it would be like a divorced family with a child that only stays together since they both fear they might loose custody.

I suppose this is a "agree, to disagree". I think the marriage was successful in AHK v1, but maybe some of us just didn't like the other partner or have little empathy for those that aren't programmers by trade. I'm asking those that would happen to read this, to think about what most would use AutoHotkey for. It's fantastic that AutoHotkey can be used as a general programming language to prototype or build large applications, that can somewhat compete with the likes of Visual Basic (to include VBA and VBScript), Python, C#, etc... on the Windows OS. But more often than not, AutoHotkey will be use for small and quick automation and utility type tasks (huge plus of AHK), by non-programmers. Dropping the quick and easy, which appears to be centered around the use of labels (to include g-labels and hotkey labels), would debatably take away what made AutoHotkey popular and appealing. Maybe something worth taking into consideration.

Note- edited for small spelling and grammatical mistakes.

[nnnik]

That Labels, g-labels, or hotkey labels require less basic knowledge is not a negative, put a plus for AutoHotkey. Other languages don't usually offer such easy to use conveniences. The argument is that by taking them out of AutoHotkey, is to reduce it's usefulness.

I never said its a negative I agreed its a positive point of labels.

Labels are not a bad coding practice. The argument is they are a different style of programming, that's easier to use.

They are not inherently bad coding practice - I never said.
What I mean by to associate is that people think its bad coding practice - not that it actually is.

Labels have been widely used in many AutoHotkey scripts, as searching through the forums and Internet proves.

Not arguing with that - in fact I used one this morning for SetTimer.

However, my rebuttal on these types of arguments is that being able to easily understand how to separate code by the task it will accomplish is of greater importance than namespace pollution. The user, regardless of style, will need to manage and track their usage of variables, so the use of labels doesn't matter in that context.

Tracking variables is a lot easier in a limited scope. Functions achieve both global namespace and task seperation - where as labels only achieve task seperation.

This appears subjective. And AHK v1 is providing both. So what is really being done is removing a well used functionality in AHK v2.

Could you point out whats subjective there?

Is this referring to AHK v1 or AHK v2 (where of course they will be less integrated as the result of removal)?

v1 and v2.

[SOTE]

This appears subjective. And AHK v1 is providing both. So what is really being done is removing a well used functionality in AHK v2.

Could you point out whats subjective there?

They are a syntax which consumes this spot for other possible syntax so only a beneficial syntax should stay around

This was in response to one of the items in your list above. It appeared you were saying that labels or g-labels were not beneficial syntax, so subject to removal.

[tank]

I like labels. Period. Easier to understand for noobs. Oops is hard. That said ECMA 6, the most widely used scripting language in the world, and is usually self study by noobs, will have more in common with v2 than not. This includes not having labels.

[nnnik]

@SOTE what I meant was that only a syntax that is more beneficial than unbeneficial will stay. Just keeping it because its there is not an argument when you consider this.
You could say this about any other syntax too - its true for any other syntax as well.

@tank Isnt Python more commonly used though?
https://www.tiobe.com/tiobe-index/

[tank]

https://www.tiobe.com/tiobe-index/

Thats an interesting table but i would bet it more represents the main skill not the only. For example a significant portion of the JAVA developers do web applications and therefore JavaScript.

[nnnik]

Its based on search results.

[Frosti]

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.