AutoHotkey Community

I used V2 many years ago, but recently when I needed to write new code, I fell into conflict.
I am using A-104, which is obviously old. I will not consider it when I write new code.
So use the latest version A-115? It is also not an ideal candidate.
Back V1? Not under consideration.

After a month of stagnation, I started to use python 3.8. I found that it is not more complicated than V2, and the learning process is very simple. Moreover, I like to use WINAPI, and seldom use AHK built-in commands, so the switching process is smooth.

I find this post interesting. I guess AHK v2 causes a taste for something else or outright general purpose programming versus its original purpose of more automation centric programming. I've always looked at AHK as an automation scripting language (and hope that stays the focus), so have been fine with AHK v1 for that being primary, and then delving into general purpose programming (for nice small utility programs) as secondary. When/if I need a "heavy hitter", then I lean on Object Pascal. Then to JavaScript (lots of synergy with AHK) or C (less often though good for MCode). Been toying with Go, but just no pressing need in relationship to the others and AHK.

What are people doing with AHK v2, that they can't find a way to do in AHK v1? Are people really writing cutting edge programs on a totally different level? I get that AHK v2 is like the shiny new car, but if the old and new car run at the same speed and serve the same purpose... Plus if you polish up the old car and its seen as a classic... Anyway, I don't see any staggering difference in capability, particularly in automation type tasks.

I've looked at AHK v2 as being experimental and playful. Its time is not yet, and I would appreciate that it gets all sorted out, before it gets introduced to prime time. To include some important tools and libraries also being written in AHK v2. Also, as a halfway point, we do have AHK_H v1, which introduces some extras that people might want. Maybe people can lobby for some extra things they are looking for to be added to AHK_H, if they feel it's important enough.

Lastly, I just don't see what people love so much about Python, especially if they are primarily on the Windows OS. Maybe learning Object Pascal causes this view. Like with what colors we like, preferences are such a strong factor. But, I do find it interesting that people don't fall back to or claim they are moving on to only C++, C, or C#. I guess its about convenience, examples, or existing libraries.

Yes, I agree with you. If I am using V1, I will not be confused. But when you start using V2 and feel that it corrects countless shortcomings of V1, it is difficult for you to return to V1.

The problem with V2 is that as the main version of the AHK language, its development is disordered and unpredictable. It does not have a timetable or detailed plan. (Of course we will all pay tribute and thanks to lexikos)

arcticir wrote: ↑

11 Jul 2020, 00:07

I used V2 many years ago, but recently when I needed to write new code, I fell into conflict.
I am using A-104, which is obviously old. I will not consider it when I write new code.
So use the latest version A-115? It is also not an ideal candidate.
Back V1? Not under consideration.

As for me, I used Python 2 and 3 for a while, returned most of my functionality back to AHK. Reason? Python is overburden and over-complicated with all those libs. Minimal footprint of a standalone .exe was around 12MB - its even more now. thousand of interconnected libs. Ofc I do resort to Python to use Neural Networking experimentation of mine cuz it has de-facto the best support for it =) and (rarely) some math libs. But I find AHK V2 (latest version) to be more convenient. I managed to have all the core functionality for my needs I had with Python (mostly maintaining routines, text/json/xml/svg/html converters and parsers). And I see the tendency I like in AHK V2 progress. BTW, Python yields to Go and other languages. It has lots of compatibility issues, its so overloaded that I see never-ending tries of making mini, micro Python versions.
I can't stand AHK V1 syntax -its a king of quirkiness in my opinion - reminds me the dark age of DOS epoch scripting.

arcticir wrote: ↑

11 Jul 2020, 04:30

The problem with V2 is that as the main version of the AHK language, its development is disordered and unpredictable. It does not have a timetable or detailed plan. (Of course we will all pay tribute and thanks to lexikos)

Well, u don't have to move on with every alpha version. Stay with that v2-a104 until u r ready to move on. I use another strategy and try to update my code base to newer version but I figured out I better do it step by step w/o skipping minor updates.
Recently AHK2 progress rate is increased and overall changes r great! I FEEL the vector it develops is right and clear, too conservative sometimes but it might be the reason AHK remains unfussy.
Oh and the last, but not the least: recent frequent AHK V2 perturbations made me refactor some of my utilities the way they r more modular and stable to possible unpredictable changes or easier to search-and-change should the need arise. Well, its never ending process. Every time I look at the code I find ways to optimize performance, reduce complexity, add new features etc

