Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

Discuss the future of the AutoHotkey language
User avatar
nnnik
Posts: 4146
Joined: 30 Sep 2013, 01:01
Location: Germany

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

11 Jun 2019, 01:24

1) isn't that a point to remove labels and hotkey labels entirely, so that people don't waste their time learning them when they generally aren't that useful for the language?

I say we remove the label pitfall to make things easier on people.

2) you need special syntaxes to use both. You can't have the exact same way to reference them both since they are on separate namespaces. That useless clutter makes the language more difficult.

3) We are talking about the creation of GUIs which is very much part of usage beyond automation. If they want advanced features they probably need to learn the advanced techniques.
While not everyone uses advanced features all the time the people that do should be the focus when creating these features.
Going by 2 the presence of labels does cause issues for these people.


To me it seems like you are not very good at explaining things, or maybe your personal opinions about the difficulty of functions seeps through and affects people.
You also can't design a language or its features for the people that don't even use it.
Recommends AHK Studio
SOTE
Posts: 624
Joined: 15 Jun 2015, 06:21

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

11 Jun 2019, 03:43

nnnik wrote:
11 Jun 2019, 01:24
1) isn't that a point to remove labels and hotkey labels entirely, so that people don't waste their time learning them when they generally aren't that useful for the language?

I say we remove the label pitfall to make things easier on people.
Removing labels will make things more difficult, not easier. To remove key features that AutoHotkey is known for and those things that makes it easy to use, is to make it the equivalent of any other traditional language. Why even use AutoHotkey? Just start using C, C++, Object Pascal, etc... We could just strip AutoHotkey down, until it looks just like the C++ that it came from.

It might be that you are confusing AutoHotkey having features that are not usually available in traditional programming languages as being bad. We could make the argument that AutoHotkey doesn't need ControlClick or WinActivate, that instead we should use the equivalent function in C++.

If people are using AutoHotkey and not C++, then perhaps it should be clear why this is so. I dare say many don't want to use C++ or rather have an easier alternative. Which is why WinBatch, AutoIt, and AutoHotkey came about. With that stated, I do acknowledge that a developer would have a different mindset about such, but then how many users are developers?
nnnik wrote: 3) We are talking about the creation of GUIs which is very much part of usage beyond automation. If they want advanced features they probably need to learn the advanced techniques.
While not everyone uses advanced features all the time the people that do should be the focus when creating these features.
Going by 2 the presence of labels does cause issues for these people.
I think there is a disconnect in this logic. Nobody is instantly an advance user. Which features are used would be relative to the ability and experience of the user, contrasted against the types of tasks they are faced with and wish to perform. To have a language that only focused on advanced features and techniques, would probably eliminate the vast majority of users. It would likely create a convoluted and difficult to use language, that would be understood and useful to the few, not the many. Unless of course you were making things that were difficult in other languages, and making them easier in AutoHotkey. I think one of the main points of AutoHotkey is ease of use and understanding. If it become no different than the other languages that exist, then it loses it's luster and appeal.

It's also not only one way or the other. A language can be good at doing both, the easy and difficult. Thus it would be useful for the majority, as oppose to the minority.
nnnik wrote: To me it seems like you are not very good at explaining things, or maybe your personal opinions about the difficulty of functions seeps through and affects people.
You also can't design a language or its features for the people that don't even use it.
While you might believe this to be true, I was not the one who taught vast numbers of users on the AutoHotkey forums, Reddit, or Stackoverflow. If functions were so easily understood, then that would be evident on this and those forums. As clearly that's not the case, it should be clear that something else is at work. Quite a large segment of users enjoy using labels, g-labels, and hotkey labels. And the AutoHotkey language is introduced by those label features, by the vast majority of sources when a Google search is done.

As I mentioned, it's not that functions are unexplainable (particularly parameterless functions), but rather that non-programmers would not of had experience with them. The concept of labels is just more simple to explain and initially use. Then the jump from labels to parameterless functions becomes small, and from there the jump to functions with parameters. And as can be seen within numerous scripts, people can and do use both at the same time. Where they have functions called from or inside of labels, and labels that are contained within functions.
nnnik wrote: You also can't design a language or its features for the people that don't even use it.
A user could be using a programming language or script they created quite often, just not need to use the most advanced features that much. Advanced features, almost by definition, would be something less likely to be used than the other features that are available.
User avatar
nnnik
Posts: 4146
Joined: 30 Sep 2013, 01:01
Location: Germany

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

