AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

Get help with using AutoHotkey (v1.1 and older) and its commands and hotkeys
omar
Posts: 539
Joined: 22 Oct 2015, 17:56

AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

16 Jan 2019, 19:06

What are these 3?
Should I be looking into these?
I just use whatever the latest version standard download is.

Would be good to know if others are worth a look.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

16 Jan 2019, 20:17

  • ahk_l v1
    • pros
      • a lot of libraries have been written for it
      • ull find the most reading material for it
    • cons
      • wont get new features
      • bad gui system
      • a lot of idiosyncrasies u have to keep track of
  • ahk_l v2
    • pros
      • will keep getting newer features still(heres to hoping)
      • good gui system
      • less idiosyncrasies
      • faster to develop with if u know what ure doing
    • cons
      • not many libraries are ported to v2, possibly ull have to port them urself
      • ull have to apply urself a bit more(less copy pasting ready made code, since theres less of it going around)
  • ahk_h v2 - all of ahk_l v2, plus:
    • pros
      • multithreading
      • a lot of nice qol features
      • winapi integration
      • easier time working with dlls
    • cons
      • ull have to figure out a lot of shit urself before it clicks
      • somethings might be buggy(but they get fixed fast)
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

16 Jan 2019, 22:11

Swagfag, I would have to strongly disagree with you about AutoHotkey_L's (v1) GUI system and some other points about that version.

. The GUI system used by AutoHotkey_L (v1) is among the easiest to understand and use of any programming language. In fact, it's partially why I picked it over AutoIt and WinBatch, and a couple friends of mine (who are in IT and we had numerous discussions about which scripting languages to use) also felt the same way at that time (was a few years ago).

. The GUI system of AutoHotkey2 (v2) is from a more Object-Orientated Programming perspective (OOP) vs procedural programming style (AutoHotkey_Basic).

Though it can be argued that the AutoHotkey2 GUI system is as easy to understand and use, it's more of an OOP style, which can create confusion or difficulty for those less familiar with that style or with OOP concepts in general.

And there is a lot of academic debate now about OOP VS Procedural programming, where OOP creates confusion, unnecessary, or messy code versus doing things more simply and procedurally. This debate spills over into Functional vs Procedural style programming too, though much less so, but the point often is still about doing things simply versus making things unnecessarily complex.

. AutoHotkey2 (v2) will likely be more difficult for non-programmers and novices to understand initially (who arguably are the target user group), though it might make more experienced programmers from other programming languages feel more comfortable as some features and OOP concepts might be more familiar to them (particularly if exposed to years of OOP style in school).

. A lot of the idiosyncrasy arguments about AutoHotkey mostly came about in regards to "=" vs ":=" vs "%variable%. Often this was a lot of fuss over nothing, because Microsoft Windows has long used %% percent signs around variables in .bat files, environmental variables, etc... So many IT people that use Windows, would already seen... %variable%

The Pascal and ALGOL programming languages have long used ":=" for assignment versus "=" for an equality test, so to cry about AutoHotkey doing it, is to perhaps not realize that it's used in other programming languages or to cry about AutoHotkey doing something different from the programming language such people are familiar with. It takes just a bit of looking into the AutoHotkey documents to understand X = %variable% versus X := variable.

And in regards to syntax, it's often a matter of preference. So if a person prefers Pascal, C++, or Perl syntax they might be strongly bias against syntax in a different language, where they do things differently. I think that is where some of the inappropriate and unwarranted "disdain" towards AutoHotkey syntax was coming from (though some of it seems to be plain AutoIt VS AutoHotkey drama), and from those who were already programmers from other languages and more set in their ways and thinking. But in regards to AutoHotkey, the stronger argument is ease of use. Is the syntax easy to understand and use for novices and non-programmers, who are the most likely to use the scripting language to do some task? AutoHotkey_Basic excelled at being easy to use, with AutoHotkey_L (v1) mostly continuing that trend.

. Arguably there is less material written in AutoHotkey2, because it is embraced by and used by less people, to include that it breaks old scripts and introduces more difficulty. Also add that it is still in Alpha and more experimental.

. Agree with a lot of your comments in regards to AutoHotkey_H
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

17 Jan 2019, 01:00

v1's gui system is the easiest to understand and use, if all ure doing is updating static text. the moment u try doing something more involved than that, ull quickly realize its anything but.