SOTE wrote: ↑

11 Jul 2020, 02:19

What are people doing with AHK v2, that they can't find a way to do in AHK v1? Are people really writing cutting edge programs on a totally different level?

Purpose of any scripting language is not about being cutting edge programs, definitely not performance-wise. But scripting can be glue to draft ideas, to do some repetitive on-the-fly actions or to be a go-between for some compiled optimized libraries. Unlike C# and to less extent Python, unrestricted AHK can be run on WinPE (live, RAM) versions and yet its arguably more advanced compared to other simple scripting tools like Windows Scripting Host, AutoIt, Lua, NSIS, etc. WSH cannot even be counted - it is not open source.

SOTE wrote: ↑

11 Jul 2020, 02:19

I get that AHK v2 is like the shiny new car, but if the old and new car run at the same speed and serve the same purpose...

Rather a workhorse that tries to bring to perfection language syntax. "Old car" works still but it cannot comply with basic rules of language modularity, matching other languages' syntax and common conventions, objectivity, not too steep learning curve. AHK V1 is just a set of commands, simply put. AHK V2 can be called a full-fledged scripting language, to some extent: it still misses some basic yet important thingies like namespace management and preprocessor/macros.

SOTE wrote: ↑

11 Jul 2020, 02:19

To include some important tools and libraries also being written in AHK v2.

Its possible to use any other libraries. U miss some wrappers? Or u need libraries to be written in AHK V2 instead of compiled machine code? I think it is possible to exploit Python's, NSIS, whatever binary libraries if one knows how to mimic in/out structures and data formats. By saying that, AHK V2 script codebase is rare still, the majority of AHK V1 code haven't been ported to AHK V2.

SOTE wrote: ↑

11 Jul 2020, 02:19

Lastly, I just don't see what people love so much about Python, especially if they are primarily on the Windows OS.

Oh, that is a good point not against Python actually. It is portable. It can be run even on Arduino and other gadgets. I consider this the main drawback of AHK.

I've tried to like Python, but it's just way too messy and bloated for my tastes. For people heavily involved with using multiple OSes at the same time or specific projects where the only or their preferred libraries are written in Python, I kind of get where they are coming from. But I will say there are other (way less messy) alternatives out there to look at. With Go and Object Pascal being strong contenders and in various cases JavaScript and C#. But, when it comes to automation centric scripting on the Windows OS, AutoHotkey is just so darn convenient, easy to use, small, and lightweight. Really hard to beat that combination.

As for AHK v2, I'm a little bit concerned about the use case and who is the target. The fact that we are talking about AHK v2 in the same breath as Python, is a bit startling. Maybe that's good or bad, depending on context, but it's hard to be sure or clear about it. With AHK v1, seems like there is less confusion. It's mainly about automation and ease of use, and if people found ways to do other things, that's all good, but such usage is more clearly creative or outside of the box.

With AHK v2, are people using it drifting that far over into general-programming and out of automation centric programming? Because that seems it would take AutoHotkey out of its strength (automation) or be pitting it against a long list of heavy hitters. This is where a clear direction and intent is maybe needed. You can do some amazing things with AutoHotkey, outside of just automation, but how far should/can it go?

Re: AutoHotkey v2 becoming a general purpose programming language, I think that is a good thing. The language is getting stronger and for a good reason. That reason is so that modern libraries such as Tensorflow and OpenCV can one day be integrated into AutoHotkey. If you think about it, despite Python being great at processing data, it is not so good at windows automation without importing a few libraries.

Lastly, the biggest factor for me is AutoHotkey not staying in touch with future forms of interaction such as speech/voice input, camera input, etc. I suppose these could be user created libraries, but lacking multi-touch (when everything is touch screen!) isn't an excuse.

I do agree that AutoHotkey's small executable and portability is it's greatest strength.

iseahound wrote: ↑

24 Jul 2020, 12:36

Re: AutoHotkey v2 becoming a general purpose programming language, I think that is a good thing. The language is getting stronger and for a good reason. That reason is so that modern libraries such as Tensorflow and OpenCV can one day be integrated into AutoHotkey. If you think about it, despite Python being great at processing data, it is not so good at windows automation without importing a few libraries.

