Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
versions [2023-01-25 17:23] – removed - external edit (Unknown date) 127.0.0.1 | versions [2023-01-25 17:23] (current) – ↷ Page moved from playground:versions to versions geek | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Should I choose v1 or v2? ====== | ||
+ | |||
+ | // | ||
+ | |||
+ | ===== Which version should I install? ===== | ||
+ | |||
+ | **Install both.** | ||
+ | |||
+ | The [[https:// | ||
+ | |||
+ | If you install v2 and try to run a v1 script without first installing v1, in many cases the launcher will offer you to automatically install the required version. So if you don’t specifically intend to run v1 scripts, just install v2. | ||
+ | |||
+ | SciTE4AutoHotkey supports both versions out of the box, while VS Code can support both with the installation of appropriate extensions. See [[# | ||
+ | |||
+ | ===== As a beginner, which version should I learn? ===== | ||
+ | |||
+ | **v2.** | ||
+ | |||
+ | Both versions make it easy to carry out a range of tasks with just a few lines of code. Where they differ most is the //syntax// - the rules and patterns that you must learn in order to write code that works. | ||
+ | |||
+ | For [[# | ||
+ | |||
+ | v2 uses expressions throughout, and several common causes of confusion have been removed. If you are a beginner and only need to carry out simple tasks, it is still sufficient to learn just a few simple patterns. When you need more, the learning curve is gentler as there is no need to shift to a different syntax. | ||
+ | |||
+ | v2 has more thorough error-detection and reporting. Sometimes this means writing extra code to avoid doing something the program considers invalid, but in return, troubleshooting is much easier and the code you write is more reliable. Stricter error-detection also tends to limit the damage that mistakes can cause. | ||
+ | |||
+ | It is unfortunately true that there are fewer [[# | ||
+ | |||
+ | ===== As a v1 user, why should I switch to v2? ===== | ||
+ | |||
+ | Even if you aren’t a beginner, you may - I dare say you //will// - benefit from simplification of the syntax and the removal of many common causes of confusion. v2 also includes [[https:// | ||
+ | |||
+ | v1 development will cease; see [[# | ||
+ | |||
+ | Note that // | ||
+ | |||
+ | ===== As a v1 user, won’t I need to learn an entirely new language to use v2? ===== | ||
+ | |||
+ | It has been said that v2 has a completely different language; that v1 users switching to v2 will need to learn a lot of new syntax or concepts, giving up their existing language skills. This is at best oversimplified and exaggerated. | ||
+ | |||
+ | v2 builds upon the same basic concepts as v1, but centers its syntax around expressions. If you have learned expressions for v1, you are most of the way toward understanding v2 code. The major differences are removal of obsolete syntax and concepts, and more robust error-detection and reporting. //New// syntax and concepts generally aren’t mandatory learning; and they are there to help you. | ||
+ | |||
+ | As a v1 user, you’ve probably memorized many details, such as the names of commands, the syntax of each parameter and various special rules within the language. It is true that many small details have changed and will require some relearning, but there are also details and pitfalls that you no longer need to account for while writing code. | ||
+ | |||
+ | ===== Why should I take the time to convert my v1 scripts to v2? ===== | ||
+ | |||
+ | In the process of converting code, you may find opportunities for improvement due to new language features or behaviour, or perhaps because your skills have grown since writing the original code. Improvements to error-detection may allow you to find bugs that were previously undetected - I’ll admit to finding such errors while updating my own code. | ||
+ | |||
+ | But maybe you // | ||
+ | |||
+ | My recommendation is to start small; write new scripts in v2 and learn a bit before attempting to convert existing scripts. | ||
+ | |||
+ | There are plans for more tools to assist with analysis and conversion of scripts, but they have not been implemented yet as the priority has been on getting v2 to a stable release. Some user-created converters exist, although with significant limitations. | ||
+ | |||
+ | If converting isn’t yet a practical option, you might consider loading v1 libraries with AutoHotkey.dll and calling them from v2. [[https:// | ||
+ | |||
+ | ====== Disclaimer ====== | ||
+ | |||
+ | This is written by Steve Gray (Lexikos), the same person who made all of the decisions (but not all of the ideas) for v2 and implemented most of them. v2 represents many hours of hard work and internal debate over more than 10 years, so the answers here may be somewhat biased. Nearly every change (honestly not all) was made with the conviction that it objectively makes AutoHotkey better, so naturally my point of view is that v2 is vastly superior to v1. | ||
+ | |||
+ | ====== History ====== | ||
+ | |||
+ | To understand the purpose of v2, it may help to know some of the history of AutoHotkey. | ||
+ | |||
+ | AutoHotkey v1.0.00 was released in 2004. This version had only (what we now call) [[https:// | ||
+ | |||
+ | For math, it supported only basic operations (add, sub, mult, div), and only one per line. Other math functions were soon added via the [[https:// | ||
+ | |||
+ | By 2005, the capabilities of the program were vastly improved with the addition of // | ||
+ | |||
+ | In 2006 (or perhaps earlier), the original developer (Chris Mallett) started gathering ideas for v2, later published as [[https:// | ||
+ | |||
+ | I (Lexikos) started developing v2 in 2011, using the draft document left by Chris as a guide for the initial alpha releases, but incorporating my own ideas and suggestions from others. With the scope of the project being rather vague and generally only myself working on it (when it interests me), there was never anything like a release schedule. Ideas changed over time and the syntax went through multiple evolutions. | ||
+ | |||
+ | Eventually I decided there had to be a cutoff for compatibility-breaking changes or there would never be a stable release, and soon after that I released v2.0-beta.1 (in July 2021). | ||
+ | |||
+ | ====== Stability ====== | ||
+ | |||
+ | “Stability” can mean a couple of things: 1. How likely it is that a user might encounter bugs. 2. Whether the syntax or features are going to change in ways that prevent previously-written scripts from working as intended. | ||
+ | |||
+ | ===== Compatibility between releases ===== | ||
+ | |||
+ | A stable release can be taken as a promise that scripts you write now will work on future versions, or at the very least, any change that prevents this is accompanied by an increment to the major version number. In other words, all v2.0.x and v2.x releases should be able to run scripts written for earlier v2.0 releases (starting with v2.0-beta.1). Compatibility-breaking changes must be deferred until v3.0. | ||
+ | |||
+ | AutoHotkey v2 alpha releases weren’t expected to be compatible with previous releases, by definition. Changes that were backward-compatible could be (and sometimes were) implemented in the v1.x branch. However, the shift from alpha to beta (in July 2021) signified a major change in priorities, from making breaking changes (alpha) to avoiding them (beta): | ||
+ | |||
+ | > Any further changes prior to the final v2.0.0 release should be of a minor nature (such as improvements to the error and warning dialogs), and should not affect the functionality of scripts. In other words, future releases are expected to be backward-compatible with this one. | ||
+ | |||
+ | Some people are scared off by the “beta” tag or make false assumptions about its meaning, but that no longer matters, as v2.0.0 has been released. | ||
+ | |||
+ | ===== Bugs ===== | ||
+ | |||
+ | v1 uses older code that hasn’t undergone nearly as much change, and has been more widely used over a longer period, so it is only natural that any remaining bugs are of a kind that you aren’t very likely to encounter. However, this is only considering the // | ||
+ | |||
+ | In some cases, old bugs have been fixed while reworking code to have new behaviour for v2; or changes to the way the code works have enabled bug-fixes that weren’t feasible before. | ||
+ | |||
+ | The release policy for v1.x was basically this: bump the fourth version number component for releases that only contain bug-fixes, and the third component if there are new features or other changes. Sometimes new releases with features were available as a test build before-hand, | ||
+ | |||
+ | v2 will be following a more robust release cycle, with a stable branch accepting only bug fixes, and an alpha branch with new features. The current feature set of v2.0 is basically how it will be for its lifetime, with new features coming in v2.1, v2.2 and so on. v2.1-alpha will have enough in it to attract quite a bit of use, and will go through development and testing for much longer than a typical v1.x release (but much shorter than v2.0!). | ||
+ | |||
+ | ====== Syntax ====== | ||
+ | |||
+ | > //boiler says:// Regarding ease of use, v2 removes the primary source of confusion that has plagued new users more than any other: the dual syntax. Sometimes “command” or “legacy” syntax is used, and sometimes expression syntax is used. It can be very frustrating learning when and how to use both. That is what made v1 confusing for even experienced programmers coming from other languages. With v2, expression syntax is used throughout. | ||
+ | |||
+ | There seems to be a common impression among those who have already learned v1 that v1 might be easier to learn for beginners, or that it is easier or has simpler syntax than v2. | ||
+ | |||
+ | v1 // | ||
+ | |||
+ | For example, the '' | ||
+ | |||
+ | <code AutoHotkey> | ||
+ | a = b ; Assignment - legacy syntax, ' | ||
+ | a = b + 1 ; Common mistake - literally assigns the text "b + 1" | ||
+ | local a = b ; Assignment - expression, b is a variable! | ||
+ | if a = b ; Comparison - legacy syntax, ' | ||
+ | if (a = b) ; Comparison - expression, b is a variable | ||
+ | if !a = b ; Comparison - expression, b is a variable | ||
+ | func(a = 1) { ; Declares a default value for parameter ' | ||
+ | a := b, c = d ; All four are variables, and ' | ||
+ | if (a == b) ; Case-sensitive comparison - expression, both are variables | ||
+ | if a == b ; Case-insensitive comparison - the value is literally "= b" (common pitfall) | ||
+ | </ | ||
+ | |||
+ | Although '' | ||
+ | |||
+ | This is just a small set of examples, and by no means complete. | ||
+ | |||
+ | v2 greatly simplifies the syntax, using expressions everywhere except within hotstrings and some directives. | ||
+ | |||
+ | ===== Simplicity? ===== | ||
+ | |||
+ | So, what gives v1 an impression of simplicity? | ||
+ | |||
+ | > ANY programming language, no matter how large and complicated, | ||
+ | |||
+ | The legacy syntax allows a command to be written with fewer “meta-characters”; | ||
+ | |||
+ | <code AutoHotkey> | ||
+ | ifWinNotExist ahk_class Notepad | ||
+ | { | ||
+ | Run Notepad | ||
+ | WinWait ahk_class Notepad | ||
+ | } | ||
+ | WinActivate | ||
+ | Send {Text}Hello, | ||
+ | </ | ||
+ | |||
+ | Specifically, | ||
+ | |||
+ | However, the need for quote marks should be intuitive to anyone who is reading this (unless you’re relying on machine translation, | ||
+ | |||
+ | Because variable names would be interpreted as literal text by default, including the value of a variable requires marking it with extra symbols. So instead of surrounding the literal text with quote marks, you must surround the variables with '' | ||
+ | |||
+ | <code AutoHotkey> | ||
+ | Run Notepad,,, PID | ||
+ | WinWait ahk_pid %PID% | ||
+ | </ | ||
+ | |||
+ | Since Run’s fourth parameter expects an output variable (or in other words, the name of a variable), no percent signs are used for it. | ||
+ | |||
+ | Although //most// characters are literal by default, another notable exception is that comma is used as a delimiter between parameters. When one needs a literal percent sign or comma, an //escape character// must be used to mark it as literal; e.g. '' | ||
+ | |||
+ | The example above uses '' | ||
+ | |||
+ | <code AutoHotkey> | ||
+ | if not (WinExist(" | ||
+ | { | ||
+ | Run Notepad,,, PID | ||
+ | WinWait ahk_pid %PID% | ||
+ | } | ||
+ | WinActivate | ||
+ | Send {Text}Hello, | ||
+ | </ | ||
+ | |||
+ | So now we have a mixture of legacy syntax and expressions. Rather than trying to keep track of where to quote literal text and where to enclose variables in percent signs (or perhaps just for uniformity or style), some users prefer to use expressions throughout. | ||
+ | |||
+ | Since v1 commands use legacy syntax by default (although [[https:// | ||
+ | |||
+ | <code AutoHotkey> | ||
+ | if not (WinExist(" | ||
+ | { | ||
+ | Run % " | ||
+ | WinWait % " | ||
+ | } | ||
+ | WinActivate | ||
+ | Send % " | ||
+ | </ | ||
+ | |||
+ | So now we have more consistency - literal text enclosed in quote marks, and variables as plain words - but we need a percent sign in front of each parameter of a command (and //not// with functions). | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | By contrast, v2 strips away the legacy syntax, leaving only expressions. For example: | ||
+ | |||
+ | <code AutoHotkey> | ||
+ | if not (WinExist(" | ||
+ | { | ||
+ | Run " | ||
+ | WinWait " | ||
+ | } | ||
+ | WinActivate | ||
+ | Send " | ||
+ | </ | ||
+ | |||
+ | This isn’t very different; I just removed the percent signs and added a single ampersand. (Ampersand in v2 is the [[https:// | ||
+ | |||
+ | In short, the legacy syntax itself is not simpler than the equivalent subset of expressions. To the contrary, retaining the legacy syntax causes greater complexity and a number of pitfalls. There are more rules to learn, and they aren’t always clear. | ||
+ | |||
+ | ===== Learning ===== | ||
+ | |||
+ | It has been said that v1 has a lower learning curve //at the beginning// | ||
+ | |||
+ | Others have said that AutoHotkey (v1) has a steep or inconsistent learning curve, or that v2 was easier to learn - or to //teach//. | ||
+ | |||
+ | A great thing about AutoHotkey is that it is easy to make something useful happen with a few lines of simple code. Most users probably start with basic things like defining a hotkey to open a program, activate a window, send some template text or similar. Often a useful hotkey can be created with a single line, simply writing a command name and some text that the command uses. | ||
+ | |||
+ | <code AutoHotkey> | ||
+ | #n::Run Notepad | ||
+ | </ | ||
+ | |||
+ | Presumably whoever wrote about the learning curve of v1 has experienced it themself. What kind of experience could cause them to think that the legacy syntax //made it easier//? | ||
+ | |||
+ | A new user might typically start with the simplest, most commonly useful commands, and work their way up. Since v1 commands default to legacy syntax, that’s what they learn first. When they find a reason to learn expressions, | ||
+ | |||
+ | Aside from the task itself, the user now needs to attach new syntax to concepts that were already learned with the legacy syntax, remember where to use each form, and how to insert an expression where an expression isn’t normally expected. This probably makes the legacy syntax seem comparatively simple. | ||
+ | |||
+ | Legacy syntax on its own //is// simple, but it is only one very small part of a larger whole. In the absence of legacy syntax, the replacement syntax is just as simple, but is also more consistent with the rest of the language as a whole. This should mean that starting simple and incremently building on that will be even easier. | ||
+ | |||
+ | A new user of v2 doesn’t need to learn all of the expression operators, or even what “expressions” are, to begin writing code. As with v1, they just need to learn some simple patterns, like how to pass some literal text to a function. | ||
+ | |||
+ | <code AutoHotkey> | ||
+ | #n::Run " | ||
+ | </ | ||
+ | |||
+ | ===== Names and scope ===== | ||
+ | |||
+ | v2 changes the rules for [[https:// | ||
+ | |||
+ | ===== Hotkeys and hotstrings ===== | ||
+ | |||
+ | In v2, hotkeys and hotstrings that are associated with multiple lines of code (excluding auto-replace hotstrings) [[https:// | ||
+ | |||
+ | ===== Sub-commands ===== | ||
+ | |||
+ | v1 has various commands that have “sub-commands”; | ||
+ | |||
+ | v2 splits most of these sub-commands into individual functions. This is arguably not particularly interesting or significant, | ||
+ | |||
+ | The monolithic v1 '' | ||
+ | |||
+ | ===== Continuation ===== | ||
+ | |||
+ | v2 supports new methods of [[https:// | ||
+ | |||
+ | ===== Other ===== | ||
+ | |||
+ | Various other changes have been made to the syntax in v2, with a general trend of improving consistency, | ||
+ | |||
+ | ====== Error-reporting ====== | ||
+ | |||
+ | v1 has a tendency to tolerate or ignore errors. When something goes wrong, often it can be difficult to identify where the cause is. It may be that the script //just doesn’t work//, and the user is left guessing as to why. Other times, the script continuing execution after encountering an error might risk causing damage, such as by writing invalid data to files or typing into the wrong window. | ||
+ | |||
+ | By contrast, v2 detects a greater variety of conditions that are likely to indicate an error or mistake in the code, and reports them to the user or transfers control to an exception handler. (The exception-handling mechanism is not new, but is used more consistently in v2.) This greatly facilitates troubleshooting and identifying problems, saving time and perhaps reducing frustration. | ||
+ | |||
+ | For beginners especially, error messages can be disconcerting; | ||
+ | |||
+ | > Learning to code can be a frustrating endeavor because you are destined to encounter many red errors along the way. What makes a programmer successful isn’t avoiding errors—no programmer can avoid them. Great programmers understand that errors are part of the process, and they know how to find the solution to each while learning something new from them. ([[https:// | ||
+ | |||
+ | > A common anti-pattern for learners with the attitude that ‘errors = bad’ is to navigate away from the error as quickly as possible without reading it. They’ll pore over their code instead, trying to reverse-engineer what the error message is already telling them. ([[https:// | ||
+ | |||
+ | Updating old code sometimes requires changing error-handling patterns or adding checks, which draws attention to the (usually minimal) cost of having stricter error-detection, | ||
+ | |||
+ | For instance, WinActivate now raises an error if the window does not exist. This could alert the user to a typo in the window title, or prevent the script from proceeding to send keystrokes to the wrong window (or whatever action comes next), perhaps averting disaster. | ||
+ | |||
+ | ====== Resources ====== | ||
+ | |||
+ | There are a great many resources available for learning AutoHotkey v1, such as tutorials, videos, blog posts and ready-made scripts. Even forum topics for past help requests are a valuable learning resource. All of this has been accumulating since AutoHotkey’s release over 18 years ago. | ||
+ | |||
+ | By comparison, there are much fewer resources available for learning v2. Although the first alpha was released in 2011, the syntax underwent multiple evolutions and lesser changes, so much of the code written prior to the release of v2.0-beta.1 in 2021 needs adjustment before it can be used. | ||
+ | |||
+ | Whether the relative lack of resources would be an issue for you depends on your learning style and how able you are to learn from the documentation. The documentation for both versions is comprehensive. | ||
+ | |||
+ | The only way to truly rectify the lack of resources is to increase the number of people generating resources for v2; writing code, tutorials and blog posts, making videos, and so on. Even just asking questions on the forums will help to generate content. If nothing else, more users means a larger audience for potential content authors. | ||
+ | |||
+ | Consider also the following: - Older resources may help you learn v1, but v1 itself may not be worth learning due to the obsolete parts of its [[# | ||
+ | |||
+ | ====== Tools ====== | ||
+ | |||
+ | Tools make writing scripts easier, especially editors with syntax highlighting, | ||
+ | |||
+ | Some popular tools for v1 have not yet been updated by their authors to support v2 syntax. If you’re familiar with those, you’ll already know how much value they hold for you. Otherwise, let me assure you that other tools which support v2 (or both versions) are more than adequate. | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | The [[# | ||
+ | |||
+ | ====== Future development ====== | ||
+ | |||
+ | Unlike v1.x, v2.x and future versions will follow semantic versioning. In other words, the feature set for v2.0 is locked in for all v2.0.x releases, with new features coming in v2.1, v2.2 and so on. As it was during the development of v2.0-alpha, new features will be progressively added to v2.1-alpha, allowing for changes up until the release of v2.1. To get an idea of what v2.1 might contain, see [[https:// | ||
+ | |||
+ | v2.x releases will be spaced apart (but nothing like the development of v2.0-alpha). Unlike the abrupt v1.1.x releases and sporadic test builds (that I assume most users ignored), this will hopefully ensure that new features will be put through more vigourous testing and actual use, avoiding major bugs on release day (as happened several times for v1.1.x releases). | ||
+ | |||
+ | As an example, v2.1-alpha will be expected to be compatible with v2.0, but features added in one alpha might be altered or removed in a later alpha, or might be deferred until v2.2 or a later release. This will hopefully promote progress, while still providing a stable platform for script authors to build on. | ||
+ | |||
+ | The additions in each release will be fairly significant, | ||
+ | |||
+ | ===== End of v1 ===== | ||
+ | |||
+ | Development of v1.x is expected to stagnate (or remain stagnant). The v2 code base has diverged quite a bit from v1, with over 2300 individual changes committed to the v2 branch (as of December 2022). This makes working on the v1 code unpleasant, and even fixing minor bugs across both versions requires tedious resolution of merge conflicts. Differences in how the two branches work has been a source of bugs. | ||
+ | |||
+ | v1.x is not expected to receive any new features, except possibly some that are planned to facilitate the transition to v2, or that might be utilized by external tools that support both versions (such as Ahk2Exe, editors and debuggers). Assume that any //feature requests// will not be implemented. | ||
+ | |||
+ | Pull requests for v1.x //may// be considered, but reviewing and/or merging them will not be a priority. | ||
+ | |||
+ | Of course, anyone with sufficient interest and motivation can develop their own fork of AutoHotkey v1 or v2. | ||
+ | |||
+ | ===== Unfulfilled potential ===== | ||
+ | |||
+ | There are some possible strategies for solving some of the problems of v1 without necessarily breaking compatibility with old scripts wholesale. For instance, opting in to certain changes, enabling expressions by default, or similar. However, simple changes would be insufficient, | ||