- I am *very* sympathetic to these kinds of concerns. I always ask myself re. AHK v2, 'is AutoHotkey still easy'.
- I think that AHK v2 will be less confusing for newbies.
- The key point about AHK v2 is that the new syntax is a subset of the old syntax. It's generally replacing two ways of doing things, with one way of doing things, removing ambiguity.
- I remember every difficulty I've had with AutoHotkey, and virtually every point has been addressed, with the situation simplified.
- 'StringReplace' to 'StrReplace' is hardly an issue.
- Shorter function names are easier to type.
- Narrower lines are easier to read.
- (I am somewhat sympathetic to the argument for fuller function/method names. IMO Java takes this too far, with ludicrously long method names e.g. lastIndexOf/toUnsignedString/equalsIgnoreCase. By contrast, C/C++ has some function names that are short but cryptic e.g. stoi. I think that 'Str' is readable yet short.)
- I regard StrReplace as the most difficult function to find good parameter names for.
- I.e. this is not specifically an AHK v2 issue.
- There are 4 key parameters.
- The terms 'old text', 'new text', 'search(ed) text' and 'replace(d) text' are ambiguous.
- However, the terms 'needle' and 'haystack' are unambiguous, from the phrase: (like looking for) a needle in a haystack.
NewStr: after/new text, output
Haystack: before/old text, input
SearchText: before/old text, needle, 'find what'
ReplaceText: after/new text, 'replace with'
COMMAND V. FUNCTION SYNTAX
Code: Select all
Cmd ReturnValue, Arg1, Arg2, Arg3
ReturnValue := Func(Arg1, Arg2, Arg3)
- The function syntax already existed in AHK v1. So you already needed to be able to understand it.
- I was familiar with it from Excel sheet functions. To me, when I started, commands seemed like the oddity.
Excel SUBSTITUTE Function
https://www.excelfunctions.net/excel-su ... ction.html
- I learnt AutoIt before AutoHotkey, and found the function syntax perfectly straightforward.
- A further issue with the AHK v1 command-style parameters is escaping characters like spaces/tabs/commas/percent signs, this gets messy fast and affects readability.
- With AHK v1 command parameters, I could never remember which one was input, which one was output. The return value (output) is always clear with functions.
- If AutoHotkey keeps command syntax, and introduces A_Result, you still have something quite simple:
Code: Select all
StringReplace NewStr, Haystack, %SearchTextVar%, %ReplaceTextVar%
StrReplace Haystack, SearchTextVar, ReplaceTextVar
NewStr := A_Result
StringReplace NewStr, Haystack, SearchTextLit, ReplaceTextLit
StrReplace Haystack, "SearchTextLit", "ReplaceTextLit"
NewStr := A_Result
- In terms of making things easy. IMO a difficult language with lots of examples, is easier than an easy language with few to no examples.
- So, for me, the focus should be on adding copious examples to the documentation, and on tutorials, particularly for the basic functions. (I can think of InStr, StrReplace, SubStr and Format. I'll do a full read-through of the documentation at some point.)
- I've recently completed matching beginner tutorials for C++/Java/Python, which I want to tidy a bit, and I'll be doing one for AutoHotkey presently.
- (Doing tutorials in other languages helped to make clear what experts from other languages might want. There's a danger of writing a tutorial based on the nature of the language, or on what can be done easily in the language, rather than based directly on what people want. It also reminded me of how newbies feel encountering a new language.)
- For me, the one thing that complicates a language is having to specify/convert/'cast' types, e.g. when defining variables, concatenating variables (in an expression) and (specifying parameters when) defining functions. It complicates everything and obscures the real code. This is why I find Python and AutoHotkey easy, and other, type-based, languages, difficult. This issue alone. In C++/Java, half the code deals with types.