Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

Discuss the future of the AutoHotkey language
User avatar
nnnik
Posts: 4500
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: 1426
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: 4500
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: 1426
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: 4500
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: 1426
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 Basic dialect, 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. By the way, Object Pascal uses labels and Goto. And it has the syntax Exit and Result (used somewhat like how Return is used in AutoHotkey, C++, etc...).

The syntax changes that were made in AutoIt v3 arguably did little for it as a Windows automation language or ease of use, just made AutoIt more generic and a strange flavor of Basic. AutoIt v3's popularity appears to be at an all time low, if you check the number of visitors to it's forum. So it's not like stripping highly used syntax made things better. 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.
User avatar
Tigerlily
Posts: 377
Joined: 04 Oct 2018, 22:31

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

01 Jul 2019, 00:41

Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

No.

I started using AutoHotkey less than a year ago. I learned a considerable amount in a very short time period, with absolutely zero prior exposure or experience to programming.

Was AutoHotkey v1 easy to learn?

No. I had to put in the time, dedication, and practice for hours and hours each day before I could become somewhat competent in using it for both personal and business use cases. I think just like lexikos said, there is going to have to be some real effort put in by a newb to learn any programming language. If v2 was stable and complete, then I would tell every newb that asks me for help that they should start on v2. However, since v1 is the official, stable version of AHK at the moment, I tell them to learn v1 first, then learn v2 because of the sheer amount of resources out there for v1 vs. v2. All those people at some point are going to have to do what I did and "re-learn" AHK in v2, which was painful because after learning v1, then learning v2, there are certain things that don't transfer over simply (like OutputVar parameters vs. the Output result from a function and strings with quotes vs. without quotes).

A huge hurdle for me when I first started with AutoHotkey last year was understanding legacy vs. expression syntax. I struggled with it for the majority of the time I spent learning how to program using AutoHotkey because of the dual usage found in documentation, archived threads, and new threads. I would see people doing incredible stuff in the archived forums using legacy syntax, but then see similar things in newer threads from users who tried very strongly to not use legacy syntax.

AutoHotkey v1 was certainly not EASY to learn, it took time, dedication, and tons of failing to learn. AutoHotkey v2 syntax would have stripped a lot of the nonsense I struggled with in the beginning out. Since I learned AHK v1, it has made me want to learn other languages. It's a simple fact that v2 syntax more seamlessly transfers over into practices found in other programming languages than v1. v1 is clunky and v2 is more smooth.

I think v2 will be easier to understand for newbies solely based on it's stronger root in simplicity of syntax (AKA not two different syntaxes to compete for your time and attention and end up confusing you) and pointless/confusing things like SetBatchLines, -1 don't ever need to be explained again to newbs since it is stripped out completely. v2 is just plainly more designed with simplicity in mind for the aspiring AHK newb.

I help newbs out with v1 syntax all the time on the AUTOHOTKEY DISCORD CHANNEL, and the legacy syntax mixed with expression syntax is probably one of the most commonly misunderstood and confusing things for them.
-TL
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

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

05 Jul 2019, 11:00

Tigerlily wrote:
01 Jul 2019, 00:41
Was AutoHotkey v1 easy to learn?
On this point, I would say YES, it is relatively easy. Thus it became so popular. But a key point is what is the meaning of relative for a person. I would also say that depending on what you are using AutoHotkey for, a person may find it more or less difficult, relative to the task they are seeking to accomplish. If a person says AutoHotkey is difficult, we should keep in mind what that is relative to. Are we simply talking about programming is difficult, what they want to accomplish is difficult, or if AutoHotkey is more or less difficult in comparison to other programming languages?

I don't know of any other languages that does this any easier.

Code: Select all

#n::Run Notepad
And labels makes it just as simple to keep adding to that.

Code: Select all

run_notepad:
#n::
    MsgBox, Notepad will run!
    Run Notepad
    return
