Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

Discuss the future of the AutoHotkey language
SOTE
Posts: 654
Joined: 15 Jun 2015, 06:21

Will AutoHotkey v2 Syntax Be More Confusing For Newbies?

30 Sep 2018, 00:20

After a discussion with a friend, an interesting issue resulted. Is AutoHotkey Version 2 something that experienced or trained programmers find comforting, at the expensive of beginner and casual programmers? Let's look at various syntax. For example, String Replace (StrReplace() / StringReplace). I'm wondering if experienced or high level programmers forget what it's like to start out and not know programming.

Which is more easily readable and understandable? Arguably, Version 1 syntax is more easily understood.

The word StringReplace changed into StrReplace, then adding in "Haystack" can be confusing. So maybe there needs to be clarification about the syntax for version 2, when you no longer have the syntax of StringReplace and just StrReplace. And this goes for other such similar syntax changes.

Version 2 syntax-

Code: Select all

 ReplacedStr := StrReplace(Haystack, SearchText [, ReplaceText, OutputVarCount, Limit := -1])
Version 1 syntax-

Code: Select all

StringReplace, OutputVar, InputVar, SearchText [, ReplaceText, ReplaceAll]
I didn't realize this was even an issue, because even though I'm a casual user, I had become familiar with AutoHotkey over many months so the change in syntax wasn't so bothersome. However, when introducing the language to a friend who is a non-programmer, these "strange" syntax abbreviations and readability immediately became an issue for understanding.

Maybe part of this "confusion" can be alleviated in the help document, if it's felt that abbreviated wording must be used as keywords, by having the whole word String Replace at the top.

So a keyword lookup would look like
StrReplace (short for String Replace)
Last edited by SOTE on 01 Oct 2018, 01:34, edited 1 time in total.
User avatar
nnnik
Posts: 4187
Joined: 30 Sep 2013, 01:01
Location: Germany

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

30 Sep 2018, 02:01

Learning the syntax is a gradual process. While at the very begninning commands may be useful, you then have to completely relearn AutoHotkey when you switch to expressions.
Mayne people stop before that and thats neither good for us nor for them. So we decided to remove that hurdle.
Recommends AHK Studio
lexikos
Posts: 6397
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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

30 Sep 2018, 05:15

I'm not sure this is really a "new" topic.
SOTE wrote: Arguably, Version 1 syntax is more easily understood.
So you say, but haven't actually posed an argument as I see it. That is just subjective opinion. Many others have done the same, with very few giving a plausible explanation.

The legacy syntax might seem easier when all you do is call for some action with some literal keystrokes, window titles, etc, but anything more complex (and every new user comes across this very soon) requires learning new symbols - even before you get to expressions, with a new set of rules. What's worse is that the symbols aren't used consistently.

Legacy syntax does not put quote marks around plain text, but as a result requires markers around variables. Even just considering this much, I don't believe it is easier, except maybe for the absolute beginner before they do anything useful. But then this cascades into a whole lot of inconsistencies, and imposes limitations that seemingly are only solved by having a whole new set of rules that supersede the legacy syntax.

Learning to put literal text in quote marks is a very simple step, and trying to avoid it only complicates matters and makes things worse in the long run. The quoting convention should be fairly familiar to anyone who is literate, in English at least - quoting literal text in a program is like quoting anywhere else.

So I suppose that what I'm saying is that no, v1 syntax is not more easily understood - as a whole. And it certainly is not easier to learn.
The word StringReplace changed into StrReplace, then adding in "Haystack" can be confusing.
Documentation changes (including parameter names) can be submitted via GitHub or suggested in the forums. However, I don't really get your point.
However, when introducing the language to a friend who is a non-programmer, these "strange" syntax abbreviations and readability immediately became an issue for understanding.
I don't know about others (you referred to abbreviations in the plural) but Str is a very common abbreviation. That might not help users totally new to programming or scripting of any kind, but it should also be easy to pick up by just looking at the description of each function.

Learning programming of any kind requires some work. No one is going to just pick it up effortlessly and immediately.
User avatar
jeeswg
Posts: 6462
Joined: 19 Dec 2016, 01:58
Location: UK

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

30 Sep 2018, 05:48

- 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.

FUNCTION NAMING

- '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.)

PARAMETER NAMING

- 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.
- Possibilities:
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.

A_RESULT

- 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 GENERAL

- 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.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
guest3456
Posts: 2537
Joined: 09 Oct 2013, 10:31

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

30 Sep 2018, 19:22

if users find v2 too difficult, they can always continue to use v1

