Autohotkey vs. AutoIt

< Next Topic | Back to topic list | Previous Topic >

Pages: 1 2 >

Posted by Fredy
Sep 1, 2012 at 03:05 PM

Spicing your Outliner up : Autohotkey vs. AutoIt ; both better than Macro Tools

Whenever I buy something of extended use, I do some comparison of the various offerings (for cars, in my price range; in computing in my range of what I find useful for me, and trying to minimize price considerations - if something is “worth” it, I buy it, even if it’s (not TOO much) overpriced; sorry, no iBuys yet, in application of this rule though).

The same goes for macro tools and script languages, where you have the additional problem of the TOC being multiple times any purchase price, and in many cases, you simply cannot evaluate the real power of some such language easily.

So I made another mistake recently, hence my writing here.

Do NOT buy any traditional macro tool. There are many of these out there, but most of them share a common problem: Either there is no flow of control processing at all, or the flow of control elements are much too basic:

- application scope? that’s all you’ll get, at most, with most of them
- control scope? absent in almost every one of them (= in an outliner, are you in the tree or in your content field? this control scope alone will open a wholly new world for you if it’s available to you)
- if, elseif, else? some macro tools offer SOME of this, but mostly in a way that will make you write awful code, doing the same 20 or 50 code lines again and again, i.e. no substructures, let alone adaptable ones
- while, for, loops in general? forget it, for most of them
- variables? sometimes; global variables? forget them, for most of the offerings
- string processing? forget it, for most of them

And “getting out” your macros, out of these tools, is a nightmare, i.e. at best for most of them, you’ll do screenshots of your steps displayed there, print these out, then enter manually all this stuff, step for step, into your “new” tool.

SOME macro tools DO offer most or all of this, though, but then, they are proprietary macro languages, offen very buggy (and having been buggy for years, without any real solution to all this) - and do they allow for free installations, i.e. the sharing of your macros with people that didn’t buy that specific tool first?! And, IF you must do it within such a real scripting language, instead of just clicking together key pressings, is it reasonable to learn a proprietary language that will be defunct when their developers lose their interest? And that’s absolutely possible since the more elaborate such a language is, the more it is in your interest to learn some “real” script language instead, and the less it is given that this proprietary langue will be bought again and again by new scripters making their choice, hence the roaring probability of it being buried at one moment or another.

If you are interested in having a look at a typical macro language that tries to do “more” but in incredible ways, have a look at Quickeys for Windows (and its if structure) - and have a look at its dated version.

I stayed many years with a macro tool, for fear of having to invest a week of more into transcripting all my stuff into a script language - and then, it was more than just 40 hours, but including much new functionality nethertheless…

(Ok, one of the offerings of (the better) macro tools is that you can have built up your first menu within 30 minutes whilst in scripting languages, it will take you some hours to understand how to build it up with your proper means - help files ain’t that good around here…)

So, if you want some functionality, your best bet is going for one of the two free script languages out there, i.e. AHK and AI.

The Kant professor in this forum (up to 2010 or early 2011) swore by AHK, but he also swore by ConnectedText, and that should have me warned, since CT “does it all”, presumably, but is missing the most important feature of them all, a viable tree structure.

There are many “AHK vs. AI” posts in the web, but most of them are simply too much biased in order to be worthwile. People say AHK has horrible syntax but do not explain. Other people say AI has a forum where experienced, professional programmers agress “dumb” newbies. Then, people say in AHK it’s much easier to assign shortkeys. Finally, you get the info, “AHK hasn’t got arrays”, then others say, “that’s true, but latest version of AHK is from 2009 anyway, so the “current” version of AHK is AHK_L anyway, WITH arrays, so what?”

This is all true, or is it not?

Outright liars - or simplets - even pretend that since AHK is outsourced from AI, they have similar syntax - nothing could be wronger.