11 Jun 2019, 04:08

The jump to parameterless functions is the easiest if you start with parameterless functions.

All languages focus on their advanced users and create an environmet in which advanced users can use all parts of the language easily.
In v1 AutoHotkey fails there because most advanced users tend to avoid the GUI commands, labels - therefore they are not useful to the users that want AutoHotkeys advanced features.

Of course people transition between 2 stages, but the time spent between 2 stages is neglecteable. You either already meet the requirements for being an advanced user or not.
You either are a basic user or are not. In the end people can use more advanced techniques even if they aren't that advanced yet by copying code and adapting it with trial and error.
Therefore we focus on these stages the users are in.

You state that using functions instead of gLabels is an insurmountable difficult hindrance - on the other GUIs themselves are far more complex than simple basic functions.
You can expect that a person willing to make a GUI can learn functions as well.

In addition to that AHKv2 will immediately tell you if something is wrong. Making the copying of patterns or similar things a lot easier.
A language can be good at doing both, the easy and difficult. Thus it would be useful for the majority, as oppose to the minority.
AHK v1 proved the opposite.
Removing labels will make things more difficult, not easier. To remove key features that AutoHotkey is known for and those things that makes it easy to use, is to make it the equivalent of any other traditional language. Why even use AutoHotkey? Just start using C, C++, Object Pascal, etc... We could just strip AutoHotkey down, until it looks just like the C++ that it came from.

It might be that you are confusing AutoHotkey having features that are not usually available in traditional programming languages as being bad. We could make the argument that AutoHotkey doesn't need ControlClick or WinActivate, that instead we should use the equivalent function in C++.
I implied the relation to my last point without actually pointing it out. Advanced users commonly know more than one language and know and use functions from other languages.
Labels are unique (in how they set these idiotic A_ variables) to AHK therefore a transition for advanced users is problematic.
A special handling for multiple syntaxes is confusing and less straightforward - therefore problematic.
That leaves us with one non-problematic choice to satisfy the users of these features and this language.

Remove label support from it and replace it with function support.
Recommends AHK Studio
SOTE
Posts: 624
Joined: 15 Jun 2015, 06:21

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

11 Jun 2019, 05:58

nnnik wrote:
11 Jun 2019, 04:08
The jump to parameterless functions is the easiest if you start with parameterless functions.
That's debatable, because it can be argued that labels can do more than a simple function or that functions should be kept simple. What is contained in a label can expand from simple code to lots of complex logic, where it's more like a class. A label can contain lots of calls to many different functions and all kinds of other code, where it's categorized more by the task it's accomplishing. Where to do this with functions, one would arguably need to study OOP concepts, so that they would design a "proper" class with methods, etc... Once we start sticking our toe into OOP concepts, things become not so easy, or at least much more difficult than explaining and using labels.
nnnik wrote: All languages focus on their advanced users and create an environmet in which advanced users can use all parts of the language easily.
In v1 AutoHotkey fails there because most advanced users tend to avoid the GUI commands, labels - therefore they are not useful to the users that want AutoHotkeys advanced features.
I find this odd. Clearly AHK v1 has done and is doing well for itself, where it's used by beginners and advanced users. Creating GUIs is quite easy, because of tools like AutoGUI. AHK v1 GUI and label commands appear quite simple to understand and use for the majority. The impression that you give is that AutoHotkey's unique features bother you, and you rather it be/become like some other language. To this I say, there is Object Pascal and those languages to jump to. Why destroy those features that AutoHotkey is known for and are often used, and instead embrace that other programming language, which has different ways to create GUIs and no labels?
nnnik wrote: Of course people transition between 2 stages, but the time spent between 2 stages is neglecteable. You either already meet the requirements for being an advanced user or not. You either are a basic user or are not. In the end people can use more advanced techniques even if they aren't that advanced yet by copying code and adapting it with trial and error. Therefore we focus on these stages the users are in.
You state that you understand that people transition between stages, like beginner to advance, but then brush aside beginners and those transitional steps in the next sentences. I don't think this was the mindset of the original creator of AutoHotkey or WinBatch. They built a tool that would make things easier, so that beginners and non-programmers could use it. And the advanced features within the language was for accomplishing more advanced tasks, as the user progresses and transitions to it over time, not just to cater to only advanced user that already know multiple programming languages.
nnnik wrote: You state that using functions instead of gLabels is an insurmountable difficult hindrance - on the other GUIs themselves are far more complex than simple basic functions. You can expect that a person willing to make a GUI can learn functions as well.
My argument is that a person can use both labels and functions. That AutoHotkey should maintain this flexibility, and allow the user to choose which or use both, however they see fit to do so. Removing well known features in AHK v2, that are already in AHK v1, looks regressive and not progressive.
nnnik wrote: I implied the relation to my last point without actually pointing it out. Advanced users commonly know more than one language and know and use functions from other languages.
On this point, we have very different opinions. I don't think that the vast majority of AutoHotkey users will be advanced users in other programming languages. An advanced user of Object Pascal or Python (for example) would not need AutoHotkey, except under limited circumstances (like a very specific automation task) or as a matter of preference (they find AutoHotkey easier for a specific task), since they have automation tools as well. I think it makes more sense to expect that those that choose to use AutoHotkey, a large percentage of them would be new to programming or not advanced users. I don't see that as a bad thing, but a good thing, where AutoHotkey is introducing people to automation and programming.