iseahound
Posts: 408
Joined: 13 Aug 2016, 21:04
GitHub: iseahound

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

30 Sep 2018, 20:02

Hey, this is very interesting because AutoHotkey is an automation based language. The key point about automation is that many actions are effectual, meaning that they may be non-deterministic, change state, and create effects. Many commands in v1 use command syntax to express this feeling such as the Run command, where depending on whether or not an executable is in the PATH will do the action or just fail. Click, X, Y again is an effect, since depending on what window is currently on the screen, will have a different outcome.

For commands with an OutputVar, function syntax is more natural. However, I think that v2 should accommodate both types of syntax to make it easier for beginning users, which make up the vast majority of our community.
SOTE
Posts: 654
Joined: 15 Jun 2015, 06:21

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

01 Oct 2018, 02:10

iseahound wrote:Hey, this is very interesting because AutoHotkey is an automation based language. The key point about automation is that many actions are effectual, meaning that they may be non-deterministic, change state, and create effects. Many commands in v1 use command syntax to express this feeling such as the Run command, where depending on whether or not an executable is in the PATH will do the action or just fail. Click, X, Y again is an effect, since depending on what window is currently on the screen, will have a different outcome.

For commands with an OutputVar, function syntax is more natural. However, I think that v2 should accommodate both types of syntax to make it easier for beginning users, which make up the vast majority of our community.
iseahound, I think you are understanding the spirit of what I mean. Because AutoHotkey has an automation base, there is likely more of an expectation of 1 to 1, cause and effect. Click this, than do this. See this, than do that. And AutoHotkey has a syntax that more strongly reflects this, arguably making it much easier for non-programmers to pick up and use much more quickly than other programming languages.

Code: Select all

StringSplit, OutputArray, InputVar [, Delimiters, OmitChars]
The version 1 syntax above has a great level of readability, for non-programmers and is closer to normal English. The more that a scripting language begins to drift away from more easily understood languge, possibly the more difficult it can be to understand. So when confronted with version 2 syntax, like below, it's more likely to produce head scratching.

Code: Select all

Array := StrSplit(String [, Delimiters, OmitChars, MaxParts := -1])
It's not to say that a learning curve can be eliminated or that the language can always or easily describe what is complex, but rather how easy it is to understand a language can effect outcomes and use.
Last edited by SOTE on 01 Oct 2018, 02:21, edited 3 times in total.
SOTE
Posts: 654
Joined: 15 Jun 2015, 06:21

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

01 Oct 2018, 02:11

lexikos wrote:I'm not sure this is really a "new" topic.
SOTE wrote: Arguably, Version 1 syntax is more easily understood.
So you say, but haven't actually posed an argument as I see it. That is just subjective opinion. Many others have done the same, with very few giving a plausible explanation.

The legacy syntax might seem easier when all you do is call for some action with some literal keystrokes, window titles, etc, but anything more complex (and every new user comes across this very soon) requires learning new symbols - even before you get to expressions, with a new set of rules. What's worse is that the symbols aren't used consistently.

Legacy syntax does not put quote marks around plain text, but as a result requires markers around variables. Even just considering this much, I don't believe it is easier, except maybe for the absolute beginner before they do anything useful. But then this cascades into a whole lot of inconsistencies, and imposes limitations that seemingly are only solved by having a whole new set of rules that supersede the legacy syntax.

Learning to put literal text in quote marks is a very simple step, and trying to avoid it only complicates matters and makes things worse in the long run. The quoting convention should be fairly familiar to anyone who is literate, in English at least - quoting literal text in a program is like quoting anywhere else.

So I suppose that what I'm saying is that no, v1 syntax is not more easily understood - as a whole. And it certainly is not easier to learn.
The word StringReplace changed into StrReplace, then adding in "Haystack" can be confusing.
Documentation changes (including parameter names) can be submitted via GitHub or suggested in the forums. However, I don't really get your point.
However, when introducing the language to a friend who is a non-programmer, these "strange" syntax abbreviations and readability immediately became an issue for understanding.
I don't know about others (you referred to abbreviations in the plural) but Str is a very common abbreviation. That might not help users totally new to programming or scripting of any kind, but it should also be easy to pick up by just looking at the description of each function.

Learning programming of any kind requires some work. No one is going to just pick it up effortlessly and immediately.
lexikos, don't get me wrong, I think what you have done is fantastic (to include expanding the capabilities of AutoHotkey) and I'm a fan. And you are right, such observations are quite subjective, to include that version 1 syntax has plenty of flaws with it. However, the point was to mention it, and maybe look again at the perspective of non-programmers and new people. And I also agree that the help documentation and GitHub submissions can mitigate such issues somewhat. Personally, I find the short examples and programming snippets do the most to help.
Last edited by SOTE on 01 Oct 2018, 02:29, edited 2 times in total.
lexikos
Posts: 6397
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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