The AI forum isn’t that nice indeed, whilst the AHK forum is much more accessible in every respect; at the end of the day, you’ll get professional help in both.

With AHK, make sure you download AHK_L, and then make sure you only use the (good) offline help coming with it, don’t refer to the AHK online help anymore, at least concerning the alphabetical commands list, etc.

III

If you never did any programming, and never will do, AHK’s macro (vs. micro) syntax would be “acceptable” whilst in any other case it is weird, weird, weird. This is an conditions structure:

key assignment
some code
if abc
{ blabla = anything you need here
} else if
{ blabla
} else if, etc., etc., then:
else
{ bla
} return

next key assingment

And no, there is no “endif” or “end if”, and similar for anything you could imagine. So much for the “macro” syntax.

Now for the “micro” syntax in AHK. Many commands are in the form

something, sothis, andthat,,andsomeotherattributeorsuch,,,whatevermightbehere,etc,

and you must put strings into quotes, OR NOT, depending on the command in question, and you must put variables within p.c. signs, or not.

Other commands are in the form

something(sothis, andthat,,etc.etc.etc, see above),

and you must put strings into quotes, OR NOT, and variables into p.c. signs, or not,

and there are commands like send this, with/without quotes/p.c. signs, or msgbox, with/without quotes/p.c. signs, etc., etc. ad infinitum

Similar for assigning values to variables, there is not one way, but there are several ways, but these several ways of doing things are allowed here, not allowed there, whilst at another place yet, you MUST apply a certain way, but in which only this or that way of doing things is allowed…

Which is to say, in AHK, there is an inconsistency “AHK vs. other programming languages” you can come by since there IS consistency within AHK, at least (even this is theoretically wrong since there are different ways to structure, but at least you can leave out those “simplifications” - that are allowed here but not allowed there! - altogether and THEN have a consistent “macro” structure).

But on the “micro” level, on the sub-structure, command line level, there is NO consistency in AHK whatsoever, since opposite to the above, you can NOT adopt one single strategy (be it more fuss, but consistent in itself), but must adopt this way in this command, another way in another. This invariable means you’ll write down the needed commands, together with the ways you will have found out are working, on a sheet of paper, hoping in another situation, with some different attribute, it will not be totally different again from what you found out - and it means you will use the tiniest possible number of commands, for fear of horrible beginners’ problems with every new command you would find useful, and that means that your scripts will probably be of horrible-syntax-induced, “unnecessary” poverty - or you see AHK as another iq test, and probable spend lots of unnecessary times coding with it, whilst in a consistent scripting language, that is consistent with traditional programming languages, on the macro level, you could do rather fast work since you would not have to think, “this is AHK, so which way must i do it otherwise, because of that?”, and on the micro level, you would memorize the usual commands rather fast, and for any command new to you, you would have a basic perception how it will work in a consistent way with other such commands within the same language.

This would make us choose AI. But then, perhaps, those key assinments in AHK are worth all the fuss? Well, they are not. In fact, for a “bloody” beginner, AHK’s key assinments are MUCH easier than anything anywhere else, so, indeed, this USP of AHK will charm you immediately. But rather quickly, you will realize that this way of doing grouped key assignments in AHK, depending on scope (by preceding ifthisthisparticularwindow commands) isn’t but a trap since what about commands belonging together, similar commands in different applications, different commands depending on global language variables, etc.? In any code, there is a two-dimensional representation only of your routines, not a three-dimensional one as is in your outliner (provided it offers clones). Thus, even in AHK with those application headings for key assinments, perhaps another key bindings structure, relying on (different! = a combination of!) global variables might be better indeed?! So, the normal key assignments don’t do it: There are very good at first sight, but at the end of the day, in AI you can do in as good a way as you’d do it in AHK - no advantage for either script language here.

VII

