Will v2 ever hit the stable state?

Discuss the future of the AutoHotkey language
AHK_user
Posts: 515
Joined: 04 Dec 2015, 14:52
Location: Belgium

Re: Will v2 ever hit the stable state?

Post by AHK_user » 02 Sep 2022, 12:12

Helgef wrote:
02 Sep 2022, 06:31
No, v2 isn't backwards compatible.

@SOTE, I genuinely just wonder why @submeg wants to covert 30000 lines of v1 code to v2.

Cheers.
I can understand why, If you want to further develop the script in V2.

iseahound
Posts: 1427
Joined: 13 Aug 2016, 21:04
Contact:

Re: Will v2 ever hit the stable state?

Post by iseahound » 02 Sep 2022, 19:20

In case anyone is wondering about the actual question posed:

v2 is stable, as I have converted most of my scripts

Some observations:
  • TargetWindow does not exist is a very common error. Much of the time, this requires refactoring that will improve the reliability and quality of the code.
  • Many helper functions can either be nested inside an existing function or made anonymous vis the fat arrow syntax.
  • Callbacks are greatly simplified, and thus should be relied on to improve scripts.
  • Command statements that formerly had an OutputVar parameter no longer need their own line. For example, MsgBox WinGetClass("ahk_id" hwnd) is a one liner now.
  • As a result, many separate lines can now be condensed into a single line of code. WinWait(hwnd) && WinActivate(hwnd)
  • Errors in general are much more helpful and can be used to guide development. Specifically the UnsetError which catches typos will save many hours.
The main benefits are a reduction in lines of code, a reduction in local variables formerly from OutPutVar, a reduction in named functions since () => () is great for functions that are only used once. This leads to cleaner, more consistent code, that is easier to maintain and understand.

SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Will v2 ever hit the stable state?

Post by SOTE » 03 Sep 2022, 04:05

iseahound wrote:
02 Sep 2022, 19:20
In case anyone is wondering about the actual question posed:
Yes, you are correct, AHK v2 is relatively stable. But, the OP (swq), asked several other questions and expressed a number of concerns. His other questions and concerns are relevant too.
swq wrote:
09 Jul 2022, 13:57
...It took so many years and there are still programs and libraries that didn't transition to newer version. What's worse I think syntax difference (not to mention radical change in language philosophy) in AHK v2 is much much bigger than it was in Python.
1) It is quite correct, that a number of AHK v1.1 libraries that various people use will probably never get translated to AHK v2.

There are AHK v1.1 to AHK v2 translators to help the process, but it can be the original authors moved on or feel it would be too much work based on their present life situation. To add to this, there are AHK v2 libraries that are not available to AHK v1.1. Where in other cases there are libraries that have both AHK v1.1 and AHK v2 versions. For some users, what they feel is best for them, can be a bit complicated. For some there might be various AHK v2 libraries or features that they must have, where with others there isn't or they are fine with what they have in AHK v1.1 for now.

2) How significant the differences are between AHK v1.1 and AHK v2 depends on the person and likely their programming experience and time they can invest.

The point that some were making, is various people don't want to deal with different versions of AHK at the same time. Some don't want to go back and forth between versions, while with others they don't mind doing that. For various people, they prefer to choose one or the other. If/when they decide to go with AHK v2, it will be both a significant and permanent move for them. As in, they will translate all their scripts from AHK v1.1 to AHK v2, so that they will keep in their minds, maintain, and update only a single version.

The timing of when such people will decide on making a permanent migration to the newer version, depends on many factors. It can be they are perfectly comfortable with AHK v1.1, based on their present needs and availability of libraries and help, despite AHK v2 being superior in various ways. Where with others, they will be jumping back and forth between AHK v1.1 and AHK v2 for all kinds of reasons, so their transition could be in various small steps versus one major transition at a designated time.

byzod
Posts: 87
Joined: 21 Jun 2021, 06:46

Re: Will v2 ever hit the stable state?

Post by byzod » 03 Sep 2022, 23:50

iseahound wrote:
02 Sep 2022, 19:20
In case anyone is wondering about the actual question posed:

v2 is stable, as I have converted most of my scripts

