What has happened to AutoHotkey?!

Discuss Autohotkey related topics here. Not a place to share code.
Forum rules
Discuss Autohotkey related topics here. Not a place to share code.
geek
Posts: 1052
Joined: 02 Oct 2013, 22:13
Location: GeekDude
Contact:

Re: What has happened to AutoHotkey?!

Post by geek » 22 Mar 2023, 16:03

I think one of the most powerful components to AutoHotkey is the extensive set of Windows-oriented libraries to do just about anything within the Windows graphical shell. Other languages have their own sets of libraries, but all targeted at different environments with naught but scraps for Windows desktop automation. AutoHotkey v2 makes it much easier to build these feature-adding libraries that have more complicated functionality, and gives many tools to make using libraries easier (assuming they actually get used by authors).

I certainly have my gripes with many of the changes. However, I think most of the issues with moving to v2 stem from pre-conceived notions from v1, a sprinkle of pretty confusing error messages, and documentation that goes way too hard. I think all three of those are things that will get better over time.

The example from the original post is a prime example of bad documentation. That code focuses to much on what you can do, neglecting to show you what you probably actually want to do. I would rewrite it from

Code: Select all

main := Gui('+Resize')
main.OnEvent('Close', (*) => (wvc := wv := 0))
main.Show(Format('w{} h{}', A_ScreenWidth * 0.6, A_ScreenHeight * 0.6))
to

Code: Select all

main := Gui("Resize")
main.onEvent "Close", CloseRoutine
main.Show "w" A_ScreenWidth * 0.6 "h" A_ScreenHeight * 0.6

CloseRoutine(thisGui) {
	global
	; Erase global variables wvc and wv
	wvc := unset
	wv := unset
}

This conversation extends into the more general question of what happened to subroutines, and why?

Notably, functions are a type of subroutine, so to be clear I'm calling them "functions" and "labelled subroutines".

Label-based subroutines, mind the french, sucked in key ways.

Labelled subroutines were a primary reason that the auto-execute section existed, making it impossible to write code like

Code: Select all

x := "initial"
a::
msgbox %x%
return

y := "initial"
b::
msgbox %y%
return
which has caused untold pain for the past 15 odd years. Introducing the use of matching brace pairs for v2 made it much easier to delineate what constituted a subroutine / function, and what could be considered auto-executable. This has enabled auto-execution to flow seamlessly around subroutine definitions, making code like the above normal.

Labelled subroutines depend on the existence and management of global variables, which pose unique challenges to people writing libraries, but also to people writing just their own every day code. When I'm working with code that GoSubs everywhere, it's frequently impossible to keep track of what state changes will result from the GoSub. It's possible to do something like

Code: Select all

; ... whatever code

; Populate alpha and beta to be processed by Routine
alpha := 1
beta := 2
GoSub Routine ; Saves results in gamma
but at that point you're just making new work when a function manages data flow in a clear-by-default way. Labelled subroutines for built-in events necessitate the creation and use of built-in variables that are inexplicably not quite global, but instead are some weird almost-global per-thread abomination. They're weird, and as far as I can tell are an innovation that exist purely in autohotkey-alike languages.

Labelled subroutines are forced global. Functions give you the option, which you can very easily take.

Labelled subroutines don't nest properly, so if you want to make a new subroutine to handle, say, your GUI events inside of a subroutine or function that created the GUI, you end up tearing your hair out. This has been a huge problem in the past with labels like GuiClose, GuiSize, GuiDropFiles, etc. I acknowledge that you have to be a certain kind of person to run up against this with any frequency, but I am that kind of person.

The biggest point, from a language feature standpoint subroutines entirely duplicate the functionality of functions. The two can fight each other, but given that functions support all label features with some extra left over, functions will always win.

In v2, functions have new tricks that make their replacing labelled subroutines much easier to bear. Notably, they can read global variables now without having to mark them as global (though you must mark them as global to write to them).

You can call them by name as a command, meaning you can call them easier than a v1 labelled subroutine. In v1, you'd write GoSub subroutine, but in v2 you can now write just subroutine for any named function-based subroutine.

If you're build a GUI inside a function, you can now define the event handlers for that GUI also inside the function. And those functions defined inside functions can access and change the variables from the outside super duper easily, referencing just the ones for that instance of the GUI making it super duper easy to make your callbacks affect the variables you want. It's an absolute game changer.

Code: Select all

makeMyGui