What about arrays, then? Yes, AI has got normal arrays, like any other normal programming language has: You assign and retrieve values as you ever did anwhere else, whilst in AHK, arrays are just another total nightmare. AHK (final “Chris” version, from 2009) has pseudo-arrays (!), sort of simili-grouped normal variables, spread in your memory, and for some 5 or 10 values, that might be it even it it’s the most ugly “programming” you will ever have done. AHL_L has got “real” arrays, they say, but in the web, I didn’t find more detailed info on that subject.

When you install AHK_L, you’ll install its help file with it, and there you’ll get your information, and yes, it’s another nightmare. Arrays can be ONE-dimensional only, and if you need more than one dimension - and most of the time you’ll do -, you can “insert” one array into another, or something: So, in a ten-rows array, you’d insert 10 other arrays, in order to get an array[10][2]? Don’t know, didn’t understand a mumbling word of what they say (and I have treated with multi-dimensional arrays many years of my life). (see below)

VIII

Thus, I simply had to renounce on doing a script for my outliner I so much had wanted to do, since I simply did not want to “learn” this weird thing of doing so-called “arrays” in AHK - j’en avais ras-le-bol, as we other French-speaking people say.

Let me explain: I have used a very expensive script language plus scriptable editors in order to run text processing scripts, will transfer my workflow to AI plus scriptable editors - should perhaps learned Perl instead to begin with… But for my “general scripting work”, i.e. for doing all these little things you’d normally do with a macro program, I’ve been using AHK for some time now - and of course, compared with my former macro tool, my possibilities are “endless”. But why not using AI for my “general purposes” also, thus avoiding all the AHK problems I’ve enumerated here?

Because of AHK’s text expanding facilities. There seems to be an additional sw / elaborate script that more or less “integrates” that power into AI scripts as well, but I never tried it - should have done so, I fear -, and so I don’t nothing about its ease of use (= which implies ease of doing changes, especially here with text expansions!!!), response times (= especially here with text expansions, again!!!) or anything else.

So, I simply adopted AHK for the relative ease of key assignments here, and of its incredible ease of doing text expansion with it, since this appeared to me the prevailing criterion for “general purposes” where indeed ease of constant, permanent, never-ending revision of all these little things here and there, and ease of use, and ease of revision, of text expansions, seemed to me more important than anything else.

As for the missing array[100][3] - not a “big thing”, then -, I’ll realize the whole script with AI, triggering it with AHK on the rare occasions I’ll be in need of it.

So, what’ve you got here? As with any other kind of sw (e.g. editors! not speaking of outliners!) or product (I’m leaving out people here), there is no easy one-does-it-all solution here, and all I could do was detailing some aspects and the temporary decisions I inferred from them, for myself. This being said, whenever AI will get better-integrated text expansion, I’ll perhaps translate - script-driven as far as it’ll be reasonable! - my currently about 3,000 lines of AHK code to AI.

But the most important step was to do the transition from a macro tool to a script language, even if here and there, I reproach myself with having made the bad choice.

Posted by Slartibartfarst
Sep 1, 2012 at 06:51 PM

@Fredy:
Thanks for your interesting comparison between Autohotkey vs. AutoIt.
Before discussing it further and in order to try to make some objective and useful comment, I would prefer to see some clarity in the definition of terms.

In your discussion, you frequently refer to AHK/IT in terms of being a “programming language”.
I don’t know about AI, but AHK would appear to not fit most/any definition of a programming language. For example, the Wikipedia entry for AHK says:
http://en.wikipedia.org/wiki/AutoHotkey
__________________________
“AutoHotkey is a free, open-source macro-creation and automation software utility that allows users to automate repetitive tasks. Any application user interface can be modified by AutoHotkey (for example, overriding the default Windows control key commands with their Emacs equivalents).[2] It is driven by a custom scripting language that is aimed specifically at providing keyboard shortcuts or hotkeys.”