Some observations:
  • TargetWindow does not exist is a very common error. Much of the time, this requires refactoring that will improve the reliability and quality of the code.
  • Many helper functions can either be nested inside an existing function or made anonymous vis the fat arrow syntax.
  • Callbacks are greatly simplified, and thus should be relied on to improve scripts.
  • Command statements that formerly had an OutputVar parameter no longer need their own line. For example, MsgBox WinGetClass("ahk_id" hwnd) is a one liner now.
  • As a result, many separate lines can now be condensed into a single line of code. WinWait(hwnd) && WinActivate(hwnd)
  • Errors in general are much more helpful and can be used to guide development. Specifically the UnsetError which catches typos will save many hours.
The main benefits are a reduction in lines of code, a reduction in local variables formerly from OutPutVar, a reduction in named functions since () => () is great for functions that are only used once. This leads to cleaner, more consistent code, that is easier to maintain and understand.
I'm considering convert my scripts to v2 too, the mixed syntax of v1 is ridiculous tbh
But the main problem that I concerned about is the libraries, v2 can't include library written with v1 syntax while I don't have sufficient skill or time to convert those myself

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Will v2 ever hit the stable state?

Post by lexikos » 04 Sep 2022, 03:05

When it comes to the future of AutoHotkey, whether it is v1 or v2, I think there has been far too much time spent debating problems and not enough on creating solutions.

hpta
Posts: 24
Joined: 27 Sep 2019, 01:43

Re: Will v2 ever hit the stable state?

Post by hpta » 09 Sep 2022, 03:30

byzod wrote:
03 Sep 2022, 23:50

But the main problem that I concerned about is the libraries, v2 can't include library written with v1 syntax while I don't have sufficient skill or time to convert those myself
I think in some cases you can deal with it like this in your v2 script:

Code: Select all

shell := ComObjCreate("WScript.Shell")
exec := shell.Exec("ahk1_executable.exe ahk1_script.ahk" )
exec.StdIn.WriteLine()
output_var := exec.StdOut.ReadAll()
and in the ahk1_script.ahk you send something relevant to the StdOut, like this:

Code: Select all

FileAppend , % output_var, *

User avatar
thqby
Posts: 391
Joined: 16 Apr 2021, 11:18
Contact:

Re: Will v2 ever hit the stable state?

Post by thqby » 09 Sep 2022, 07:18

viewtopic.php?f=83&t=98890&p=439179&hilit=v1lib#p439179
@byzod
This is also a way to call the V1 library across processes.

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Will v2 ever hit the stable state?

Post by lexikos » 09 Sep 2022, 19:04

One can also run v1 libraries in-process with AutoHotkey.dll.

The usage of an "imported" function or class can be the same as a native v2 one, except that they are essentially COM objects. Any objects passed between the two versions won't work like native objects (such as with for loops), but that shouldn't be surprising since the two versions aren't inherently compatible anyway.

Tensai
Posts: 29
Joined: 12 Dec 2019, 14:15

Re: Will v2 ever hit the stable state?

Post by Tensai » 09 Sep 2022, 22:13

It would be incredible if the #Requires directive could transition between interpreters.
Spoiler
I realize of course this is easier said than done, and v2 is meant to shed the plethora of v1 issues, thus self-defeating. If the v1 code isn’t clean it would certainly lead to debug nightmares and newbie confusion.
I personally would only use it for libraries, which is essentially what I’ve been doing with thqby’s function.
Perhaps the UX Launcher could be designed in a way to integrate dual launching v1/v2? Hope this sparks some ideas! ;)
Spoiler

User avatar
RaptorX
Posts: 368
Joined: 06 Dec 2014, 14:27
Contact:

Re: Will v2 ever hit the stable state?

Post by RaptorX » 17 Sep 2022, 12:32

To answer the main question:
In my opinion v2 is already stable enough for making the switch (if you can) and I cant wait for it to go mainstream.

Regarding when will that happen?
well, only Lexikos has the answer to that, but as far as I can tell, he is very active on the project atm, so hopefully soon.

For those scared of switching and not in special cases of having thousands of lines of code to convert or being in business settings with conditions and restrictions I would say that I found the switch to be a no brainer. The syntax is NOT that different. You can definitely understand v2 if you understand v1.
Click to see my experience and "solutions" to the most common problems you might encounter if you decide to switch.
Projects:
AHK-ToolKit

User avatar
submeg
Posts: 326
Joined: 14 Apr 2017, 20:39
Contact:

Re: Will v2 ever hit the stable state?

Post by submeg » 25 Sep 2022, 22:45

Helgef wrote:
02 Sep 2022, 06:31
No, v2 isn't backwards compatible.

@SOTE, I genuinely just wonder why @submeg wants to covert 30000 lines of v1 code to v2.