AHK v1 is easy, when used for automation and simpler goals. Particularly, hotkeys. In this respect, AutoHotkey (as the name suggests), blows away even AutoIt (from which it forked). Debatably, the more a person uses AutoHotkey in the arena of automation, the relatively easier it will be to do things with AutoHotkey in comparison to other languages. This is because one would be using a language built around automating tasks in Windows versus general programming languages not specifically built for or lacking syntax to make such easier. This is why we have WinBatch, AutoIt, and AutoHotkey. The language from which they came, C++, was unwieldy and difficult for most people to deal with.

I would say AHK v1 is definitely easier than C++, and there is a strong argument it's overall easier than AutoIt. The further a person gets away from simple automation, like hotkey labels or manipulating standard Windows GUIs, the more likely they are to encounter difficulty. I think this is a problem beyond just syntax, but is relative to the task. If you start using AutoHotkey for building applications and general purpose programming, then a person can run into greater difficulties. But those difficulties are relative to learning programming, logic, and writing "clean code". A lot of the problems people can have go beyond syntax and are due to poor logic, inexperience, and lack of studying.

If we are outside the realm of just automation, and are much more heavily involved in building applications and general purpose programming, then the person is going to have to put in the hours. There is no choice but to become a programmer and have a clear understanding of syntax and programming concepts. We will need to start to know what are arrays, objects, functions, classes, DLLs, S.O.L.I.D principles, OOP concepts, composition vs inheritance, etc...

I've not seen evidence that AHK v2 will make life easier than what AHK v1 can already do for the vast majority and what they usually use AutoHotkey for. I do understand the desire to "clean up" syntax, but don't think that should come at the expense of functionality. It might be best to be cautious and conservative about what syntax is eliminated, when/if it's reducing flexibility and features people have in AHK v1. Many might not see how a newer version of software that does less then the previous version, is the better version. Not against change, just hoping that when changes are made, they are for the better.

Other programming languages are not automation based, consequently a lot of what they are doing doesn't match up to what WinBatch, AutoIt, or AutoHotkey was designed to do. My impression is that most people are interested in AutoHotkey, because it's not like other languages. That they can use it for automation, in addition to general programming, and that it's easier to understand and use. I don't think it's a good idea for AutoHotkey to become "just like other languages", and see nothing wrong with it having an unique identity and style to solve programming problems. Differences in programming languages, often allow them to better adapt to situations and tasks.

Also, don't get me wrong. My point is not entirely AHK v2 VS AHK v1, but rather to question what is the best for the majority of users. AHK v2 is eventually inevitable, I'm just hoping to point out some things that might improve how it's perceived and embraced. I believe that AutoHotkey has beat out it's competition and has become so well liked, because it's a more handy and an easier to understand tool. Part of that has to do with making good choices in what syntax to use.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

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

05 Jul 2019, 18:10

the best for the majority of users is to not be bombarded with a multitude of mildly different, partly compatible but mostly incompatible syntaxes and ways of doing things.
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

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

05 Jul 2019, 19:48

SOTE wrote:
05 Jul 2019, 11:00
On this point, I would say YES, it is relatively easy. Thus it became so popular.
It has been said before that AutoHotkey became popular because of what it can do, not because of its syntax. Do you believe that it would have been less popular if the v2 language had been implemented from the beginning? I do not.

It has also been said that AutoHotkey became popular despite its syntax.
I don't know of any other languages that does this any easier.
It's about what the program can do, not the language. This isn't any harder in v2, but it is arguably clearer.

Code: Select all

#n::Run "Notepad"
And labels makes it just as simple to keep adding to that.
Functions are just as simple (this will also run in v1).

Code: Select all

#n::
run_notepad()
{
    MsgBox "Notepad will run!"
    Run "Notepad"
}
This is because one would be using a language built around automating tasks in Windows versus general programming languages not specifically built for or lacking syntax to make such easier.
What syntax are you talking about?