makeMyGui() {
	guiName := Gui("Resize")
	guiName.SetFont "s16"
	textControlName := guiName.AddText("c303030", "Width: 9999, Height: 9999")
	guiName.onEvent "Size", ResizeMe
	guiName.Show "w" 640 "h" 480
	
	ResizeMe(guiName, minMax, width, height) {
		; notice here, textName was grabbed automatically from the outside world
		textControlName.Text := "Width: " width ", Height: " height
	}
}
Notably, GUI syntax is still bizarre. However, v1's GUI syntax is also bizarre. If you struggle with it, I understand but I strongly do not believe it's because v2's GUI syntax is inherently worse. This is a prime example of a struggle that exists only when you already know v1, and so it does not make a good metric to judge v2's implementation's friendliness for newcomers.

I don't know where I'm going with all this, except maybe to say that the documentation for v2 is misleading. A lot of the symbol soup can be thrown out, to reveal a more v1-ey language underneath. I do regret the removal of plain-text parameters, and the brief existence of variable de-referencing in strings with no practical replacement. But over all, it makes it better for power-users to create better tools for non-power-users and that's a good thing. It adds many stumbling blocks for people coming from v1, but I don't believe that's avoidable.

In the Discord we've been helping people completely new to v2 for many weeks now, and the biggest stumbling blocks are:
1. I installed v2 but I've copied v1 code from online into my script
2. (Frustratingly) I asked ChatGPT to help me with my code and it spat out absolute hot garbage which I pasted into my script
3. Just regular issues that people would have whether they were using v1 or v2, like not putting braces around indented if else blocks

User avatar
mikeyww
Posts: 26601
Joined: 09 Sep 2014, 18:38

Re: What has happened to AutoHotkey?!

Post by mikeyww » 22 Mar 2023, 16:27

Those are fantastic points, well detailed, and I agree with them.

User avatar
rommmcek
Posts: 1470
Joined: 15 Aug 2014, 15:18

Re: What has happened to AutoHotkey?!

Post by rommmcek » 30 Mar 2023, 14:41

I agree with every one on this thread, but I'm not undecided and will definitely migrate (gradually) to Ahk v2, because everything is developing, however unlike a new OS, browser and the like, Ahk is open source, hence unlikely to be insidious in any way. So long live Ahk v2!

P.s.: Ahk v2 seems to be here and there more efficient...
Spoiler

guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: What has happened to AutoHotkey?!

Post by guest3456 » 02 Apr 2023, 02:07

geek wrote:
22 Mar 2023, 16:03
The example from the original post is a prime example of bad documentation. That code focuses to much on what you can do, neglecting to show you what you probably actually want to do. I would rewrite it from

Code: Select all

main := Gui('+Resize')
main.OnEvent('Close', (*) => (wvc := wv := 0))
main.Show(Format('w{} h{}', A_ScreenWidth * 0.6, A_ScreenHeight * 0.6))
to

Code: Select all

main := Gui("Resize")
main.onEvent "Close", CloseRoutine
main.Show "w" A_ScreenWidth * 0.6 "h" A_ScreenHeight * 0.6

CloseRoutine(thisGui) {
	global
	; Erase global variables wvc and wv
	wvc := unset
	wv := unset
}
+100000000000000
:clap:

v2 docs should be completely rewritten in this manner


User avatar
mikeyww
Posts: 26601
Joined: 09 Sep 2014, 18:38

Re: What has happened to AutoHotkey?!

Post by mikeyww » 02 Apr 2023, 05:18

Although the documentation needs improvement, the script shown here is an especially poor example of how to improve the documentation, for the following five reasons.

1. It demonstrates that the user has not even bothered to consult the documentation to learn what the fat arrow function is. This is the opposite of what we are trying to promote. Although it's nice when a language can be understood just by looking at it, this cannot always be the case.

2. The fat arrow function itself is described reasonably well in my view.
Fat arrow function. Defines a simple function and returns a Func or Closure object. Write the function's parameter list (optionally preceded by a function name) to the left of the operator. When the function is called (via the returned reference), it evaluates the sub-expression expr and returns the result.
3. The part of this documentation section that actually needs improvement is overlooked. An example should be included about how to use this function when including the function's name, in a situation where including the function's name is especially useful.

4. The script that is provided is not actually part of the documentation (or I might have just missed it when I searched for it). Readers of this thread can be misled into thinking that this is the case. If the script is present, including examples of how AHK features are used helps readers understand those features in greater detail.

5. The fat arrow function is a poor example of a so-called problem with v2, because, like ~= in v1, it is merely a convenient shorthand notation and is never required to achieve any effect or result. Therefore, a novice may simply ignore it and never use it. The documentation already indicates this by providing the long-hand version and indicating that the two code samples are equivalent.