Note- small edits on last paragraph was done.
Last edited by SOTE on 11 Jun 2019, 17:23, edited 1 time in total.
User avatar
nnnik
Posts: 4146
Joined: 30 Sep 2013, 01:01
Location: Germany

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

11 Jun 2019, 08:12

You state that you understand that people transition between stages, like beginner to advance, but then brush aside beginners and those transitional steps in the next sentences. I don't think this was the mindset of the original creator of AutoHotkey or WinBatch. They built a tool that would make things easier, so that beginners and non-programmers could use it. And the advanced features within the language was for accomplishing more advanced tasks, as the user progresses and transitions to it over time, not just to cater to only advanced user that already know multiple programming languages.
I ignored beginners because beginners cannot understand GUIs anyways.
And planning for the transition will only make you end up adding another new fixed stage because you cannot plan with a transition.
So what are you gonna make 1000 stages and make unique APIs especially catered to them.
Yeah lets GUI Syntax for people that know autohotkey for 3 minutes - those who know it for 30 minutes and those that know it for 2 weeks and then finally one for everyone that knows it for at least half a year.
Of course they are going to interfere with one another and make it more difficult to actually fully understand the language.
Its also extra work. I think its not worth it - you just cant cater to everyone.
I find this odd. Clearly AHK v1 has done and is doing well for itself, where it's used by beginners and advanced users.
Many people complained about many things for years - many even left the language behind.
Of course you don't know that since you arent involved enough yet.
My argument is that a person can use both labels and functions. That AutoHotkey should maintain this flexibility, and allow the user to choose which or use both, however they see fit to do so. Removing well known features in AHK v2, that are already in AHK v1, looks regressive and not progressive.
I don't think this was the mindset of the original creator of AutoHotkey or WinBatch.
Having both clutters the language - while labels provide no beneficial advantage.
The whole point of v2 is it to remove features that have outgrown their usefulness or don't matter to the current language anymore.
Because suprise languages grow over time - what once seemed like a good idea is now irrelevant or doesn't fit the language.
v2 seeks to solve these problems so that the language can grow further than it currently can.
Of course that means the main focus is removing and replacing features.
That's debatable, because it can be argued that labels can do more than a simple function or that functions should be kept simple.
Thats not really open for debate. The only thing that functions do not have that labels have is goto. Using goto shouldn't be considered an option anyways.
On this point, we have very different opinions. I don't think that the vast majority of AutoHotkey users will be advanced users in other programming languages. An advanced user of Object Pascal (for example) would not need AutoHotkey, except under very limited circumstances. I think it makes more sense to expect that those that choose to use AutoHotkey, a large percentage of them would be new to programming or not advanced users. I don't see that as a bad thing, but a good thing, where AutoHotkey is introducing people to automation and programming.
Most regulars of the forum program in multiple laguages.
Recommends AHK Studio
SOTE
Posts: 624
Joined: 15 Jun 2015, 06:21

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