Functions like Send, WinActivate, ControlClick and so on are what makes automation easy, not the syntax you use to call those functions. The library of functions/commands and the language are different parts of AutoHotkey. Functions can be easily ported or exposed to other languages, or made language-agnostic.

The legacy syntax is sometimes suited for automation in the sense that quotation marks can be omitted for most parameters (window titles, keystrokes, etc.), but do not mistake this to mean the language was built around automating tasks. The legacy syntax primarily exists because of decisions made nearly 20 years ago by the author of AutoIt (from which the legacy syntax was copied), who replaced that "really horrible" syntax (as he called it) over 16 years ago. It's likely that the design was motivated by lack of experience more than any concerns over what is suitable for automation;
Jonathan Bennett wrote: Previous versions were very strict about syntax it was "Command, param1, param2,..." and it took about a month to come up with something that could read in a line containing complex expressions (a whooooole lot of googling required). Although I "get" it now, writing the expression code in AutoIt was the 2nd hardest thing I'd ever done.
Source: AutoIt and Developer History (January 2003)
The same library in any other modern scripting language would be just as powerful, if not more so. The hotkey and hotstring syntax is unique and adds convenience over (for example) the Hotkey function, but it is ultimately just a convenience.
AHK v2 is eventually inevitable, I'm just hoping to point out some things that might improve how it's perceived and embraced.
I cannot see how anything you have said could improve how v2 is perceived and embraced. On the contrary, you seem to argue that v2 is a step backward. If what you're saying is that you hope to convince "the developers" to revert to v1 syntax under the assumption that doing so would improve perception and adoption of v2, you can forget it. Chris recognized long ago that the legacy syntax should be removed, I agreed when I began v2 years ago, and if anything, I have only grown more certain that it was the right decision.
Many might not see how a newer version of software that does less then the previous version, is the better version.
In what way does AutoHotkey v2 do less than v1, or were your words mere hyperbole? Having multiple ways to achieve the same result is not functionality.
My impression is that most people are interested in AutoHotkey, because it's not like other languages.
I think you are in the minority. What attracts people to AutoHotkey is what it can do, regardless of (or despite) the language.
I've not seen evidence that AHK v2 will make life easier than what AHK v1 [...]
Then open your eyes. :HeHe:
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

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

06 Jul 2019, 01:50

lexikos wrote:
05 Jul 2019, 19:48

It has been said before that AutoHotkey became popular because of what it can do, not because of its syntax. Do you believe that it would have been less popular if the v2 language had been implemented from the beginning? I do not.
As usual Lexikos, you have my utmost respect, despite some minor disagreements.

On this point, I'm not so sure. It could be that AHK v2 would have been less popular than AHK v1. This might be the case, because of how AHK v1 overtook AutoIt v3. Many of the things that some AHK v2 advocates argue for, were implemented in AutoIt v3 and later versions. Stripping out labels, Gosub, Goto, etc... If a final version of AHK v2 followed the same path as AutoIt v3, it might not be as popular. Changes to AutoIt from v2 to v3, outside of the ability to create GUIs, didn't make it any more popular. Instead, AHK v1 gained a larger audience, debatably at the expense of AutoIt v3.

It might be that the easier to use and understand syntax of AHK v1 was a key factor in this, in addition to greater conveniences like hotkeys. With that typed, I do think the large number of improvements and increased functionality that you (Lexikos) and other developers had made to AHK v1 were also part of the increase in popularity. But so to, has AutoIt v3 improved. So maybe there is something more to the syntax and language choices made, that it should not be so quickly dismissed.