01 Oct 2018, 04:28

SOTE wrote:However, the point was to mention it, and maybe look again at the perspective of non-programmers and new people.
So you've mentioned it, and nothing has changed. Unless someone can offer a new perspective, regardless of their level of experience, this is futile.

"Non-programmers and new people" are not the right people to be designing a language, even for "non-programmers and new people", and the rest of us cannot pretend to be new. That aside, a language that only non-programmers would use will have no developers, and will go nowhere.
lexikos
Posts: 6397
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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

01 Oct 2018, 05:58

Apparently I missed some posts. I also got a server error but apparently posted twice (which is twice more than I thought). I've deleted the duplicate.

I believe that the v1 syntax being "easier" to read for beginners or closer to English is only superficial, if even true, and offers no real benefit.
User avatar
jeeswg
Posts: 6462
Joined: 19 Dec 2016, 01:58
Location: UK

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

03 Oct 2018, 21:12

- @SOTE: I think on balance AHK v2 is easier:

Code: Select all

;AHK v1:
Cmd %var%
Cmd string
Cmd % 1 + 1

;AHK v2:
Cmd var
Cmd "string"
Cmd 1 + 1

;AHK v1/v2:
Func(var)
Func("string")
Func(1 + 1)
- Your argument seems to be:

Code: Select all

;easy:
Cmd Output, Input

