Autohotkey vs. AutoIt
Started by Fredy
on 9/1/2012
Fredy
9/1/2012 3: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.
I
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...)
II
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.
IV
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...
V
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.
VI
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.
IX
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.
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.
I
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...)
II
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.
IV
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...
V
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.
VI
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.
IX
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.
Slartibartfarst
9/1/2012 6: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.
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.
Fredy
9/1/2012 8: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...
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...
Slartibartfarst
9/3/2012 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:
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.
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.
Fredy
9/5/2012 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.
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.
Fredy
9/5/2012 11:24 am
Edit: Thus, the irony is: Many people discuss the "the web never forgets" phenomenon, whilst in its day to day use, the real problem is not unwanted storage beyond your original intention, but that info, help, etc. given here and today, will be "lost" tomorrow, needing the same info being reformulated again and again, instead of a global attack on this much evident access contradiction: It's all there, but since they all solely rely on "searching", you won't find it anymore (with reasonable "cost"), so it's produced anew and anew. Of course, there had been strivings to attack this, at least in big-scope fields. Yahoo's cataloging things, anyone? Cannot be automatted enough, is too expensive, is hence done with. Today's "overview" / "comparison" sites are mostly conceiled advertising, i.e. they push select offerings which pay for that, if the sites don't secretely belong to that manufacturer wanting to push his product to begin with.
And again, it's not a question of "it's free, hence we can't expert the effort" - first, all the effort is given, bad very badly applied, it's squandered for a very good part; second, what would be 100 bucks a year, or say 75, for real good, useful things you'd have easy access to? Always remember the tco, which nowadays can be immense, for many such "free" or ostensible "cheap" offerings.
In our times, much "secretarial work" isn't done anymore where it would produce big returns, be it in today's corporations or in "communities" in all sorts, hence incredible waste of time and efforts given - and literally an "internal brain drain" - to mean tasks.
And again, it's not a question of "it's free, hence we can't expert the effort" - first, all the effort is given, bad very badly applied, it's squandered for a very good part; second, what would be 100 bucks a year, or say 75, for real good, useful things you'd have easy access to? Always remember the tco, which nowadays can be immense, for many such "free" or ostensible "cheap" offerings.
In our times, much "secretarial work" isn't done anymore where it would produce big returns, be it in today's corporations or in "communities" in all sorts, hence incredible waste of time and efforts given - and literally an "internal brain drain" - to mean tasks.
Fredy
9/5/2012 1:33 pm
Double Edit:
Last Edit here-above: Of course, I wanted to say, it's wrong to say, we can't AFFORD (to pay for) these efforts", since the resources are spent anyway, they are just very badly attributed today.
"Inline outlining": I just had a look into my 15years-old source code, and indeed, I had such (very basic) "switching" routines there already, even for just one indentation level only, both-ways: "Make the headings plus following paragraphs a sibling of the current item" (= the heading becoming the new item's title; for this I "understood" that single-line paragraph were "headings"), and "Make the selected items (= all siblings) as body text, with headings".
So it seems that I afterwards got too far away from this need, i.e. negated it, from lack of any "outliner" doing this switching for me (and not considering doing the necessary switching by hand, one paragraph / item a time, except when really necessary). Today, I see that with just a little bit of scripting, the same (= this very basic way, with just one indentation level and considering ALL content of a given item as such a body to be transposed into several sibling items) could be done within any outliner(2/3) of your choice - but here again, an array would be extremely helpful in order to do so, at least for the "paragraphs into different items" direction (= differentiating the paragraphs from the headings within a text body within memory, within the scripting language, not having the scripting language switch forth and multiple times between tree and content field, doing multiple cuttings and pastings - this is what differentiates a script from dumb macro execution), and again, even in AHK_L, even two-dimensional arrays are an awful and totally way-off any standardization thing to do - and of course, this "amateurish" character of AHK does bother me, again and again, so I'm not really happy with this "easy-access" scripting language.
But then, again: Why professional developers, in 2012, unable to integrate at least some basic, one-level switching between content and tree, when I was able to do it 15 years ago (and it wasn't complicated for me): again, this "good enough quality" stance of theirs (even when what we're asking wouldn't be really an effort for them) is revolting imho.
Last Edit here-above: Of course, I wanted to say, it's wrong to say, we can't AFFORD (to pay for) these efforts", since the resources are spent anyway, they are just very badly attributed today.
"Inline outlining": I just had a look into my 15years-old source code, and indeed, I had such (very basic) "switching" routines there already, even for just one indentation level only, both-ways: "Make the headings plus following paragraphs a sibling of the current item" (= the heading becoming the new item's title; for this I "understood" that single-line paragraph were "headings"), and "Make the selected items (= all siblings) as body text, with headings".
So it seems that I afterwards got too far away from this need, i.e. negated it, from lack of any "outliner" doing this switching for me (and not considering doing the necessary switching by hand, one paragraph / item a time, except when really necessary). Today, I see that with just a little bit of scripting, the same (= this very basic way, with just one indentation level and considering ALL content of a given item as such a body to be transposed into several sibling items) could be done within any outliner(2/3) of your choice - but here again, an array would be extremely helpful in order to do so, at least for the "paragraphs into different items" direction (= differentiating the paragraphs from the headings within a text body within memory, within the scripting language, not having the scripting language switch forth and multiple times between tree and content field, doing multiple cuttings and pastings - this is what differentiates a script from dumb macro execution), and again, even in AHK_L, even two-dimensional arrays are an awful and totally way-off any standardization thing to do - and of course, this "amateurish" character of AHK does bother me, again and again, so I'm not really happy with this "easy-access" scripting language.
But then, again: Why professional developers, in 2012, unable to integrate at least some basic, one-level switching between content and tree, when I was able to do it 15 years ago (and it wasn't complicated for me): again, this "good enough quality" stance of theirs (even when what we're asking wouldn't be really an effort for them) is revolting imho.
Fredy
9/5/2012 2:06 pm
And you need a command "make this paragraph / the selection a new sibling/child" (making the first line, if there is any independant first line above, the item's name) - very easy indeed.
And the aforementioned group switching in both directions, most of the time, the (easy-to-script/program) just ONE indentation level is perfectly sufficient, since we're speaking of the outliner(2/3) variety here where most of the time, you wouldn't go for several indentation levels within the content - using an outliner(1) then instead -, but you would do - as in programming within an outliner - just the deepest level of your outline indentation within your text body, processing higher levels within the tree, and hence the necessity of shuffling your current deepest level (only) into the tree whenever you recognize the the need of further deepening your indentation within a given sub-tree, and, respectively, the necessity of combining several, originally separate items into just one item when you realize that here, there will not bee the need of further indentation you had initially foreseen. Thus, what at first sight doesn't appear but as a pis-aller (since it's basic but easy to implement), is in fact, even long-range, a viable, sufficient solution. But of course, a developer must first SEE that such a very basic solution, not asking much of his programming efforts, would indeed be perceived as perfectly satisfying by most possible users of his program, in order to not be ashamed of presenting it as a new feature. Hence the interest of for them to have some glance into this forum, here and then. ;-)
And the aforementioned group switching in both directions, most of the time, the (easy-to-script/program) just ONE indentation level is perfectly sufficient, since we're speaking of the outliner(2/3) variety here where most of the time, you wouldn't go for several indentation levels within the content - using an outliner(1) then instead -, but you would do - as in programming within an outliner - just the deepest level of your outline indentation within your text body, processing higher levels within the tree, and hence the necessity of shuffling your current deepest level (only) into the tree whenever you recognize the the need of further deepening your indentation within a given sub-tree, and, respectively, the necessity of combining several, originally separate items into just one item when you realize that here, there will not bee the need of further indentation you had initially foreseen. Thus, what at first sight doesn't appear but as a pis-aller (since it's basic but easy to implement), is in fact, even long-range, a viable, sufficient solution. But of course, a developer must first SEE that such a very basic solution, not asking much of his programming efforts, would indeed be perceived as perfectly satisfying by most possible users of his program, in order to not be ashamed of presenting it as a new feature. Hence the interest of for them to have some glance into this forum, here and then. ;-)
Slartibartfarst
9/6/2012 3:30 am
In your Opening Post you made a start in trying to gather an objective comparison - AHK vs. AutoIT.
You seemed to want to avoid repeating history, when you wrote:
I pointed to the issue possibly being lack of a handy comparison tool for carrying out a rapid objective comparison between 1 or more scripting languages - rather than making an(other) AHK vs. AutoIT comparison, and suggested a generic sort of "requirements-criteria checklist" approach for scripting languages.
That doesn't seem to have appealed to you.
So we are presumably left with making the comparison - AHK vs. AutoIT - in this thread.
Though AHK-L seems to be a perfectly good scripting tool for my purposes - having used it for a while - I am ignorant of AutoIT.
Since engaging in this discussion, I have had a look over the AutoIT website, and I think it looks very interesting. I also noticed this:
"Also supplied is a combined COM and DLL version of AutoIt called AutoItX that allows you to add the unique features of AutoIt to your own favourite scripting or programming languages!"
Presumably, that might indicate that AutoX calls could be made from within AHK-L(?). So you could maybe try for the best of both worlds. I am not sure about doing it the other way - i.e., from AutoIt-->AHK.
Anyway, the idea seemed interesting, but I have not tried it.
You seemed to want to avoid repeating history, when 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”.
I pointed to the issue possibly being lack of a handy comparison tool for carrying out a rapid objective comparison between 1 or more scripting languages - rather than making an(other) AHK vs. AutoIT comparison, and suggested a generic sort of "requirements-criteria checklist" approach for scripting languages.
That doesn't seem to have appealed to you.
So we are presumably left with making the comparison - AHK vs. AutoIT - in this thread.
Though AHK-L seems to be a perfectly good scripting tool for my purposes - having used it for a while - I am ignorant of AutoIT.
Since engaging in this discussion, I have had a look over the AutoIT website, and I think it looks very interesting. I also noticed this:
"Also supplied is a combined COM and DLL version of AutoIt called AutoItX that allows you to add the unique features of AutoIt to your own favourite scripting or programming languages!"
Presumably, that might indicate that AutoX calls could be made from within AHK-L(?). So you could maybe try for the best of both worlds. I am not sure about doing it the other way - i.e., from AutoIt-->AHK.
Anyway, the idea seemed interesting, but I have not tried it.
Fredy
9/9/2012 11:22 am
Slatibartfast, for strict "ahk VERSUS ai" subject here, don't count on me, but I'm certainly willing to share valuable hints for both script languages here, and I absolutely try to not becoming biased without further notice (which would perhaps be possible after better knowledge of text expansion within / by AI).
As for your triggering AI scripts by AHK, I didn't try yet but it should be VERY easy, please let me explain (but perhaps I'm mistaken in part, corrections are always welcome).
Basics:
a ) Every (?) macro tool works in a similar / identical way: It's running continuously even if you ain't aware of this. So it causes a certain load on your computer resources, which may be more or less heavy perhaps, depending on the expertise it is programmed. The same goes for scripts that run continuously; here you also have YOUR say in determining the load since you can assign functionality (= by scope and context) by different ways (cf. the above link to the AHK forum I gave as an example - and a rudimentary example, without global variables to be constantly checked, let alone multiple ones).
Normal macro tools do NOT allow for you deciding upon the frequency the underlying script running again and again, neither does AHK for such continuously running scripts, but AI allows for your deciding upon it, so possibly such AI scripts can run in a more smooth way - this would have to be checked with very big scripts.
The continuous run - if you see it in AI or don't in AHK or commercial macro tools - is, of course, because the tool / script has to intercept any possible key pressing and then to check if there is any special subscript to be executed, or if it is expected to let pass the key pressing, in order for your pressing "h", e.g., in your text program, to become a simple "h" on your screen and within the text you're producing.
In theory, a tool that doesn't allow for simple keys, as the "h" in our example, could exert less such system load, since normal key pressings would simply bypass the running script, whilst it would intervene only in key combinations and "F" key pressings and such, but then, it's only when you start to use even normal key pressings, like pressing of the "h" key, as special commands depending on scope and context that things become really interesting, so it would be dumb to confine your possibilities to "special key combinations only".
Also, any key expansion would need "total interception" and not only the interception of special combinations, so you see that for any such tool, even a commercial one, it's a good things to "intercept anthing", hence a certain system load - if you had a 8088 processor, you'd certainly run into trouble then...
I do NOT think that running TWO such ever-running scripts simultaneously, would be a good idea, except for scripts with rather confined scope, e.g. I use an additional Cherry 4700 keypad, besides my normal keypad, and the 4700 script only works on the 21 keys of that additional keypad, without causing trouble (but on the other hand, AHK and AI are NOT able to intercept the commands sent from that script): if you want better functionality, you must buy an additional keyboard from Preh or X-Keys which have both inbuilt Eproms, which means there is NO running script there but you intercept the sent scan codes there by AHK or AI without any problem, in the form "key a1 on your Preh / X-Keys keyboard sends "shift-control-alt-a", and AHK/AI does this command xzy whenever "shift-control-alt-a" is triggered".
b) From these ever-running scripts, you must distinguish once-running scripts which can be done in any language, and which do NOT intercept key pressings, but just do what they are meant to do whenever they are triggered, and then close (or run forever by mistake if you made a programming error - I don't say "scripting error" since I think that the activity might be called "to program a script" and not "to script a script" - there are distinctions to be avoided in order to avoid ridicule imo). For such "self-contained scripts" as you might call them, I think there is no problem whatsoever to trigger them from within everything, even from within any cheap macro tool that is able "to run a program", and remember, the "ever-running" script (AHK, AI, or a macro tool) does NOT interfere here since it intercepts any (physical only? physical or "virtually physical", cf. above, both script languages do NOT intercept other programs' "key pressings" but scan codes only, even sent by virtual key combinations - Preh, X-Keys), hence it will "let run" your external script, just like it would "let run" any external program that it triggered. Hence I don't see any special problems here, nor do I see special technical means needed in order to run such scripts, hence my thinking that there is total availability of such AI scripts from within AHK and vice versa.
Scope AND context
As I said earlier, some macro tools allow for "macro scope" = application scope, but very few allow for "micro scope" = scope within a given application, i.e. doing different things depending on which "control" of a given application has focus. But then, e.g., it's evident you can almost double your normal key assignments if you have control over them depending on the alternative "focus within tree vs. focus within text field" of your outliner, let alone focus on the various panes within such outliners like MI or UR; the same goes for CT, of course.
All this is about using your NORMAL keyboard for most of your things, with "mnemonically decent" keys / key combinations, instead of having to multiply your additional keyboards (or to refrain from further scripting).
Btw, I own a Preh 128 keys keyboard, and I don't use it anymore, since most of the keys there are WAY to far away from my main keyboard, and so, even complicated key combinations on my main keyboard are easier to trigger than many of my additional "simple" key commands on that expensive additional keyboard. On the other hand, Preh's 30-keys keyboard is ideal for putting to the left of your normal keyboard (on which, of course, you'll assign many additional commands on your numeric keypad (to the right; vice versa for lefthanders, of course) in most applications).
But I quickly have realized that "micro scope" just by "controls" is rather poor again: What about having a context: "Within your text pane, have the same keys trigger different commands, depending on the alternative, "is there something selected there currently, or is there not?"" - it's evident you'll have many new possibilities here, as soon as you are able to program (or for Slatibartfast: "to script") this alternative; cf. here:
http://stackoverflow.com/questions/3381451/catch-copy-paste-of-empty-text-on-windows-from-autohotkey-script
And so on, and so on, once you begin with all these, you quickly realize that most developers ain't interested but in the money, and certainly not in the sheer excellence of their products, since everything we do here, with big pains, from the outside, they could implement INTO their programs, from the inside, making them sheer pieces of art.
But no. Which leaves room for us to do a little programming of our own, called scripting. ;-)
As for your triggering AI scripts by AHK, I didn't try yet but it should be VERY easy, please let me explain (but perhaps I'm mistaken in part, corrections are always welcome).
Basics:
a ) Every (?) macro tool works in a similar / identical way: It's running continuously even if you ain't aware of this. So it causes a certain load on your computer resources, which may be more or less heavy perhaps, depending on the expertise it is programmed. The same goes for scripts that run continuously; here you also have YOUR say in determining the load since you can assign functionality (= by scope and context) by different ways (cf. the above link to the AHK forum I gave as an example - and a rudimentary example, without global variables to be constantly checked, let alone multiple ones).
Normal macro tools do NOT allow for you deciding upon the frequency the underlying script running again and again, neither does AHK for such continuously running scripts, but AI allows for your deciding upon it, so possibly such AI scripts can run in a more smooth way - this would have to be checked with very big scripts.
The continuous run - if you see it in AI or don't in AHK or commercial macro tools - is, of course, because the tool / script has to intercept any possible key pressing and then to check if there is any special subscript to be executed, or if it is expected to let pass the key pressing, in order for your pressing "h", e.g., in your text program, to become a simple "h" on your screen and within the text you're producing.
In theory, a tool that doesn't allow for simple keys, as the "h" in our example, could exert less such system load, since normal key pressings would simply bypass the running script, whilst it would intervene only in key combinations and "F" key pressings and such, but then, it's only when you start to use even normal key pressings, like pressing of the "h" key, as special commands depending on scope and context that things become really interesting, so it would be dumb to confine your possibilities to "special key combinations only".
Also, any key expansion would need "total interception" and not only the interception of special combinations, so you see that for any such tool, even a commercial one, it's a good things to "intercept anthing", hence a certain system load - if you had a 8088 processor, you'd certainly run into trouble then...
I do NOT think that running TWO such ever-running scripts simultaneously, would be a good idea, except for scripts with rather confined scope, e.g. I use an additional Cherry 4700 keypad, besides my normal keypad, and the 4700 script only works on the 21 keys of that additional keypad, without causing trouble (but on the other hand, AHK and AI are NOT able to intercept the commands sent from that script): if you want better functionality, you must buy an additional keyboard from Preh or X-Keys which have both inbuilt Eproms, which means there is NO running script there but you intercept the sent scan codes there by AHK or AI without any problem, in the form "key a1 on your Preh / X-Keys keyboard sends "shift-control-alt-a", and AHK/AI does this command xzy whenever "shift-control-alt-a" is triggered".
b) From these ever-running scripts, you must distinguish once-running scripts which can be done in any language, and which do NOT intercept key pressings, but just do what they are meant to do whenever they are triggered, and then close (or run forever by mistake if you made a programming error - I don't say "scripting error" since I think that the activity might be called "to program a script" and not "to script a script" - there are distinctions to be avoided in order to avoid ridicule imo). For such "self-contained scripts" as you might call them, I think there is no problem whatsoever to trigger them from within everything, even from within any cheap macro tool that is able "to run a program", and remember, the "ever-running" script (AHK, AI, or a macro tool) does NOT interfere here since it intercepts any (physical only? physical or "virtually physical", cf. above, both script languages do NOT intercept other programs' "key pressings" but scan codes only, even sent by virtual key combinations - Preh, X-Keys), hence it will "let run" your external script, just like it would "let run" any external program that it triggered. Hence I don't see any special problems here, nor do I see special technical means needed in order to run such scripts, hence my thinking that there is total availability of such AI scripts from within AHK and vice versa.
Scope AND context
As I said earlier, some macro tools allow for "macro scope" = application scope, but very few allow for "micro scope" = scope within a given application, i.e. doing different things depending on which "control" of a given application has focus. But then, e.g., it's evident you can almost double your normal key assignments if you have control over them depending on the alternative "focus within tree vs. focus within text field" of your outliner, let alone focus on the various panes within such outliners like MI or UR; the same goes for CT, of course.
All this is about using your NORMAL keyboard for most of your things, with "mnemonically decent" keys / key combinations, instead of having to multiply your additional keyboards (or to refrain from further scripting).
Btw, I own a Preh 128 keys keyboard, and I don't use it anymore, since most of the keys there are WAY to far away from my main keyboard, and so, even complicated key combinations on my main keyboard are easier to trigger than many of my additional "simple" key commands on that expensive additional keyboard. On the other hand, Preh's 30-keys keyboard is ideal for putting to the left of your normal keyboard (on which, of course, you'll assign many additional commands on your numeric keypad (to the right; vice versa for lefthanders, of course) in most applications).
But I quickly have realized that "micro scope" just by "controls" is rather poor again: What about having a context: "Within your text pane, have the same keys trigger different commands, depending on the alternative, "is there something selected there currently, or is there not?"" - it's evident you'll have many new possibilities here, as soon as you are able to program (or for Slatibartfast: "to script") this alternative; cf. here:
http://stackoverflow.com/questions/3381451/catch-copy-paste-of-empty-text-on-windows-from-autohotkey-script
And so on, and so on, once you begin with all these, you quickly realize that most developers ain't interested but in the money, and certainly not in the sheer excellence of their products, since everything we do here, with big pains, from the outside, they could implement INTO their programs, from the inside, making them sheer pieces of art.
But no. Which leaves room for us to do a little programming of our own, called scripting. ;-)