For the most part, AHK v2 has kept much of the syntax, functionality, and "spirit" of AHK v1, so I don't think learning the new version will be so dramatic to long time users. Though obviously the vast number of libraries made with AHK v1, will also be incompatible and need to be re-written. To include tools like AutoGUI and AHK Studio should probably have an AHK v2 version or replacement. I think there will be a certain amount of inconvenience, that nobody can say how many will react to this. The overall popularity of a language might also have to do with software development tools that are available and examples of usage, not just syntax.
lexikos wrote:
05 Jul 2019, 19:48
It has also been said that AutoHotkey became popular despite its syntax.
I've often perceived the attacks on AutoHotkey syntax, to be from those who are programming in other languages, and have become used to those languages. When I look at AutoIt syntax, I see a lot of what can be called problematic and weird. And a bit of what they say (which appear to often be AutoIt folks) comes from rivalry and resentment that AutoHotkey forked off. When I go on other forums, I will see Object Pascal guys say harsh things about C++, and the opposite from advocates of other programming languages about Object Pascal. I think people can become accustomed to how things are done in their preferred language. Not all the criticism is valid, or the complaint about the syntax can actually be quite minor.

With that typed, the need for change and to evolve is understandable. AutoHotkey can't always stay the same, and hopefully the changes made are for the better.
lexikos wrote: Functions are just as simple (this will also run in v1).
Agreed. I'm not against functions. It is also correct that learning them is essential for greater understanding of other programming languages. Though one could debate the percentage of AutoHotkey, AutoIt, or WinBatch users that use just the one language or are primarily focused on automation as opposed to general-purpose programming. Also, I think g-labels should be able to use both labels and functions, and that the use of labels should be maintained in AHK v2.
lexikos wrote: The legacy syntax is sometimes suited for automation in the sense that quotation marks can be omitted for most parameters (window titles, keystrokes, etc.), but do not mistake this to mean the language was built around automating tasks. The legacy syntax primarily exists because of decisions made nearly 20 years ago by the author of AutoIt (from which the legacy syntax was copied), who replaced that "really horrible" syntax (as he called it) over 16 years ago. It's likely that the design was motivated by lack of experience more than any concerns over what is suitable for automation;
In looking at the history, AutoIt was heavily inspired by WinBatch, in terms of types of commands, syntax, and various other aspects. ScriptIt (from WinBatch) was a free tool previously promoted by Microsoft prior to AutoIt. Below is example syntax of ScriptIt.

https://docs.microsoft.com/en-us/previous-versions//cc723493%28v=technet.10%29
(The MS ScriptIt Utility, April 1, 1998)

WinBatch, created in 1991, with it's commands and syntax were no accident. The design of WinBatch or ScripIt didn't come from lack of experience, but was specifically tailored to make things easier for Windows users. It was a "battle tested" product, in existence for many years. Something to take note of, as the Win-Batch name implies, their syntax was influenced by Microsoft Windows Batch Scripting.

"Its language structure and syntax is a cross between DOS batch command, Basic, Fortran, and C..." Before there was WinBatch, there was Command Post, which was created in 1989. WinBatch was derived from the menuing language of Command Post, in 1991. Command Post allowed users to custom design and make changes to Windows menus. Keep in mind that Windows was much more primitive then, but we are talking about an automation concept somewhat similar to Hotkeys, at that time. Where the user could simply click an application's name and launch programs or tasks directly, without have to go through a long list of submenus. What took multiple clicks, could be done with one click.

WinBatch took the concepts of Command Post a step further, creating a programming language and code binder (combining a bytecode version of a program along with an interpreter). Jonathan Bennett made a kind of alternative open source freeware version of ScriptIt (WinBatch). Apparently, Chris Mallett knew this as well. And has mentioned this in the old forums of how AutoIt v2 syntax was heavily inspired by ScriptIt (WinBatch). I think Jonathan Bennett has written on this too. In fact the very name of AutoIt, seems to be a play on words and paying homage to ScriptIt.

WinBatch (from years ago) also has expressions, functions, etc... It's hard to say to what extent changes in that language might have influenced the direction of AutoIt v3. And this likely went back and forth between the automation languages. Where new ideas in one, influenced the others. Debatably things went in the other direction too, where WinBatch was inspired by and got ideas from AutoIt and AutoHotkey.

