AutoHotkey Community

AH is great. I love it. Having said that I must say the programming language itself is a bit clumsy. I see it is improved constantly, but it lags behind other powerful languages (Python, Perl, etc.) and probably never will reach their level of maturity and expressiveness.

My idea is (which might already be posted before) to separate the actual window handling backend from the language frontend.

By putting window handling into its own library, developers could add for example Python language bindings to AH and people could use whatever language they want.

I don't know how the backend is currently tied to the language, but I think they should be independent and AH development should strive to separate them as much as possible.

That's true. You probably know the reasons but here they are:
1) Backward compatibility, both with AutoIt v2 and with existing scripts.
2) Limited mission and scope: AutoHotkey specializes in automation and hotkeys. It's not intended to be a comprehesive programming language such as Python or Perl.

This is a good idea and very similar to what Jonny has proposed in greater detail. However, due to limited developer time, it will probably be a long time in coming because other improvements seem to be a higher priority.

In the meantime, you might look into AutoItX, which is a DLL version of AutoIt. The site describes it as, "... a subset of the features of AutoIt via an ActiveX/COM and DLL interface. This means that you can add AutoIt-like features to your favourite scripting and programming languages, e.g. VB, VBScript, Delphi, C, C++, Kixtart, and most other languages that support the use of DLLs."

Just out of curiosity: is the language strongly tied to the window handling functions?

I haven't yet written a script language, but I wouldn't think of mixing the syntax processing part with the window handling backend. I mean when it comes to invoking a function like wingettitle I have all the parameters parsed know the name of the function, so it's only a matter of a function call into an other "module" containing the window handling functions, isn't it?

Is there some historical reason the language is not separated from the backend? Or are there some complex design issues with that I don't know about?

Although the code is somewhat modular, for the most part it is tightly integrated. This is done for performance and code size reasons, and perhaps a little laziness too.

I have a bit of a different perspective on AutoHotkey's language independence.

I think that AutoHotkey is a good easy to learn and introductory programming language, that is also very powerful too. Furthermore, if you understand programming concepts in AutoHotkey, than understanding other programming languages will be much easier.

Key points that make the language easy and powerful are:

1. GUI syntax

2. LOOP syntax.

3. Various specialized automation commands that other programming and scripting languages don't have. You can do more than "send keys".

4. Goto and Gosub options

* Now before anybody loses their mind about Goto, consider the following:

A. Can be useful for small programs, as long as the user understands that they will be skipping code to perform an operation/function/task else where in their program and will not be going back to where they left off. Gosub, on the otherhand, solves the issue of going back to where you left off.

B. Makes programming easy for newbies and inexperienced programmers.

C. AutoHotkey also provides Else, Blocks, Break, and Continue commands. Therefore you have more options on what you can do, in reference to Goto and you are not "forced" to use only a certain method.

5. AutoHotkey could also be used as a type of framework to call other scripting languages.

6. AutoHotkey is a very easy programming language to read. Other programming languages give a lot of "talk" about how they are so easy that they don't need to comment on the source code, but such talk is usually bull.... becauase when you come back months/years later or somebody else looks at that language's code than they will often have no idea what was going on without the comments (often lots of comments).

AutoHotkey code on the otherhand, after you understand the basic concepts, looks very "modular" and organized due to labels and how loops, "{ }", etc... are done. Its kind of like looking at "self-contained cells" that can connect to each other.

The above features of AutoHotkey would make it a great .NET language too. Of course creating a AutoHotkey.NET version would have lots of issues, but then you are talking about moving this easy to understand and use language to the Linux and Mac world too.

There are lots of "serious", "proper", and "complex" programming languages out there. Which interestingly enough, many people that use computers don't use those "proper" languages or require years of study to figure out how to use them. With that stated, there should be plenty of room for an easy to understand and use programming language as well.

True, but this topic wasn't meant to be an attack against AutoHotkey the language.

It's an easy to learn, simple, useful language. The idea was to provide an option to plug in other languages besides AH, so that anyone can use AH or any other language for which bindings has been written. It's about choice, separating AH the language from AH the library.

Yes, "Guest", I do understand your wish and I'm in no way saying that it is invalid. I was just giving another point of view about language independence .

As was mentioned by Chris, there is the AutoItX.dll. If AutoHotkey came out with an AutoHotkey.dll than how different what it be from AutoIt's dll?

I was stating that perhaps AutoHotkey could go a different route by it being an easier to use and understand, but a very powerful programming language, that could also easily call code from other languages too.

In this way, a person new to programming could use AutoHotkey and then use other bits of other programming languages for various tasks.

If a person was an expert of another programming language, lets say Pascal, than such a person could always use the AutoItX.dll

If the person was not an expert of another programming language and primarily a user or AutoHotkey expert than he/she could use other bits of another programming language as necessary or as they learned them.

In this way AutoHotkey and AutoIt would also complement each other, as oppose to unnecessarily compete with each other over nearly equally functioning dlls.

I think that the AutoHotkey.dll, if it came about, what need to have some direction and purpose that was different from the AutoItX.dll.

As far as the plugin concept goes, I would vote "yes" for it too. But it appears that there are a number of factors involved in being able to do this with AutoHotkey.

Overall, I think AutoHotkey is just a great user friendly language and that it would be nice to see it grow.

I think this is a very good idea. However, for various reasons we will not see it realised. (Not only not "anytime soon" -- I think "never" is the word here.)

My mid-term solution is to scrap the whole ahk syntax with the exception of the menu and gui stuff and have keypresses, menu choices etc. go to internal (if short) or external (if longer) Perl scripts (also some JavaScripts).
This works reaonably well, though a direct way of switching AHK from one language to another (with a directive for instance) would not a bad idea.

I have looked into the sources and I will at some point do something about this but there are other things to do before Even if I do something it will probably too quick&dirty for general use, though I would male it available anyway.

Ick... I guess we all have our preferences...

I dream in Perl... whereas the AHK syntax is simply too constrained and too inconsistent (if I would dream in it it'd be a nightmare I am almost inclined to say ).

I tried it but it simply doesn't work for me: sometimes I can replace a dozen lines of AHK with an elegant one-liner in Perl. (s/// is my friend.)

If the stuff works for you, all the better.

Why Perl? Why not Python?

Is not Python suppose to be more "in" than Perl?

Code minimalization/shorthand/abbreviation, taken to an extreme, invariably means that ease of maintainability becomes proportional to code size. While such code abbreviation is ideal for individual user customization, it is very bad for businesses and potentially confusing for a user in the long run. Unless you place very specific comments along with the code, which still may not completely defray another's lack of familiarity with the code, or even one's own forgetfulness.

_________________
1) The Open Source Definition http://www.opensource.org/docs/definition_plain.php

2) Intuitive. Logical. Versatile. Adaptable. <<AutoHotkey>>

IN? Crikey, I never realised this is a beauty contest. I know Perl and I don't know Python. Who cares about IN or OUT!


Any sentence with the word invariably in it is invariably wrong.

I must ask the obvious question then (please don't take offense ). Why are you here?

That's an easy one: because AHK's hotkey and macro handling is rock-solid (under Win2K, don't know about Win9x). I have used almost all hotkey/macro utilities under the sun and they all have problems with getting the keyboard/mouse hooks right, or expanding the macros, addressing the right window etc. AHK hasn't got these problems, though it has, err, others

Now, if someone would marry Perl with AHK's ability to handle hotkeys and expand macros... dream on.