Thus, I would say overall that a key challenge to using v2-- as with any language-- is undertaking an adequate process to learn how it works. For v1 users, v2 syntax may come as a surprise because v2 has so many differences from v1. In some ways, this may actually make v2 easier to learn for the coders who are new to AutoHotkey.

neogna2
Posts: 586
Joined: 15 Sep 2016, 15:44

Re: What has happened to AutoHotkey?!

Post by neogna2 » 02 Apr 2023, 06:51

I agree with mikeyww.
mikeyww wrote:
02 Apr 2023, 05:18
4. The script that is provided is not actually part of the documentation (or I might have just missed it when I searched for it). Readers of this thread can be misled into thinking that this is the case. If the script is present, including examples of how AHK features are used helps readers understand those features in greater detail.
It seems the code snippet is from this WebView2 lib example forum post by thqby
viewtopic.php?t=95666#p425637

jibeta281
Posts: 1
Joined: 19 Apr 2023, 03:26

Re: What has happened to AutoHotkey?!

Post by jibeta281 » 19 Apr 2023, 03:27

What set AutoHotkey apart from all other languages I've tried over the years, is simplicity combined with power. No libraries, no definitions, just code and go. Write a line, test it, add another, rinse and repeat. Originally there were few paranthesis, no line ends, no conversion between data types, no case sensitivity, all the things that bug novice users in other languages. And still AutoHotkey has been able to do anything I've thrown at it, with the assistance of the wonderful contributors in the community.

LazarouJoinery
Posts: 22
Joined: 02 Jan 2022, 21:41

Re: What has happened to AutoHotkey?!

Post by LazarouJoinery » 21 Apr 2023, 02:36

I came here today, to express my immense thanks to all the giants, upon who's shoulders I stand.
I have read the V2 docs. Many parts of it are EXCELLENT. Because of programming ease however, I will be sticking with AHK_L.
AHK_L was an excellently managed project, IMO. The docs still hold up, the language stayed agnostic from the triad of OO-Functional-Imperative paradigms.

The loss of the imperative paradigm, and the awkward influences of OO and FP, are too contextless to the absolute beginner. I've been a beginner programmer for 15 years, and if I could rewrite forum pages, I'd scream to beginners:
"DON'T BE SCARED OF GLOBALS! YOU DON'T NEED TO USE A FUNCTION!"

For scripts - end-user scripts - of <500 lines, you can get by best, in V1.
My business is a mix of multiple 10k+ scripts, and dozens of <500 line scripts; and to the whole community I owe that effort.
V2 wasn't stable, when I was in a position to port.

I wholeheartedly endorse the notions that manual is contributed to, not to show what's terse or novel and shiny: but what's conventional.
Fat arrows, closures, object inheritance etc, does not belong in the manual examples. These belong in libraries.

Already OO and FP are not beginner concepts. V1's imperative control-flow was.
I've been using AHK_L since it's inception, and I still have problems with objects, and cannot find everyday uses for function objects, boundfuncs, enums, prototypes, methods, maybe more. I understand that these, and RegisterCallbacks, are tools for different problems, and I appreciated their addition into the language. I can use the docs, and get myself out of a bind with some of those features. The beauty of V1, is that I could **just solve it dodgy and simple**.

V2 is no more or less readable, really. But it is SO MUCH LARGER and consequently SO MUCH BETTER.
The GUI object does make sense. The syntax/command cleanup, does make sense. The OO features, make brilliant, easily composable libraries for end-users.
It is just so much harder to help absolute beginners understand the OO paradigm for problem solving, let alone, program design. I know this, as I have to explain my programs to colleagues.

AHK V2 is more idiomatic, and that's what will keep me happily esconced in V1.

User avatar
mikeyww
Posts: 26601
Joined: 09 Sep 2014, 18:38

Re: What has happened to AutoHotkey?!

Post by mikeyww » 21 Apr 2023, 06:04

This commentary is interesting. I can't argue with a preference or something that is faster to learn and more appealing for that reason alone. For anyone who has never done any computer programming, v1 does seem like it would be faster to learn, in terms of building simple scripts. If such learners choose not to expand their learning or complexity in scripting, it might also be a good way to go in the longer term. I'll say a few additional things here.

1. In my view, reading the docs is not always the best sole way to make a decision about a program or to compare it to something. I'd even say that trying v2 for an hour provides an insufficient test, because you'd be comparing it to something that you have used for years and already know well. If I tried to learn Swahili for 15 minutes, I'd probably conclude that English is easier and so I'm going to stick with that. A better comparison requires more extended usage. So far, I haven't found anyone who tried v2 for a month, writing and using v2 scripts, and then decided to return to v1 for most of their scripting.