As a comparative reference between languages and to see examples of usage, below is the WinBatch manual.
https://web.archive.org/web/20170710090254/techsupt.winbatch.com/techsupt/PDFs/wil-lang20170412.pdf
lexikos wrote: Chris recognized long ago that the legacy syntax should be removed, I agreed when I began v2 years ago, and if anything, I have only grown more certain that it was the right decision.
Totally understand and agree with the direction. Though looking at the old archive debates on this, I thought Chris also wanted to remove the AutoIt legacy GPL code so that a more permissive license could be granted, like LGPL or BSD, and finally stop the controversy that was involved over that.

I'm not in disagreement with rewriting the code, but have caution about whether or not some functionality or convenience is/will be lost. I would hope that AHK v2 could do anything that AHK v1 could do, plus more and just as easily. ;)
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

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

13 Jul 2019, 04:21

SOTE wrote:
06 Jul 2019, 01:50
It might be that the easier to use and understand syntax of AHK v1 was a key factor in this
That's allegedly easier to use and understand. ;) I already explained my viewpoint on that in my first reply.
Changes to AutoIt from v2 to v3, outside of the ability to create GUIs, didn't make it any more popular. Instead, AHK v1 gained a larger audience, debatably at the expense of AutoIt v3.
That occurred to me after I posted. One could suppose that mere compatibility with AutoIt v2 could account for AutoHotkey's initial adoption more than any alleged benefits of the syntax. Perhaps compatibility is more important than ease of use, in that respect. However, I want a better program, not a more popular one.
The overall popularity of a language might also have to do with software development tools that are available and examples of usage, not just syntax.
Certainly. Perhaps working on those things would be more productive than this discussion.
I've often perceived the attacks on AutoHotkey syntax, to be from those who are programming in other languages, and have become used to those languages.
How would someone offer valid criticism of AutoHotkey's syntax without any basis for comparison, such as experience in other languages, or an understanding of programming in general?

I was not speaking of attacks, only one opinion.
So maybe there is something more to the syntax and language choices made, that it should not be so quickly dismissed.
What do you mean by "so quickly dismissed"? How long do you think I've been thinking about these things?
Chris Mallett [...] has mentioned this in the old forums of how AutoIt v2 syntax was heavily inspired by ScriptIt (WinBatch).
I've read that, and was misled into thinking AutoIt v2's syntax came from ScriptIt and ScriptIt was derived from WinBatch, but that is not the case.
  • ScriptIt used INI files, not a true scripting language.
  • WinBatch does not have "commands" in the v1 sense; as you know, it has expressions and function calls with parentheses. While it does use percent signs for variable substitution in strings, those strings are quoted.
Clearly, the fundamental parts of AutoIt v2's syntax - the parts that became AutoHotkey's legacy syntax - were not based upon ScriptIt or WinBatch. I do not believe these programs have any real bearing on the topic.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

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

17 Jul 2019, 09:20

lexikos wrote:
13 Jul 2019, 04:21
Chris Mallett [...] has mentioned this in the old forums of how AutoIt v2 syntax was heavily inspired by ScriptIt (WinBatch).
I've read that, and was misled into thinking AutoIt v2's syntax came from ScriptIt and ScriptIt was derived from WinBatch, but that is not the case.
  • ScriptIt used INI files, not a true scripting language.
  • WinBatch does not have "commands" in the v1 sense; as you know, it has expressions and function calls with parentheses. While it does use percent signs for variable substitution in strings, those strings are quoted.
Clearly, the fundamental parts of AutoIt v2's syntax - the parts that became AutoHotkey's legacy syntax - were not based upon ScriptIt or WinBatch. I do not believe these programs have any real bearing on the topic.
AutoIt v1 and v2 syntax was heavily inspired by ScriptIt. Jonathan Bennett explains how in the description of AutoIt's development history.
Link- https://www.autoitscript.com/autoit3/docs/intro/dev_history.htm