Cheers.
@Helgef, it's pretty much summed up below:
For those using v1 scripts, a significant percentage may feel a strong urge or pressure to convert them over because of also not wanting to be bothered with keeping different ways and conflicting versions in their mind. The situation could be viewed more as a permanent migration over to the new version, versus attempting to "dip their toes" or go back and forth between versions.
The other reason is that, if I start updating / creating additional code that is sitting in a main file that is all written in v1, will AHK be able to interpret both concurrently?
____________________________________
Check out my site, submeg.com
Connect with me on LinkedIn
Courses on AutoHotkey :ugeek:

User avatar
RaptorX
Posts: 368
Joined: 06 Dec 2014, 14:27
Contact:

Re: Will v2 ever hit the stable state?

Post by RaptorX » 26 Sep 2022, 09:49

submeg wrote:
25 Sep 2022, 22:45
The other reason is that, if I start updating / creating additional code that is sitting in a main file that is all written in v1, will AHK be able to interpret both concurrently?
No, it would interpret a full v1 script OR a full v2 script. Not a mix of both.
Projects:
AHK-ToolKit

User avatar
submeg
Posts: 326
Joined: 14 Apr 2017, 20:39
Contact:

Re: Will v2 ever hit the stable state?

Post by submeg » 27 Sep 2022, 17:26

RaptorX wrote:
26 Sep 2022, 09:49
submeg wrote:
25 Sep 2022, 22:45
The other reason is that, if I start updating / creating additional code that is sitting in a main file that is all written in v1, will AHK be able to interpret both concurrently?
No, it would interpret a full v1 script OR a full v2 script. Not a mix of both.
Makes sense. That's why I'd like to shift my code across, so I get used to coding in v2, as opposed to v1.
____________________________________
Check out my site, submeg.com
Connect with me on LinkedIn
Courses on AutoHotkey :ugeek:

User avatar
dJeePe
Posts: 20
Joined: 21 Oct 2022, 08:53

Re: Will v2 ever hit the stable state?

Post by dJeePe » 26 Oct 2022, 07:44

For me, V1 is a scripting tool, V2 is more like a "modern" language

I may be an extremist but I think that people should be forced to migrate

Don't forget this about gmail : Released on April 1, 2004, it was still in beta five years and tens of millions of users later.

User avatar
boiler
Posts: 16705
Joined: 21 Dec 2014, 02:44

Re: Will v2 ever hit the stable state?

Post by boiler » 26 Oct 2022, 08:17

dJeePe wrote: I may be an extremist but I think that people should be forced to migrate
“Extremist” is right. Why would it ever make sense to force anyone to do anything (as if that could be done)? How arrogant it would be to decide what’s best for everyone.

People are always welcome to use any version that best suits them, going back to 1.0.x. The question being discussed is when/how v2 would become the primary version — not whether to make prior versions unavailable.

User avatar
dJeePe
Posts: 20
Joined: 21 Oct 2022, 08:53

Re: Will v2 ever hit the stable state?

Post by dJeePe » 27 Oct 2022, 07:19

Why are so many people still using V1?
because of the "beta" sticker on v2?

The contributions of v2 (i mean thing you can't do with V1) should be important enought to "force" the migration (at least not to make new scripts in v1)

User avatar
boiler
Posts: 16705
Joined: 21 Dec 2014, 02:44

Re: Will v2 ever hit the stable state?

Post by boiler » 27 Oct 2022, 07:27

dJeePe wrote: Why are so many people still using V1?
because of the "beta" sticker on v2?

The contributions of v2 (i mean thing you can't do with V1) should be important enought to "force" the migration (at least not to make new scripts in v1)
That’s a very myopic view. For me, this is the reason.


User avatar
boiler
Posts: 16705
Joined: 21 Dec 2014, 02:44

Re: Will v2 ever hit the stable state?

Post by boiler » 27 Oct 2022, 08:12

None of the issues discussed in that article are applicable to this situation.

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

Re: Will v2 ever hit the stable state?

Post by guest3456 » 30 Oct 2022, 10:05

dJeePe wrote:
27 Oct 2022, 07:57
The cost of legacy code is so underrated ...

https://www.diffblue.com/blog/2019/7/4/the-hidden-costs-of-legacy-code-and-how-to-fix-them
yeah, no

allow me to post a real link

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

one of my apps with hundreds of end users still uses AHK Basic 1.0


Post Reply

Return to “AutoHotkey Development”