i dont think v2 is more difficult for noobs. id rather they waste more time upfront learning the 1 way to call a function or type a string and be done with it, than wonder every time "oh is it expression now, is it not", or even worse yet - go on blissfully unware of the distinction, running a buggy script, because eveything failed silently

the idiosyncracy comment was aimed at other things, but percent signs do comprise part of it. simply put theres too many ways of doing things with no consistency amongst them. this is what makes things difficult for noobs. "u can use expressions here here and here, but not here", "but u can use them in <this_other_semi_related_thing>", and that goes for other things as well. why does settimer require i pass it a plain variable reference to a function object. if var is type doesnt work with expressions. click doesnt work with expressions. "oh wait whats that? it does?" click % x ", " y LOL. i get why these things are the way they are, but the point is, in an ideal world, they shouldnt have to be

= vs := for assignment is a nonissue. the issue is, pick one dammit! otherwise u can make the eggplant emoji the assignment operator, for all i care. and ill tell u something about "disdain". heres what "disdain" looks like: mylegacyvar = %ha%ha%look%%ma%I%did%%it%%babby%s%first%concat. did u manage to pick out the vars? hope ur syntax highlighter didnt just shit itself. AutoIT's unsightly dollar sign spam is on par with this

yeah v2 breaks old scripts. so, run ur old scripts with v1, and write ur new ones with v2, i dont see the problem there. the difficulty lies in learning something different from scratch, but v2 in and of itself isnt any more difficult than v1 is

e: i recall some time ago a user made this super hugeass post about everything wrong with v1, ill see if i can dig it up
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

17 Jan 2019, 01:40

swagfag wrote:
17 Jan 2019, 01:00
v1's gui system is the easiest to understand and use, if all ure doing is updating static text. the moment u try doing something more involved than that, ull quickly realize its anything but.

= vs := for assignment is a nonissue. the issue is, pick one dammit! otherwise u can make the eggplant emoji the assignment operator, for all i care. and ill tell u something about "disdain". heres what "disdain" looks like: mylegacyvar = %ha%ha%look%%ma%I%did%%it%%babby%s%first%concat. did u manage to pick out the vars? hope ur syntax highlighter didnt just shit itself. AutoIT's unsightly dollar sign spam is on par with this
But why must we be forced to pick one over the other? The Pascal programming language uses both = vs :=. := is the assignment operator and = is the equality operator. And why not :=, when you have all kinds of <<=, >>=, .=, ~=, *=, +=, etc... Seems strange to single out one, but not the other dozen assignments... I've not seen any Delphi or Pascal programmers crying about it. If anything, they are happy and quick to explain the distinction and why.