From the description and other bits throughout the Internet from Jonathan, it appears that he was trying to make an improved version of ScriptIt. ScriptIt was a special compiled WinBatch script. The relationships between Microsoft and WinBatch (Wilson Windoware) is not entirely clear, but it might be that some people on team Microsoft was using WinBatch and thought it was a good tool to use for a problem they were having.

Microsoft's SCRIPTIT is a Compiled Winbatch EXE
https://web.archive.org/web/20040908054 ... ch~EXE.txt

Winbatch Script to Convert Microsoft ScriptIt INI Files to WBTs (ScriptIt to normal WinBatch program converter)
https://web.archive.org/web/20040925072 ... ~Files.txt
Jonathan Bennett (AutoIt creator)

October 1998
...Searched around for a while for some way to force button presses and came across Microsoft ScriptIt which was a compiled WinBatch script designed for clicking buttons in automated builds.

ScriptIt worked OK but it was extremely unreliable. It was notoriously fussy about the speed of the machine it was used on and had no way to control the key delays between keystrokes. Another feature that caused problems was that there was no way to specify a working directory when running a program which caused loads of problems with many of the applications I was scripting. Also, some of the functions didn't work under NT 5 beta (i.e. Windows 2000).

January 1999
AutoIt version 1 released on the old winfiles.com site. Syntax was similar to ScriptIt (for Send) and featured the functions Send, Run, RunWait, WinWait, WinWaitClose, WinWaitActive, WinHide, WinActivate, WinClose, WinRestore, Sleep and SetKeyDelay. From the v1.0 helpfile:
ScriptIt syntax was derived directly from WinBatch syntax. ScriptIt was merely a modified type of WinBatch script for Microsoft. Jonathan Bennett (AutoIt creator) was then influenced by that syntax when creating AutoIt v1 and v2. And AutoIt v2 is where AutoHotkey has inherited various syntax from, which was chosen by Chris (AutoHotkey creator).

Note: For those that might get confused, AutoIt and AutoHotkey uses no source code from WinBatch. Referring to syntax and language structure. In addition, the syntax of WinBatch is heavily influenced by Microsoft Batch scripting, Fortran, and C.

ScriptIt syntax example:

Code: Select all

~exit
Exits the script immediately. For example:
Untitled – Notepad=~exit
Tells your script to exit when it sees the Untitled – Notepad window.