;hard:
Output := Func(Input)
- This is the only bit of syntax you've really mentioned.
- I can appreciate that the first one arguably does look a little less daunting to a newbie.
- However, there's still a learning curve for the first one.
- And, the second one, if you're honest, is pretty straightforward.
- (There's the which is input/output disadvantage for commands, which I mentioned before.)
- (Also, functions are necessary in AHK e.g. for expressions/one-liners, and are commonplace elsewhere e.g. Excel. Better to introduce it well, than to delay introducing it.)

- If you used command-style notation here, would it really make things easier?
- Whether commands or functions were used, I think the key is a good example.

Code: Select all

;==================================================

;replace 'abc' with '___'

vText := "abcdef"
vTextNew := StrReplace(vText, "abc", "___")
MsgBox(vText "`r`n" vTextNew)

;==================================================

;split a string to create a (linear) array

vText := "abc,def,ghi"
oArray := StrSplit(vText, ",")
MsgBox(vText "`r`n" oArray[1] "`r`n" oArray[2] "`r`n" oArray[3])

;==================================================

;count the items in an array

MsgBox(oArray.Count())

;==================================================
- How many languages use commands as in AHK v1?
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
roysubs
Posts: 168
Joined: 29 Sep 2018, 16:37

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

06 Oct 2018, 13:00

Everything I've seen of v2 is massively better. I found v1 *extremely* confusing when I started. v2 will be easier to get into with a more sensible syntax.
I'm very excited for AutoHotkey v2 to be finalised soon!
User avatar
jeeswg
Posts: 6462
Joined: 19 Dec 2016, 01:58
Location: UK

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

15 Mar 2019, 11:43

- I came across this video which talked about using user data to determine the qualities of a simple language.
"Evidence-Oriented Programming" by Andreas Stefik - YouTube
https://www.youtube.com/watch?v=uEFrE6cgVNY

- The results are this, and it's pretty similar to AutoHotkey v2, and more like AutoHotkey v2 than AutoHotkey v1:
Quorum Reference Pages - Quorum Programming Language
https://quorumlanguage.com/reference.html
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
SOTE
Posts: 654
Joined: 15 Jun 2015, 06:21

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

15 Mar 2019, 12:57

I think that AutoHotkey can take some hints from 2 languages that are syntactically similar. WinBatch (manual of the language for comparison- http://techsupt.winbatch.com/techsupt/PDFs/wil-lang20170412.pdf) and JavaScript (https://www.w3schools.com/js/js_syntax.asp). With the included advantage that AutoHotkey can see what did or didn't work in other languages, and what might be the easier way to do things.

Despite AutoHotkey's obvious connection to AutoIt, I think they went off the rails a bit, and went way too heavily into making it Visual Basic like. The exact percentage will probably never be known, but it does seem a lot of people switched over to AutoHotkey, after AutoIt v3 was released due to dislike of the syntax changes.

AutoHotkey keeps a more C language family syntax, which makes more sense, especially with a C++ interpreter. And it's somewhat likely that advanced or power users of AutoHotkey will eventually use C/C++ and/or JavaScript. Somehow, AutoHotkey has flavors of Pascal in it too (:=), which is probably for the best, as Pascal was arguably designed for or is more well suited for teaching programming.

Syntax understanding problems with AHK v2 can possibly be rectified to a large extent by a better help manual, explaining the syntax more clearly. Something the granddaddy automation language, WinBatch, arguably does. My point was to bring attention to the clarity of syntax used, and not forget how easy AHK v1 syntax often is to understand. The more cryptic the syntax is made, arguably the more difficult it will be for non-programmers to understand and use it.

Another point is "new" doesn't always mean better. Python, for example, appeared to have created a mess for itself for a very long time (debatably still so) and fractured it's community over the changes from 2 to 3. When new syntax is picked, the reasoning behind it should debatably be clear, and well understood why it's needed among the community.

What compelling reason or incentives are there to use AHK v2, if it's harder to understand and/or the code does the same as AHK v1? To include so much user contributed code and examples being in AHK v1. It's perhaps something to think about.
swagfag
Posts: 2610
Joined: 11 Jan 2017, 17:59

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

15 Mar 2019, 14:40

what do u find cryptic about v2's syntax? if anything, command syntax should be completely done away with. there, v2 just got way easier. no more need to be aware of/learn a separate syntax that isnt even universally applicable. what an utter waste of time that would have been!

has it been established that v2 is harder to understand? from what i see so far, u have one user suggesting the very opposite

the compelling reason to use v2 is the modernized syntax, access to new features, streamlining/disposal of tacked on historical backwardscompatibility gobbledygook
the compelling reason not to use v2 is, as u say, the availability of libraries, or specifically, lack thereof
SOTE
Posts: 654
Joined: 15 Jun 2015, 06:21

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

15 Mar 2019, 17:06

swagfag wrote:
15 Mar 2019, 14:40
what do u find cryptic about v2's syntax? if anything, command syntax should be completely done away with. there, v2 just got way easier. no more need to be aware of/learn a separate syntax that isnt even universally applicable. what an utter waste of time that would have been!

has it been established that v2 is harder to understand? from what i see so far, u have one user suggesting the very opposite

the compelling reason to use v2 is the modernized syntax, access to new features, streamlining/disposal of tacked on historical backwardscompatibility gobbledygook
the compelling reason not to use v2 is, as u say, the availability of libraries, or specifically, lack thereof
Hmmmm...

Let's take ControlGet for example. In AHK v1 it's much more compact, where the majority of features are in the sub-command. Where in AHK v2, this is distributed over a wider range of functions, but the syntax style varies.

For example, from AHK v1:

ControlGet, OutputVar, SubCommand , Value, Control, WinTitle, WinText, ExcludeTitle, ExcludeText

ControlGetPos , X, Y, Width, Height, Control, WinTitle, WinText, ExcludeTitle, ExcludeText

For example, from AHK v2:

IsEnabled := ControlGetEnabled(Control , WinTitle, WinText, ExcludeTitle, ExcludeText)

ControlGetPos X, Y, Width, Height, Control, WinTitle, WinText, ExcludeTitle, ExcludeText

So, what is the general user gaining in AHK v2 from this?

And, AHK v1 has a lot of syntax added to it, so you have the strange convenience of dual syntax. A state of syntax duality, which has existed for years now, thus allowing the interesting convenience of either type of syntax to be chosen. I've seen this in use too many times to count on the help forum.

Array := StrSplit(String , Delimiters, OmitChars, MaxParts := -1)

StringSplit, OutputArray, InputVar , Delimiters, OmitChars

This also creates the argument of why not just keep updating AHK v1 (to include newer syntax) and AHK v2, until they "feature or syntax merge". Which is basically what has been happening. Which would be the argument of not accelerating jumping to AHK v2 and causing pain for the majority, but allowing the slow merge to continue, where jumping between the two versions would become quite minor.

The state has existed, where those interested in AHK v2, have chose to use it. And those fine with AHK v1, have continued to use it (which looks to be the majority). AHK v2 doesn't seem to have generated such level of interest or libraries, yet. Where AHK v1 is still significantly backwards compatible with AHK_Basic, and has a large collection of user contributed scripts.

The other elephant in the room is if Lexikos doesn't or is unable to return. There is a good argument of continuing with AHK v1 and adding the new features into it. The deprecated syntax could be hidden, instead of dropped, thus allowing a degree of backward compatibility until agreed it's no longer needed or wanted. Though I will add, I've nothing particularly against AHK v2, except that it's unfinished and still Alpha. If there is going to be a switch, I would think a more polished and stable version should be it, which is supported by AHK Studio and AutoGUI (at the very least). Let's not forget the tools that many use to write scripts with.
User avatar
kczx3
Posts: 833
Joined: 06 Oct 2015, 21:39

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

15 Mar 2019, 18:51

For me, v2 became massively better with GUI objects. Then when fat arrow expressions and nested functions came out, I was completely sold. Anything new that I write is done in v2
swagfag
Posts: 2610
Joined: 11 Jan 2017, 17:59

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

15 Mar 2019, 19:03

idk how u determined v1's ControlGet to be the more compact one. to me, neither seems particularly compact in comparison to its counterpart
heres what the user is gaining with v2's function versions:
  • the freedom of choice of capturing the result in a variable or consuming it rightaway - lingering, one-time-use-only variables can introduce bugs, so their creation is to be minimized
  • consistency across the board and assurance that unquoted == variable, quoted == string and %percentsurrounded% == variable deref - no more of v1's "some fields are legacy but also accept expressions, ooops nvm, except for these ones that dont lol, gl remembering them/skimming the docs". no more of v1's "spam % everywhere, y'know, just to make sure"
  • the ability to use objects as parameters(. member access and [] subscript operators), without having to enable forced-expression mode
  • u see how in a bunch of the boolean return commands u gotta remember to do ControlGet, OutputVar, CMD >>>>>[,,<<<<< Control, WinTitle, WinText, ExcludeTitle, ExcludeText]. yeah, well no more of that in v2
tbh im not entirely convinced this example with the control functions does v2 much justice. if command syntax had been done away with and there no longer was a need to keep parity between the function/command syntaxes, i believe lexikos would have further streamlined the interface of these functions. the void return and byref functions strike me as particularly odd. it is evident they were made this way only to reflect their command counterparts, otherwise they dont make any sense.

i dont know the exact reason why, but what ure proposing is not feasible. v1 cant be updated in this gradual fashion. i think it had something to do with tons of backwardscompatibility and other hacks having made their way into the codebase, which makes it hard to easily change stuff. it would be easier to rewrite instead.

hiding deprecated stuff is proven not to work, u have to outright break it, if u want people to stop using deprecated features. otherwise, theyd just randomly discover the features or just copy-paste and not know any better

im not going to contest the point about the tooling
SOTE
Posts: 654
Joined: 15 Jun 2015, 06:21

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

15 Mar 2019, 20:29

swagfag wrote:
15 Mar 2019, 19:03
im not going to contest the point about the tooling
Yeah, because while various people are pushing to jump to AHK v2, the authors of AHK Studio and AutoGUI don't appear to be so enthusiastic to rewrite their programs or accommodate, nor are there any AHK v2 tools written by different coders to be a replacement. That's no small issue. What arguably allows AutoHotkey to be a viable tool to write programs with, are the tools it comes with, and preferably written in the same language. Perhaps this situation should be looked at more holistically.
hiding deprecated stuff is proven not to work, u have to outright break it, if u want people to stop using deprecated features. otherwise, theyd just randomly discover the features or just copy-paste and not know any better
Hmmm... Not sure about that, because it's kind of the existing situation now. Many of the commands and older syntax have been deprecated for quite some time now. Hiding them would arguably just be the next phase of letting people know they are going and helping people to switch over, but allowing for various situations. I'm not seeing the necessity of a sudden break or creating anymore pain than necessary in a transition. I think a sudden break, will do more harm than good. Especially, since the new tools and libraries to support and incentivize a transition are arguably lacking.
User avatar
nnnik
Posts: 4187
Joined: 30 Sep 2013, 01:01
Location: Germany

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

16 Mar 2019, 05:14

Yeah, because while various people are pushing to jump to AHK v2, the authors of AHK Studio and AutoGUI don't appear to be so enthusiastic to rewrite their programs or accommodate, nor are there any AHK v2 tools written by different coders to be a replacement. That's no small issue. What arguably allows AutoHotkey to be a viable tool to write programs with, are the tools it comes with, and preferably written in the same language. Perhaps this situation should be looked at more holistically.
I have a compiled version of AHK Studio - thats one of the features it offers.
That way I can edit any AHK Script while I have any AHK version installed.
Of course they arent enthusiastic about switching to v2 because v2 still isnt finished yet.
Recommends AHK Studio

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 4 guests