Lastly, the biggest factor for me is AutoHotkey not staying in touch with future forms of interaction such as speech/voice input, camera input, etc. I suppose these could be user created libraries, but lacking multi-touch (when everything is touch screen!) isn't an excuse.

I do agree that AutoHotkey's small executable and portability is it's greatest strength.

I just hope its not flirting with disaster in terms of community split, somewhat like Python 2 VS Python 3 did to its community. Removing of what appears to be "unneeded" noob friendly features to satisfy advanced tastes, could possibly cause people to want to stay with AHK v1 or a new AHK v1 fork, while many of the so-called advanced AHK v2 users might get seduced to other programming languages. "Well, now that I'm doing general purpose programming with AHK, let me just jump over to..." I can't speak for arcticir, but that's the kind of vibe his original post gave off.

But automation is a very wide field. There are so many things to factor in; speech, voice, touch screen, RPA, RDA, AI, digital assistant, etc... There debatably is no reason not to stay close to this lane, and keep knocking it out. And this mindset or focus, is likely to be reflected in the AHK language development (automation centric VS general purpose).

For example, I started using AHK, because it wasn't a/like other general purpose programming languages. It was automation centric and a great complementary programming language (on Windows), in addition to highly portable, easy to use, and easy to understand. Maybe the concept of AutoHotkey as a complementary programming language, has also gone a bit under the radar. For instance, I created and seen others make many scripts of AutoHotkey combined with all sorts of other languages (JavaScript, VBScript, C#, etc...).

If AHK becomes more like other general purpose programming languages or the more one starts to do general purpose programming (which gets a bit tricky), you have to look at AHK from a different perspective. Clearly, the present form of AHK is not meant to compete in general programming with compiled programming languages like C++, Object Pascal, Go, etc... JavaScript is pretty much in a world of its own, because it's accepted as a world standard for browsers. Though I do think making it easier for AutoHotkey and JavaScript to team up would yield even greater advantages. So interpreted languages like Python, become a more obvious competitive target or "next step". But these other interpreted languages have like tons of developers and/or big companies backing them. For a smaller community to compete (and AutoHotkey has done great so far), maybe the focus has to be a bit different.

I can't say what "thee answer" is, outside of a feeling or hunch, but it does appear a bit worrisome.

I see AHK V2 becoming a general purpose scripting language, too. Clean and lightweight. With as few irregularities and quirks as possible. I would like it to use javascript and python notation and data types, the best of the two worlds. I don't expect AHK to become a huge set of built-in functions/libraries like Python - I personally prefer to write my own custom libraries (script and binary) and wrappers intended for a compact core interpreter and finite set of compiled libraries of my choice.

Clearly, the present form of AHK is not meant to compete in general programming with compiled programming languages like C++, Object Pascal, Go, etc...

Yeah. We can't compare interpreter/pseudo-code compiler with machine code compiler.

JavaScript is pretty much in a world of its own, because it's accepted as a world standard for browsers.

node.js for server code, extendscript for Adobe products, etc. Most of them realized for sandboxed (restricted) environment anyways.

I just hope its not flirting with disaster in terms of community split, somewhat like Python 2 VS Python 3 did to its community.

We got exactly the same - split between V2 and V1 communities. But that's good thing as well - AHK V2 don't have to narrow and slow its progress to be backward compatible with AHK V1.

@SOTE
A good resource to get an idea of trending syntax is Rosetta Code aggregator, e.g.: https://rosettacode.org/wiki/Percentage_difference_between_images
AHK V1 example out there doesn't actually use additional libraries, instead it calls GDI functions directly. So one might think AHK is a do-it-urself language.
Using wrappers and/or OOP design rules would dramatically increase legibility, yet one can note a typical AHK V1 script uses quite peculiar formatting and layout and that comes from batch-like nature of AHK V1.
I believe there is nothing to worry about that AHK V2 becomes a general-purpose language and that it mimics commonly used trends - it makes users' life easy, reduces the work required to adapt scripts written for other languages, etc.

Timelapse: Most Popular Programming Languages 1965 - 2019 (based on GitHub repositories access frequency and other survey aggregations)
Rosetta Code's rank languages by popularity shows Go #1; Python #5 goes down from #3; non-OOP C #9; Java #10 and slowly loses its traction; CPP, Javascript fell out of top 10.

I wouldn't exactly call Rosetta code a relevant source for overall coding language popularity.