I find AutoHotkey following a bit of Pascal (with it's long history and reputation as an easier language to learn) as a good thing. Debatably, this allows more advanced AutoHotkey users to more quickly read both Pascal and C syntax, easier transition to using either of those programming languages syntax, in addition to creating flexibility in coding style.

Oh, I agree with you about AutoIt dollar sign spam syntax $. Hurts my eyes to look at it, yet they are arguably the most vocal group talking about AutoHotkey syntax. Talk about the pot calling the kettle black.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

17 Jan 2019, 04:53

AutoHotkey v1 GUI system VS AutoHotkey v2 GUI system

With regards to AutoHotkey v1 VS AutoHotkey v2 GUI system, I have been perplexed by the comment of it being bad. AutoHotkey's v1 GUI system is arguably "brilliant", especially for a scripting language, and was arguably superior to what AutoIt and other similar automation scripting languages had to offer. I have built 2,000 to 3,000 line programs, with GUIs, with AutoHotkey for work and didn't have any trouble with them. Also keep in mind the excellent program, AutoGUI by Alguimist. Made entirely in AutoHotkey to build AutoHotkey GUIs with v1 GUI syntax (https://sourceforge.net/projects/autogui/).

Building AutoHotkey v1 system GUI programs with AutoGUI is quite easy, and is up there with any IDE and Editor. And those GUIs can be easily opened or copied and pasted to programs like AHK Studio (https://www.autohotkey.com/boards/viewforum.php?f=62) or SciTE4AutoHotkey (https://www.autohotkey.com/boards/viewforum.php?f=61)

I fail to see what was the major shortcoming of the AutoHotkey v1 GUI system, for which it needed to be completely redone, except to align it more stylistically with the introduction of OOP (Object-Orientated Programing) concepts and expressions. Arguably, doing so introduced new levels of complexity and difficulty, because many non-programmers or novices would now have to ground themselves and understand Object-Orientated Programming (OOP) concepts, expressions, and functions from the start. And OOP or Objects are not something that is always needed.

With AutoHotkey v1, you can completely stay in the world of Procedural Programming and Automation, and then venture out beyond that to the level necessary or desired (Objects, true Arrays, Functions, DLL calls, etc...). Where with AutoHotkey v2, you must almost immediately need to start understanding very advanced programming concepts. While this might not be a big jump for a Computer Science student or a person with a long history of programming, it can arguably be so for non-programmers. Especially for non-programmers short on time to learn programming.

I can understand wanting to use AutoHotey v1 or v2 as a matter of preference or style, but I wouldn't say that the AutoHotkey v1 GUI system was bad. It's arguably the opposite, and one of the things that makes AutoHotkey fun to work with, especially when compared to other programming languages.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

17 Jan 2019, 22:23

- @swagfag: I listed some AHK v1 GUI issues here:
GUI COMMANDS: COMPLETE RETHINK - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=25893
- @SOTE: It's interesting your attempts to teach people AutoHotkey. Perhaps you could collect some general/specific thoughts on introducing people to AutoHotkey. I'm working on a general beginner tutorial. (Although I'd be more interested, not in whether AHK v1 or v2 are easier/harder to learn, interesting though that is, but on how best to teach/introduce AHK v1 or v2.) Thanks.
- I think that GUIs in AHK v2 could be done via functions, with no OOP, (and plan to complete my GUI rethink project on that basis,) however, I don't think that the OOP GUIs are particularly difficult to use (they're similar to Excel macros). However, fat arrow functions, those are newbie-unfriendly.
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: 1426
Joined: 15 Jun 2015, 06:21

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

17 Jan 2019, 23:55

jeeswg wrote:
17 Jan 2019, 22:23
- @swagfag: I listed some AHK v1 GUI issues here:
GUI COMMANDS: COMPLETE RETHINK - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=25893
- @SOTE: It's interesting your attempts to teach people AutoHotkey. Perhaps you could collect some general/specific thoughts on introducing people to AutoHotkey. I'm working on a general beginner tutorial. (Although I'd be more interested, not in whether AHK v1 or v2 are easier/harder to learn, interesting though that is, but on how best to teach/introduce AHK v1 or v2.) Thanks.
- I think that GUIs in AHK v2 could be done via functions, with no OOP, (and plan to complete my GUI rethink project on that basis,) however, I don't think that the OOP GUIs are particularly difficult to use (they're similar to Excel macros). However, fat arrow functions, those are newbie-unfriendly.
I think it's good for the more experienced people that have received some benefit from AutoHotkey to give back to the community by at least helping newer or other members, when possible or when time permits. I'm thankful to the developers and those more experienced or skilled programmers for helping me.

My concerns about OOP is grounded in how necessary that it is, freedom of choice, and flexibility. OOP (or it's concepts) as optional, seems more understandable, as opposed to forcing it's use. By imposing and forcing the OOP and function paradigm it arguably eliminates simpler and easier ways of doing tasks. So when I look at AHK v2, I wonder how necessary are the changes, as opposed to existing functionality? It's one thing if the change is giving a new ability or significantly empowers, it's another if the change makes things more difficult for limited benefit.

If we wanted complicated and confusing, we already have C++ for that and a long list of difficult programming and scripting languages. I've always thought one of the main objectives of AutoHotkey was to make things easier and ease of use. With that typed, the AHK v2 OOP GUIs does use a lot of the language of AHK v1 GUIs to ease the transition, though they are backwards incompatible and they kind of fit stylistically to the overall theme of what is being done with AHK v2. I guess only time will tell if those and other changes are truly embraced by the majority or not.

With AHK v1, there is actually a lot of freedom and flexibility in terms of programming style and on what areas a person would like to focus on. If a person doesn't want to use functions, DLL calls, OOP, objects, true Arrays, etc... then you don't have to. I think this unintentional aspect of AHK v1 is underestimated. You can accomplish a lot using standard procedural programming, commands, pseudo Arrays, Labels, subroutines, and automation orientated commands. It's arguably why AHK v1 is so easy to get started with. It has a kind of building blocks or upward stairs type of vibe, where a person can get as deep as they feel comfortable versus immediately drowning users in complexity. So that's where I'm coming from when mentioning such.

As mentioned on that thread, I find your GUIs as functions concept and system interesting. Minus the OOP, such an alternative allows for comparisons, so that others can more clearly see the positives and negatives of each GUI system.

By the way, perhaps your AHK v1 to AHK v2 Converter should be mentioned here as well.
https://www.autohotkey.com/boards/viewtopic.php?t=36754
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

18 Jan 2019, 01:18

- It's OK if we make AHK slightly harder to use ... slippery slope. (But I approve of AHK v2, and have argued for simplifications/ease-of-use where I've felt necessary e.g. AHK v1 force-local/#Include %A_Desktop%/ObjCount/A_Args (all implemented), and for AHK v2: objects that can record insertion order (not currently implemented).
- (As I've said before.) AHK v1 commands v. functions: with functions it's clear where strings start/end (quotes), it's clear what's a variable and what's a literal string (quotes), you can use objects/do calculations without needing to use a leading %. Learning functions is easier than learning functions *and* commands.
- AHK v1 GUIs had a lot of small quirks but that added up, and I'm looking forward to demonstrating how simple GUIs via functions can be. (I have about six major projects to finish first.)
- Let's assume you have to teach AHK v1/v2, whether you like certain features or not. Do you have any comments about how best to do that? Thanks.
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: 1426
Joined: 15 Jun 2015, 06:21

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

18 Jan 2019, 01:50

jeeswg wrote:
18 Jan 2019, 01:18
- Let's assume you have to teach AHK v1/v2, whether you like certain features or not. Do you have any comments about how best to do that? Thanks.
I think the most convenient ways are to help users in the "Ask For Help" section or create a new tutorial about a specific subject, in the "Tutorial" section of the forum. You are doing a great job there.

There is presently a lot of Youtube videos (Hellbent/Civborn, Blackholyman and Joe Glines...), books, websites, and blogs (Jack Dunning...) out. Which is fantastic, but that level is much harder to do and put together. It's great that we have members doing such.

However, it still takes the user or newbie to find, take the time to consume, practice, and understand the material given to them. There is also the debatable point on if some tutorials should be dedicated to C/C++, C#, or perhaps Pascal, to encourage new developers. That part gets a bit trickier, as the person will need to get much deeper into programming.
User avatar
evilC
Posts: 4822
Joined: 27 Feb 2014, 12:30

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

18 Jan 2019, 05:31

FYI, swagfag's post did not cover AHK_H v1

AHK_H v1 is:
99% compatible with AHK_L v1 scripts (About the only issue I ever came across is an AHK_L script that used the variable name null, which is a reserved word in AHK_H)

Has improved Gui functionality (Scrollbar support, auto-layout and resizing built-in)

Plus many of the benefits of AHK_H V2 (Multi-threading etc)
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

18 Jan 2019, 07:54

AHK v1s GUI system is such a failure, that I dont even consider using it anymore.
OOP works fine with UI - sadly the new v2 UI OOP implementation doesn't seem to make much use of it.
BTW the first thing I do when I create a GUI in AHK v1 is create an ActiveX object with IE in it for my GUI.
Recommends AHK Studio
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

18 Jan 2019, 08:46

i purposefully omitted ahk_hv1. if ure considering making the switch, might as well do it on v2. asa bonus, u get to keep ur sanity
User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

18 Jan 2019, 22:07

Resorting to v1.1 is out of question for me - v1.1 and older versions doesn't feel like a structured language at all.

AHK H v2 seems to be 5-15% as slow compared to AHK L v2. Memory consumption and .exe file size of H is much larger as well. It compensates with extended functionality but I prefer using AHK L v2 when its possible.
I do like the idea of Lexikos trying not to include stuff that would drastically degrade the interpreter performance and/or increase its size and complexity. Being said that, some AHK H ideas r just brilliant, I cant wait to see them included in L. :D
evilC wrote:
18 Jan 2019, 05:31
Has improved Gui functionality (Scrollbar support, auto-layout and resizing built-in)
oh, yeah, "anchor-like" and other additional commands of gui is a killer feature of H, no doubt! :D
SOTE wrote:
16 Jan 2019, 22:11
The GUI system used by AutoHotkey_L (v1) is among the easiest to understand
I completely disagree. Its a bloody mess tbh. v2 gui object facilitates it to a great extent. But even v2 gui implementation feels like there is room for improvements.
but the point often is still about doing things simply versus making things unnecessarily complex.
That's exactly what one gets at the end. imho, v2 gui object makes the gui code incredible simple and structured.
. Arguably there is less material written in AutoHotkey2, because it is embraced by and used by less people, to include that it breaks old scripts and introduces more difficulty. Also add that it is still in Alpha and more experimental.
Alpha state doesn't mean anything concerning its stability - v2 is completely stable. I guess it remains in "alpha" status due to susceptibility to drastic changes in the nearest future.
Well, transferring from Python 2.x to 3.x was dramatical, too. But at the end we have a very logical syntax with Python v3.
swagfag wrote:
17 Jan 2019, 01:00
yeah v2 breaks old scripts. so, run ur old scripts with v1, and write ur new ones with v2, i dont see the problem there. the difficulty lies in learning something different from scratch, but v2 in and of itself isnt any more difficult than v1 is
I believe v2 is even easier from the scratch, one doesn't need to look up in the documentation so often to consult which input argument types and arguments order the current command accepts.
A language utilizing just a big set of heterogeneous commands is a bad idea in general.

OOP in AHK might be very primitive and thus easy to understand.
i recall some time ago a user made this super hugeass post about everything wrong with v1, ill see if i can dig it up
Very intriguing. Could u provide a link please. Cuz right now I'm preparing a huge wish list concerning v2 inconsistencies. :D Yes I think there r lots remaining yet.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

19 Jan 2019, 01:12

yes i found it
https://www.autohotkey.com/boards/viewt ... 939#p41939
i dont subscribe to everything he says but hes right for the most part
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

19 Jan 2019, 08:04

vvhitevvizard wrote:
18 Jan 2019, 22:07
Resorting to v1.1 is out of question for me - v1.1 and older versions doesn't feel like a structured language at all.

I do like the idea of Lexikos trying not to include stuff that would drastically degrade the interpreter performance and/or increase its size and complexity.

...

OOP in AHK might be very primitive and thus easy to understand.
While it's understandable to create a AutoHotkey v2, I wonder if it might be better to truly set AutoHotkey free from the C++ interpreter, where it can be compiled directly. There is clearly a divide, where we have a programing language dependent upon another programming language, which creates restrictions in terms of development, knowledge of both languages, and portability. And if that is too radical a step, perhaps a transpiler (source to source compiler) using C++ or some other language (like Pascal) to directly compile programs.

Judging from a recent post by Hellbent, it's clear that some will fall very deeply down the OOP rabbit hole, even with AutoHotkey. With AutoHotkey v1, OOP is still something more optional that can be ignored, which I think might be preferable. In other programming languages, like Object Pascal, programmers can choose to stay entirely with the Procedural paradigm or choose to play with OOP. At least AutoHotkey has the advantage of picking and choosing out of OOP concepts, which have already been tested in other languages. Hopefully they will all be good choices.

It's not to say that there isn't any good things about OOP, but that perhaps proceeding with great caution might be more advisable when it comes to OOP. And it is something that non-programmers and newbies are going to be forced to wrestle with, if it is fully embraced in AutoHotkey and presented as a solution in help files and the Help section of the forum.
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

20 Jan 2019, 09:41

I do not think AHK v2 GUI API requires any knowledge about (even the existence of) oop, just basic object syntax. Most importantly, it is one syntax, compare v2,

Code: Select all

myGui.addButton("w200", "Click Me")
vs v1,

Code: Select all

gui %myGui%: add, button, w200, Click Me
or

Code: Select all

gui % myGui ": add", %  "button", % "w200", % "Click Me"
or

Code: Select all

gui myGui: add, button, w200, Click Me
or

Code: Select all

gui myGui: default
gui add, button, w200, Click Me
or maybe some combination of these.

Cheers.
User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

20 Jan 2019, 09:58

Helgef wrote:
20 Jan 2019, 09:41
And the most nightmarish AHK v1 feature was MsgBox with its smart comma syntax and enabling expression(s) with percent sign. :D AHK v2 MsgBox is very legible:

Code: Select all

MsgBox("name: " var1 " count:" var2)
I don't have to use parenthesis here but I do cuz this way its similar to the top languages syntax and the code is easily transcoded if the need arises.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: AutoHotkeyH vs AutoHotkeyL vs AutoHotkey2

20 Jan 2019, 10:42

Thats still nothing when compared to the Click command.
Recommends AHK Studio

Return to “Ask for Help (v1)”

Who is online

Users browsing this forum: garry, marypoppins_1, Pumpk11nnn, Rohwedder, RussF and 151 guests