Wikipedia also says about AHK:
“AutoHotkey scripts can be used to launch programs, open documents, send keystrokes and send mouse clicks and movements.[3] AutoHotkey scripts can also assign, retrieve, and manipulate variables, run loops and manipulate windows, files, and folders. These commands can be triggered by a hotkey, such as a script that would open an internet browser whenever the user presses Ctrl+Alt+i on the keyboard. Keyboard keys can also be remapped or disabled, such that pressing the letter q, for example, might result in the computer receiving a letter r, or nothing at all.[4] AutoHotkey also allows for ‘hotstrings’ that will automatically replace certain text as it is typed; the most typical use for hotstrings is expanding abbreviations, such as assigning the string “btw” to send the text “by the way” when typed, or the text “%o” to send “percentage of”.[5]
__________________________

Wikipedia also has this definition for a programming language:
https://en.wikipedia.org/wiki/Programming_language#Definitions
__________________________
“A programming language is a notation for writing programs, which are specifications of a computation or algorithm.[1] Some, but not all, authors restrict the term “programming language” to those languages that can express all possible algorithms.[1][2] Traits often considered important for what constitutes a programming language include:
* Function and target:...
* Abstractions:...
* Expressive power:...”
...

“All programming languages have some primitive building blocks for the description of data and the processes or transformations applied to them (like the addition of two numbers or the selection of an item from a collection). These primitives are defined by syntactic and semantic rules which describe their structure and meaning respectively.”
____________________________________________

I would thus tend to distinguish a scripting language from a programming language.
I know Wikipedia may be a dubious authority to quote, as it may contain much that may be wrong or apocryphal (!).

It would be interesting to see a formalised set of requirements for a scripting language, but I am unaware of any such - I haven’t come across one in any event.
If we had a set of requirements, then we could use it as a basis for comparison and rapidly tick off whether script language A or B met the requirements, and to what extent.

Posted by Fredy
Sep 1, 2012 at 08:48 PM

I am sorry my misuse of the terms - I wasn’t even aware that I had mixed them up again - brought you into such lengths of arguing, but then, no need to convince me of my mistake, simply replace all verbs and nouns “program(ming)” with “script(ing)” - I usually do that distinction you remind me of here on my own, seems I didn’t gave enough attention to it here.

Pure slapstick, over 4 pages:

http://www.autohotkey.com/community/viewtopic.php?t=81433

= A man from Russia or Ukraine says Russian AI forum is even nicer than English AHK forum, but English AI forum isn’t nice at all. Needs this:

“GUI something really similar to Jitbits macro editor, so i just place actions i need, save it and get script as output

Desired actions:

Mouse Clicks / Movement
Mouse Drags
Keyboard Actions
Loops, ifs,else, this kind of variables
Pixelsearch, image search
Goto,pause,break
Script in a script option
Delays,sleeps
Hotkey assign
working with clipboard
window based activation like (script becomes active only for selected application)
Ability to record macros on fly”

Which brings this comment from tank:

“looks like some pretty robust requirements you might consider starting by hiring a project manager or software architect.”

Finally decides he will search for an AI programmer to do it, notwithstanding the outstanding kindness encountered in AHK forum.

Where’s the slapstick, then?

Well, he’s got 100 bucks to finance the project…

Posted by Slartibartfarst
Sep 3, 2012 at 10:59 PM

@Fredy:
Ah, thanks for the clarification.
The thing is, I found what you wrote - your rationale as to which is better - to be *very* interesting, but I had thought you seemed to be genuinely mixing up or confusing the 2 distinct terms:
(a) “scripting language” and
(b) “programming language”.

If you were confusing them, then I couldn’t see how the discussion could really develop in a constructive/useful way. From experience, any discussion which uses confused/ambiguous or poorly-defined terms would probably tend to suffer similar constraints. There are probably plenty of examples of such, on this and other forums.
For example, and as you wrote:
“There are many “AHK vs. AI” posts in the web, but most of them are simply too much biased in order to be worthwile”.