~wait
Causes a five-second delay in the execution of the script (this is the same as using ##). For example: Network=~wait
Causes ScriptIt to pause for five seconds when the Control Panel's Network window appears. The line Network=## has the same result.

~winwaitclose
Causes the script to pause until the window is closed. For example:
Setup=~winwaitclose
Causes the script to pause until the Setup window closes. This is very useful when setup programs have multiple windows open. ScriptIt will want to continue when it sees a window title that it needs to send keystrokes to; however, a previous step may not have finished. Using ~winwaitclose allows you to pause your script until the previous step completes.

~winclose
Causes ScriptIt to close the window and terminate the executable that created it. For example:
Untitled – Notepad=~winclose
causes ScriptIt to shut down the Notepad instance that created that window.

~winhide
Causes ScriptIt to make the specified window invisible. For example:
Untitled – Notepad=~winhide
causes ScriptIt to hide the window titled Untitled – Notepad. The window is still there, but the user cannot see it.

~winshow
Causes ScriptIt to show the specified window if it is currently hidden. For example:
Untitled – Notepad=~winshow
causes ScriptIt to make the hidden Untitled – Notepad window visible again.

~winmin
Causes ScriptIt to display the specified window as an icon. For example:
Untitled – Notepad=~winmin
causes ScriptIt to minimize the specified Notepad window.

~winmax
Causes ScriptIt to display the specified window as a full-screen window. For example:
Untitled – Notepad=~winmax
causes ScriptIt to maximize the specified Notepad window.
AutoHotkey's syntax has a lineage, which can be traced back. These languages are relevant, because neither ScriptIt or WinBatch syntax looks to have been arbitrarily chosen, but appears to have been mindfully selected to make doing automation easier. The syntax from those Automation languages helped to shape the direction of AutoIt v1 and v2, to include influencing AutoHotkey's syntax.

True, that AutoIt didn't merely copy some syntax from ScriptIt or Winbatch (to include making numerous innovations of their own), but one can see some commonalities in the languages. And syntax choices that Chris made, when creating AutoHotkey, arguably were good ones. Leading to AutoHotkey eventually overtaking AutoIt (to include with Lexikos help and innovation) as arguably the better automation language. I'm just saying that AutoHotkey's syntax lineage is part of why it's such an easy language to learn and use. Expressions and functions are great, nothing against them, I'm just hoping that AutoHotkey maintains it's edge as the better Windows automation language to use.
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

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

20 Jul 2019, 00:53

@SOTE I do not think you comprehend what I said.
AutoIt v1 and v2 syntax was heavily inspired by ScriptIt.
Define "syntax" and "inspired". You've seen and posted a ScriptIt script. Can you honestly say that the language structure is even similar to AutoIt v2? What exactly is the connection between ScriptIt or WinBatch and the concerns you started this thread for?

AutoIt and AutoHotkey have some function names in common with ScriptIt and WinBatch, and the parameter values of those functions have similar interpretation. Even if you consider that part of the "syntax", how does that relate to this topic?
ScriptIt syntax was derived directly from WinBatch syntax.
That is clearly untrue. For example, compare Setup=~winwaitclose (from your post) to WinWaitClose("Setup"). The structure of these two statements is completely different. ScriptIt does not even have control flow:
Note that ScriptIt is not a traditional scripting language and does not offer many of the traditional programming language constructs (such as if, then, else, while, gosub, and so forth).
Source: The MS ScriptIt Utility | Microsoft Docs
ScriptIt was merely a modified type of WinBatch script for Microsoft.
No, ScriptIt was a compiled WinBatch script, as you said. Say someone wrote an AutoHotkey script which took an INI file and ran certain commands based on its contents. That's what ScriptIt was, only built with WinBatch rather than AutoHotkey.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

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

20 Jul 2019, 02:20

lexikos wrote:
05 Jul 2019, 19:48
The legacy syntax primarily exists because of decisions made nearly 20 years ago by the author of AutoIt (from which the legacy syntax was copied), who replaced that "really horrible" syntax (as he called it) over 16 years ago. It's likely that the design was motivated by lack of experience more than any concerns over what is suitable for automation;
The reference to syntax used by ScriptIt and WinBatch is that the syntax looks to be designed for making automation easier. This doesn't look like an accident nor it being "horrible". That AutoHotkey has inherited such type of syntax is debatably an advantage versus a disadvantage. Was referring to the type of syntax (relative to it being easy to understand) and influences, not that the syntax across the specified automation languages were exact duplicates of each other.

Changes made in AutoIt v3, to make the language more Basic-like did arguably nothing for it's popularity. I question that if AutoIt v1 and AutoIt v2 syntax were so horrible. A significant number of AutoIt v2 users broke away to AutoHotkey, after the syntax changes of AutoIt v3. Both legacy versions, AutoIt v1.8 and AutoIt v2.64 are still available for download and a review of the syntax used can be done. AutoHotkey arguably overtook AutoIt v3, with more AutoIt v2 like syntax (which was influenced by ScriptIt and WinBatch syntax). It can be argued that AutoHotkey became more popular because of it's syntax, despite some quirks, and not the claim that it gained in popularity despite the syntax.

The position being presented is that syntax does matter to how attractive an automation based tool is to users. That users can understand it more easily and make use of it more quickly, will likely affect how popular it will be. When AutoHotkey is introduced, which can be seen by a Google search of AutoHotkey, the ease of use as an automation tool is what's often highlighted. Arguably, the introductions, reviews, and code examples of how to do time-saver tasks in the AutoHotkey language contributed greatly in making AutoHotkey more popular than AutoIt v3 and it's revised syntax.
just me
Posts: 9423
Joined: 02 Oct 2013, 08:51
Location: Germany

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

20 Jul 2019, 05:44

Related to AutoIt:

AFAIK, Hotkey and Hotstring commands were the main reason for the split. And IMO, this commands are the main reason for many newbies to choose AutoHotkey as script language, not the command syntax
Another reason might be, that the AutoHotkey forums were (afair) always more tolerant of game manipulation scripts.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

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

20 Jul 2019, 23:31

just me wrote:
20 Jul 2019, 05:44
Related to AutoIt:

AFAIK, Hotkey and Hotstring commands were the main reason for the split. And IMO, this commands are the main reason for many newbies to choose AutoHotkey as script language, not the command syntax...
I have argued that point. That the Hotkey and Hotstring syntax and how it should be implemented were part of the reasons for the fork from AutoIt and that this type of syntax makes automation easier. But, those are reasons to like AutoHotkey for it's syntax and part of it's popularity. This would be an example of why AutoHotkey became popular because of it's choice in syntax, not despite it.
the AutoHotkey forums...
On this we agree, this has helped AutoHotkey. What went on at the AutoIt forums was quite disturbing, and appears to be continuing to this day. But in that, there is a lesson to be learned. Being dismissive, disrespectful, or condensing to one's users (or other developers... like a Chris) is not a winning formula in the long run. Ultimately, one of the main points of a scripting or programming language is to be helpful to users, be they thought of as "lesser" or "greater".
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

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

21 Jul 2019, 03:02

That's what we do.
We decided that having to learn both command and expression syntax to use AutoHotkey at a very basic level is quite a hindrance. So we decided to remove one of the syntaxes in favor of the other.
That the surviving syntax cannot be the command syntax should be fairly obvious.
You have yet to provide any sort of concise reasoning that explains why you want to keep one or the other aside from:
"It used to be like that in the past and I thought that the past was good." and "A person might perhaps be able to grasp command syntax a tiny little bit faster when starting".
To the first I'll just say I disagree. To the second I'll say that the initial gain does not out weight the confusion people encounter afterwards.
Recommends AHK Studio
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

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

26 Jul 2019, 20:49

SOTE wrote:
20 Jul 2019, 02:20
The reference to syntax used by ScriptIt and WinBatch is that the syntax looks to be designed for making automation easier. This doesn't look like an accident nor it being "horrible". That AutoHotkey has inherited such type of syntax is debatably an advantage versus a disadvantage. Was referring to the type of syntax (relative to it being easy to understand) and influences, not that the syntax across the specified automation languages were exact duplicates of each other.
No. Perhaps you're saying one thing and meaning something else entirely, in which case I would have to conclude that I am better off ignoring your posts in future.

Putting that aside, you haven't answered the questions in my previous post.

Given that ScriptIt, WinBatch and AutoIt v2 have quite different syntax and WinBatch appears to be closer to AutoHotkey v2 than v1, I must assume you are not talking about syntax, but some other undefined factor that "makes automation easier". Perhaps you can explain what that is and how AutoHotkey v2 lacks it. I think, probably not.
A significant number of AutoIt v2 users broke away to AutoHotkey, after the syntax changes of AutoIt v3.
If syntax alone was the issue, they could have stayed with AutoIt v2, just as AutoHotkey users may stay with v1. People resist change.
It can be argued that ...
Yes, it has been argued both ways, repeatedly.
Arguably, the introductions, reviews, and code examples of how to do time-saver tasks in the AutoHotkey language contributed greatly in making AutoHotkey more popular than AutoIt v3 and it's revised syntax.
That appears to be a good counter-argument to the rest of your post and this topic in general... :?

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 32 guests