11 Jun 2019, 18:38

nnnik wrote:
11 Jun 2019, 08:12
I ignored beginners because beginners cannot understand GUIs anyways.
I don't know about that. From the beginning, I understood AHK v1 GUI syntax very quickly. Which was one of the reasons why I choose AutoHotkey (over WinBatch and AutoIt) for writing scripts, where you could quickly make GUIs for command line tools (among other things). However, I did talk with some IT friends about WinBatch (too expensive back then) and AutoIt, so did get some prior exposure to those languages. I was always of the opinion that AHK v1 GUI syntax was comparatively easy to use and understand. The help files and forums does a good job explaining. And to top it off, there is AutoGUI and SmartGUI Creator.

I thought it was more a matter that some people were not interested in building their own GUI applications, but more interested in automating the GUI of existing applications. If there is confusion, it might be that the syntax for the creation/automation of an AutoHotkey GUI can differ from that used for automating other Windows Applications. I've on occasion seen this in the help forums. For example, there is GUIControlGet and ControlGet, and some newbies confuse themselves. This is quite minor, and the difference is usually soon understood, by more reading and playing with the examples and code.
nnnik wrote: Many people complained about many things for years - many even left the language behind.
But complaints and some people leaving the language are bound to happen anyway. What if they want to write applications for Linux, MacOS, iOS, or Android? AutoHotkey is primarily a Windows OS tool (maybe add ReactOS at some point). And on that point, I could argue that if a new version of AutoHotkey is being developed, that it should be for Linux or Android. Maybe C# advocates and programmers might want a say...

No programming language can be all things to all people, thus people will jump to or use something else. I don't see anything wrong with say using AutoHotkey and C# or Object Pascal. It's not like you have to only use one language. If a person learns another programming language, they can still use AutoHotkey too. Hell, that might create a good situation, where there will be developers that can fork AutoHotkey to other OSes.

Note- I also find it interesting that if so many AHK users actually know multiple other programming languages and are advanced users (as nnnik believes), instead of being beginner/casual programmers or that AHK is their first or primary language, that there hasn't been more activity in creating a multi OS version of AutoHotkey or fork of it using a different programming language (particularly C#).

If AutoHotkey will be forcibly developed as primarily a Windows OS automation tool, I'm just saying that it having unique features (only found in AutoHotkey) and other benefits is a good thing. This will set it apart from competing automation tools, where AutoHotkey is the best Windows automation tool. Stripping off well known AutoHotkey features (so that it's more generic or becomes about the same as using AutoIt), and it also being confined to the Windows OS only (though the "Windows world" is still pretty wide), doesn't seem to be for the best.

AHK v2 Becoming Too Similar To AutoIt v3?

Maybe it has escaped the notice of others, but I see AHK v2 as becoming too similar to AutoIt v3 in various ways. Keep in mind that when AutoIt went from AutoIt v2 to v3, that it caused a major break in it's community, and looks to be one reason many switched to AutoHotkey years ago (in addition to the hotkey label fight between developers). AutoIt v3 also stripped out using labels, Gosub, Goto, etc... Becoming "pro-function" oriented. In addition to making itself more of an odd Visual Basic clone, that's written in C++. The thing about that is, if I were to use Basic, I would rather use Visual Basic .NET, PowerBasic, PureBasic, or other dialects because they are cross-platform or retain easy to use syntax. Interestingly, various flavors of Basic which are presently sold or have many users still retain the labels, Gosub, and Goto syntax. PlayBasic, PowerBasic, PureBasic, FreeBasic, and Gambas (Basic/Java hybrid) being among them.

The syntax changes that were made in AutoIt v3 did little for it as a Windows automation language or ease of use, just made AutoIt more generic and a strange clone of another programming language. AutoIt v3's popularity appears to be at an all time low, if you check the number of visitors to it's forum. Arguably, the rise and popularity of AutoHotkey v1, might have more to do with it's more unique user friendly syntax than is being estimated.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: Helgef and 8 guests