What you wrote is true, and I don’t really see any value in repeating that sort of a discussion.
But that is why I found the rationale you used in your post interesting - you seemed to be taking the effort to discuss the two things (AHK v. AI) rationally and in an objective manner. However, scattered in your post were some implicit/subjective assumptions - i.e., not stated/substantiated assumptions.
For example: “...but is missing the most important feature of them all, a viable tree structure.”

On reading that last bit, I immediately thought: “What does that mean? Why is a tree structure important? Why is that necessarily the *most* important? When did priority come into this, and why? What does “viable” mean?”
I decided that these things probably reflected your implicit opinion/POV/bias - and I was not interested in discussing whose POV was strongest.

This is why I suggested at the end that:
“t would be interesting to see a formalised set of requirements for a scripting language, but I am unaware of any such - I haven’t come across one in any event.
If we had a set of requirements, then we could use it as a basis for comparison and rapidly tick off whether script language A or B met the requirements, and to what extent.”

If you would like to work with me and other interested parties to draft up such a thing - an objective set of requirements criteria for a scripting language - then we would probably be able to run any existing scripting language through the criteria to establish a checklist of:
(a) Which criteria it met.
(b) To what extent it met the criteria.

That might have the potential to be a tremendously useful exercise for anyone seeking to find a scripting language that met their peculiar criteria. It could help to show the flaws in existing scripting languages, thus pointing constructively to areas for potential improvement. The purpose of such an approach would be a generic and objective analysis of and focus on requirements criteria - not a criticism of the flaws - for any scripting language, offering a powerful basis for comparison.
This could be a decidedly non-trivial exercise. Outside of program development. it is not how most people have likely been trained to think, so might not be of interest to too many people. As a basis for comparison, however, it could be widely useful.
I suspect it is not an original idea, and there may thus be a lot of work already done (e.g., Wikipedia?, university computer science departments) that could save us time.

This would initially start with a sort of knowledge-gathering exercise. To proceed and start to run discovery, we might be able to make good use of an OPEN collaborative working environment - e.g., Google docs, or similar. It would be a constipated process in a discussion thread such as this.

I hope this mostly makes sense or is of use.

Posted by Fredy
Sep 5, 2012 at 10:53 AM

Again, a little misunderstanding, Slatibartfast, and I didn’t even understand why I would have said that “a viable tree structure” would be important in a programming or script language, since if there is any in your scripts (in both) - which then can be replicated / really “shown” by technical means in an editor like emEditor, e.g., but not so much in “folding-only” editors -, it’s made by your own programming / scripting structure, e.g. by your putting things into sub-routines, under headings, sub-headings, and, in scripting and perhaps for many programming tasks also, under a system of “structured, parented” global variables - the script/programming language itself has nothing to do with it (whilst many macro system, e.g., don’t even allow for such a system since they lack global variables and / or if-structures) - in order to do “good work”, I personally and absolutely NEED tree structures, cf. my current thread on using “outliners” or even mindmap applications to do programming, design AND real code - but again, this is not a “language” problem insofar as there might be working environment for specific languages that offer most of what I’m looking here for within external tools I try to combine.

Back to initial question, I searched for the term you don’t like in my little comparison, and heureka! This is an “outliner” forum, so if you speak off-topic, you must force a (natural or artificial) connection between what you’ve got to say and “outliners” (in a broad sense though), and there is Prof. Manfred Kuhn with his blog “takingnotenow” (“note” in singular!) who “advertized” both AHK and CT, and I was referring to the latter here, and also I said I’m ambivalent about his hint to the former - in fact, I have the feeling that if I knew AI better, then perhaps I could use AI even for “normal macro purposes” and wouldn’t be in my current “need” to use AHK, in order to get easy text expansion (where one of the probs is you’ll constantly do lots of changes, extensions, so you need quick access and quick rebuilding); as for AHK’s easy way of key bindings, this is quickly put into perspective once you’ll use global “scope” / “context” variables / other means of scope or context in either script language, since then your whole construction will perhaps be turned upside down anyway, cf.