2. For those who do frequently use functions and expressions in their v1 commands, v2 could lead to faster coding and simpler scripts.

3.
Fat arrows, closures, object inheritance etc, does not belong in the manual examples.
This does not make sense to me, because fat arrow functions and closures are essentially like "syntax variants". If you told me to put that in a library, I wouldn't have any idea of how to do that. I also find these structures to be useful "in the core".

I do not use all of the available AHK functions, so I can simply ignore documentation pages that I do not need. I prefer a more complete set of documentation. Fat arrow functions are completely optional and do nothing that a regular function cannot do.

4.
But it is SO MUCH LARGER and consequently SO MUCH BETTER.
This does not make sense to me. Larger things aren't always better. I'm not even sure what "larger" means here, and I don't think v2 is better because it's larger, though I think it has a design that facilitates understanding, coding speed, functionality, consistency, and fewer errors. For me, it is more readable than v1, but this requires working with it for a few weeks.

You've pointed out that there is a role for v1 and an audience that fits it, so I cannot argue with that.

ahketype
Posts: 191
Joined: 27 Oct 2016, 15:06
Location: Yorkshire, UK

Re: What has happened to AutoHotkey?!

Post by ahketype » 21 Apr 2023, 08:07

LazarouJoinery wrote:
21 Apr 2023, 02:36
I came here today, to express my immense thanks to all the giants, upon who's shoulders I stand.
I have read the V2 docs. Many parts of it are EXCELLENT. Because of programming ease however, I will be sticking with AHK_L.
AHK_L was an excellently managed project, IMO. The docs still hold up, the language stayed agnostic from the triad of OO-Functional-Imperative paradigms.

The loss of the imperative paradigm, and the awkward influences of OO and FP, are too contextless to the absolute beginner. I've been a beginner programmer for 15 years, and if I could rewrite forum pages, I'd scream to beginners:
"DON'T BE SCARED OF GLOBALS! YOU DON'T NEED TO USE A FUNCTION!"

For scripts - end-user scripts - of <500 lines, you can get by best, in V1.
My business is a mix of multiple 10k+ scripts, and dozens of <500 line scripts; and to the whole community I owe that effort.
V2 wasn't stable, when I was in a position to port.

I wholeheartedly endorse the notions that manual is contributed to, not to show what's terse or novel and shiny: but what's conventional.
Fat arrows, closures, object inheritance etc, does not belong in the manual examples. These belong in libraries.

Already OO and FP are not beginner concepts. V1's imperative control-flow was.
I've been using AHK_L since it's inception, and I still have problems with objects, and cannot find everyday uses for function objects, boundfuncs, enums, prototypes, methods, maybe more. I understand that these, and RegisterCallbacks, are tools for different problems, and I appreciated their addition into the language. I can use the docs, and get myself out of a bind with some of those features. The beauty of V1, is that I could **just solve it dodgy and simple**.

V2 is no more or less readable, really. But it is SO MUCH LARGER and consequently SO MUCH BETTER.
The GUI object does make sense. The syntax/command cleanup, does make sense. The OO features, make brilliant, easily composable libraries for end-users.
It is just so much harder to help absolute beginners understand the OO paradigm for problem solving, let alone, program design. I know this, as I have to explain my programs to colleagues.

AHK V2 is more idiomatic, and that's what will keep me happily esconced in V1.
Thanks for expressing many of the things I was thinking, particularly the appreciation of old-skool methodology, "dodgy and simple", and globals. In particular, thanks for making me feel better about my struggle with objects and a lot of the other shiny concepts in modern programming. I know I'm not stupid, but I keep thinking I must be when faced with objects and classes and instances and inheritance - it's like, yes, that's great and makes sense, but what the hell do I need it for? Once or twice, I've found a structure I'm working on that might possibly be better done that way, but often it's just as easy, more readable, and - to my mind - easier to follow, debug and change if I do it the old ways I learned in 1984.

I haven't delved much into V2, and decided to stick to V1 for the foreseeable. I'm not sure it makes sense to say one or the other is "better", as is generally pointed out when anyone asks, "What's the best programming language?" (or best most things, for that matter). It depends on a lot of things, including personal taste.

LazarouJoinery
Posts: 22
Joined: 02 Jan 2022, 21:41

Re: What has happened to AutoHotkey?!

Post by LazarouJoinery » 23 Apr 2023, 22:18