http://www.autohotkey.com/community/viewtopic.php?f=1&t=91871

so that the advantage of AHK would be reduced to have (much) quicker initial “results” when you can’t start from a functional “standard” script from somebody else in which you’ll then make all the necessary amendments “by example” - hence the big market for commercial (and mostly far inferior) “macro tools” where you get initial results within minutes (which would be possible with either AHK and AI if there were such “start from here” scripts easily available in either.

Another (totally unnecessary) problem is AI forum’s paranoia vs. possible “game scripting misuses” of that language, and almost total censorship in that direction, which means that when you ask questions there in order to have your “outliner” enhanced, you’ll get heavy reprimanding THAT (= not why) game scripting isn’t allowed! And this ridiculous phenomenon heavily impedes your ability, as an AI newbie, to do your very first key binding to start with, whilst in AHK, you do a “^t:: command”, and you’re done. Thus, saying that the AI crowd seems to remain “select” - “programmers only please, no laymen who don’t know nothing about what we do here” -, would not be totally diffamatory, it seems.

In the end, it comes to “how to do easy text expanding with AI also”, and then - if you know both programs well and need elaborate scripting - you wouldn’t look back at AHK I fear, since it’s too much hampered by its “micro syntax folly” and absence of standard array processing, whilst you could finally do with its “macro syntax” idiosynchrasies - and, there are lots more of “commands”, etc. (= inbuilt functions, etc. - string processing is particularly poor in AHK, and hampered by its “micro syntax” issues on top of that!) in AI’s commands list. Many people say they don’t like AI’s syntax because of its “Visual Basic” character / similitude - ok, but “anything” is better than what AHK has to offer instead.

Thus, my conclusion was, I started for my “normal” scripting needs - “macros” over all applications, not special tasks within a multiple text files environment for data processing - with AHK, and here, with now some 3,000 lines of code (without even having started text expansion here), I’m a little bit stuck with it for now, all works very well, but I’d prefer to have it all within AI, on condition that I could do easy text expansion there as well.

There isn’t the slightest doubt that one, AHK is the much more “accessible” script language for a non-programmer, and that two, for heavy scripting, AI is indeed the superior language, and be it for the fact alone that your code, for sophisticated tasks, will be much more compact, whilst in AHK, you must first overcome many little (and totally unnecessary) problems for which you’ll do a lot of additional (unnecessary) coding.

As said, AI, by the men behind it (and who can be exceptionally rude then), clearly doesn’t want to be a “general use macro language”, “beginners stay off, please”, but for anybody willing to cope with this, it seems to offer the far better scripting possibilities. Hence my current being stuck with the need to concurrently use both languages, which cannot be it long-term.

As for any tries to “virtually design” the perfect scripting language, this bumps into the same barrier as we encounter with “perfect outliners” or whatever: The developers of the existing stuff just do their thing, the market is “taken”, and even for totally obvious follies that are evident to everyone, they won’t even discuss abolition but insist of preserving their marks. There is certainly a more viable approach: Enhancement of the fori, installing a tree structure (again!) in them, not allowing any more “help me!” posts, but fractionizing and clear denomination / classification of questions for help, etc., and then category structures with cloned threads, both for technical problems within the language and for applications to spice up, with such standard scripts, i.e. bringing order into the current chaos of such fori as AHK’s, with currentloy about 70,000 different threads in which searching, most the time, is fruitless.

I’m saying, at the end of the day, most people would need rather similar things, in identical / similar applications, and today, there is nothing provided for this underlying need structure, meaning incredible amounts of wasted time, both on the asking as on the responding side. The web itself is a mess, and this absence of structure is propagated into the depths of most of the sites constituting it.

Pages: 1 2 >

Back to topic list