@mikeyww Just as you, I can't argue with 1.) and 2.), or any of your points really.

3.) when I mean "put it in a library", I don't mean like, extensible syntax a-la Lisp.
I mean, such shorthands obfuscate examples.
Shorthands/syntax sugars are great if you know how to use them, impenetrable if you aren't clued in.
So they are good, in user's library code, that you can study.
It's at that point, that noob users will choose to either opt-in to that syntax, or rewrite that lib for clarity.
(Let's be honest - this user is copy-pasting that lib)

Having read the V2 docs (and the rest of this thread) I know that the V2 examples (per-article) are sufficiently noob-friendly.
And just translated V1 examples, so there's that side-by-side comparison.
mikeyww wrote:
21 Apr 2023, 06:04
"so I can simply ignore documentation pages that I do not need.
I likely use the manual in exactly the same way as you, but I can't ignore the pages I don't need... because one does need them.
I've just checked my v1 CHM file.. I've used every article, except for ClipWait.
Much of this can be explained while researching unusual behaviour in AHK (as per the user's expectations).
Unusual thread behaviours. Fiddling with #Directives. Trying to work out what __Enums are. Just making things work.

mikeyww wrote:
21 Apr 2023, 06:04
This does not make sense to me. Larger things aren't always better. I'm not even sure what "larger" means here, and I don't think v2 is better because it's larger, though I think it has a design that facilitates understanding, coding speed, functionality, consistency, and fewer errors. For me, it is more readable than v1, but this requires working with it for a few weeks.
There's new functions in V2, and that's without considering the changes to classes/objects
https://www.autohotkey.com/docs/v2/v2-changes.htm#new-functions
It's broader in scope, and more complete in total capabilities - that's what I mean by 'larger'. And it is, unmistakeably, better.
For comparable stability, one should be able to express more concepts - in OO fashion. That's going to allow quite a few talented users, a platform to make quite a lot of better, cleverer, more considered libraries, available to users.
I have no doubt that V2 tooling is going to improve greatly. A few concepts, like the Standard Library, etc. will likely get revived.

I myself, am moving onto new pastures for my next projects - less opinionated again, lisps. A privilege that people like your good self, have afforded me.
I'm only a shifting-out of the audience - someone new will come to AHK. I just empathise, that some concepts:
- state change
- mutatability
- flow of control
... you need to trust the novice user to batter through as they implement their business logic.. as quick, dirty and with as many GoTos as they like.
Asking novices to Design Programs is a bit too much for them, to zip everything up - including control flow - into functions.

User avatar
mikeyww
Posts: 26601
Joined: 09 Sep 2014, 18:38

Re: What has happened to AutoHotkey?!

Post by mikeyww » 23 Apr 2023, 22:51

Thank you for these details & explanations-- interesting reading, and I can appreciate the views. At least v1 remains available for those who want to stick with it, get started, dabble, etc. I can see the appeal, as one need not know much or anything about functions, objects, and so on.

LazarouJoinery
Posts: 22
Joined: 02 Jan 2022, 21:41

Re: What has happened to AutoHotkey?!

Post by LazarouJoinery » 24 Apr 2023, 01:52

ahketype wrote:
21 Apr 2023, 08:07
I know I'm not stupid, but I keep thinking I must be when faced with objects and classes and instances and inheritance - it's like, yes, that's great and makes sense, but what the hell do I need it for?
It's easy to forget just how long ago these things started out... as I understand it, Alan Kay (??) develops OO for Smalltalk, as a timesaving/laboursaving/standardising methodology, that shows promise for the future... It's brilliant for creating *systems*, but it is overwrought for gluing things together - as we do. Our opinions, your and mine, are simple: (declarative && OO && functional) programming all require *knowledge overhead*: design patterns and/or library knowledge. (Imperative programming && the CHM file) gets people off the ground, and interested. The gateway programming paradigm, the necessary paradigm :-)

ahketype
Posts: 191
Joined: 27 Oct 2016, 15:06
Location: Yorkshire, UK

Re: What has happened to AutoHotkey?!

Post by ahketype » 24 Apr 2023, 04:29

I too appreciate your explanations. I'm feeling mischievous:-
LazarouJoinery wrote:
24 Apr 2023, 01:52
The gateway programming paradigm,
Hmm, like a gateway drug. Maybe I'm resisting the hard stuff. :lol:
the necessary paradigm :-)
And the opposite of "necessary" is "unnecessary". ;) This reminds me of when I told my partner something was "perfectly adequate," and she said, "Yes, but perfectly adequate doesn't mean it's good enough."

Post Reply

Return to “General Discussion”