Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

AutoHotkey as programming language


  • Please log in to reply
62 replies to this topic

Poll: Do you think people would use it as a programming language? (84 member(s) have cast votes)

Do you think people would use it as a programming language?

  1. YEAH!!! (57 votes [53.27%])

    Percentage of vote: 53.27%

  2. yes (20 votes [18.69%])

    Percentage of vote: 18.69%

  3. maybe (16 votes [14.95%])

    Percentage of vote: 14.95%

  4. not really (6 votes [5.61%])

    Percentage of vote: 5.61%

  5. NO WAY. (8 votes [7.48%])

    Percentage of vote: 7.48%

Vote Guests cannot vote
not-logged-in-daonlyfreez
  • Guests
  • Last active:
  • Joined: --
Can you then explain to me, a non-programmer, what is so 'very messy' about AHK? Sure, in some cases, compatibility with the old AutoIt2 makes the order of values the comma-seperated one-line commands a bit messy, but other than that?

Most 'higher order' programming languages - in my view (non-programmer) - add a lot of characters that I don't really think are necessary, like the semicolon at the end of a line, or put all values between quotes, or the need to specifically define everything...

If you simply don't like/cannot get used to the comma-seperated style syntax... well... I find it very easy to use.

I don't think AHK was created to be a programming language, but more a rapid-scripting and automation language, with the emphasis on that, and ofcourse 'borrowing the best' of the 'real languages'.

What is missing from AHK that would make it a 'real' programming language then?

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005

Can you then explain to me, a non-programmer, what is so 'very messy' about AHK? Sure, in some cases, compatibility with the old AutoIt2 makes the order of values the comma-seperated one-line commands a bit messy, but other than that?

Indeed, being compatible with AutoIt2 make the syntax heavier: there is a lot of context-sensitive exceptions.
I am just reading the doc, taking notes to perhaps do some day a lexer for SciTE (Scintilla), and I fear it is not an easy task because AHK has not a regular syntax (variables with or without %, strings with ou without delimiters, similar syntax for hotkeys, hotstrings, key mapping (can I use : in these?), etc.
Indeed, Chris as added some stuff to ease the pain, like braces, better control flow, optional first comma, etc. But still, it is quite messy and hard to parse for a simple lexer.

I chose AutoHotkey over AutoIt3, despite that. The syntax was a showstopper, but the fact that AutoIt3 has reverted to a closed source policy was also a showstopper.
And indeed, the management of hotkeys by AutoHotkey is powerful...

Like Bill, I am dreaming of using some of AutoHotkey features in a "real" programming language. I am thinking of Lua, which is small, fast, powerful yet easy to learn.
If I had some free time, I would try and integrate some of AHK code as a Lua library, that would give nice syntax, true language power and powerful integration to Windows.

Well, I am a bit uneasy with the GPL status of the code, I much prefer something like BSD... But I suppose Chris as no choice here, as original code is GPL.
I have even seen criticism on the way GPL has been applied...
I have not seen the original code of AutoIt (I don't know if it can still be found somewhere), but the little I saw from the AHK code seems quite personal, with lot of comments seemingly from Chris (giving credit to AutoIt3 where due), etc.
The source is quite clean and readable. I would have broken down more some files, like the gigantic script.cpp, but beside than, it is nice.

Most 'higher order' programming languages - in my view (non-programmer) - add a lot of characters that I don't really think are necessary, like the semicolon at the end of a line, or put all values between quotes, or the need to specifically define everything...


:-) You are kidding, right?
At least 95% of the languages I know use these "unecessary" chars, primitive batch-like syntax like AutoIt2/AHK is fortunately quite scarce.

Semi-colons allows to put several instructions per line. Indeed, nowadays this is frown upon as bad style, but they are here for a reason, and it was a relief from languages with hard-coded positions like the early Fortran.
Modern script language like JavaScript or Lua make them optional... That's a good thing.

To put strings in quotes are sometime necessary to lift ambiguities. That's that, or using lot of escape chars. And I prefer a "regular" syntax, that apply in all cases.
Note that some (script) languages are quite flexible in these quotes, using single or double quotes, or a special syntax for multiline strings.

The need to "define everything" (variable declaration I suppose) is mostly true for compiled languages, rarely for interpreted ones (script languages).
Both approaches are useful: using declarations allows to detect errors early, enforce strictness; omitting them and using typeless variables allows for flexibility and quick writing.
The first approach is paramount for large projects, made by lot of developpers, using strict specifications; the second one is useful to get fast results on small projects.

If you simply don't like/cannot get used to the comma-seperated style syntax... well... I find it very easy to use.


:-) To each its own. I am not fan of this syntax, but I used in AutoIt2 some years ago, and I can get used to it.
Actually, it is not very far from classical function call.
The most disturbing stuff is when I see lines like:
SomeCommand,,,,,, A parameter
A good text editor can help here :-)

I don't think AHK was created to be a programming language, but more a rapid-scripting and automation language, with the emphasis on that, and ofcourse 'borrowing the best' of the 'real languages'.


I fully agree here.
AutoIt2 was just that at the start. People started to make computing using external command-line calculators (I even made one), went to great lengths to parse file content, etc. Jon started to add some expressions and string handling, but it was awkward with the native syntax...

Note that although using a "real" language wrapper would be nice - or, more exactly, having some of AHK capabilities in the language of my choice would be fabulous - I do believe, and this thread enforce my belief, that the current state of AHK is a good thing, as it seems less intimidating to beginners than a more classical language.

I can even imagine a graphical IDE where users grab visual representations of AHK commands and drag them in place, connecting them, etc.

What is missing from AHK that would make it a 'real' programming language then?


As savage notes, AHK is turing-complete, ie. you can do anything a "real" programming language can do, even if it can take some work.
I certainly won't use it to create a graphical game, supposing it has SDL or OpenGL bindings... It is not made for this, and this would be ridiculous.
AHK is great for automating stuff, and that's why I started to learn it.
For more complex algorithms, like accessing databases, really complex GUI, Web programming (CGI) or such, I would use C, C++, [Visual] Basic, Java, PHP, Lua or some other language.

The reason there is a trillion different languages is that each one fill a little niche (Web page scripting, Web application, network access, scientific calculation, financial application, etc.), because some people prefer "if Foo then DoThis else DoThat end" to "Foo ? DoThis : DoThat", because there are big and small projects, running embedded or on large computer, etc.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

...the little I saw from the AHK code seems quite personal, with lot of comments seemingly from Chris (giving credit to AutoIt3 where due), etc.

If you're curious about which commands are based on AutoIt source without having to delve into the source code, see http://www.autohotke... ... 9710#19710

Thanks for all your insightful comments.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
I think this really boils down to: What do you consider to be a 'real' programming language? Why should AutoHotkey follow the same syntax, structure, etc... as many other languages? The unique style that it has is very likely what so many people love about it.

I would already consider AHK to be a 'real' programming language. Unconventional maybe, but certainly 'real'. There are a few things that would be cool to have built-in that would make programming vs scripting a bit easier but that's true with many, many so called 'real' programming languages IMO. For building larger programs, the structure isn't too bad and very readable compared to many C based languages. The real difference is in the amount of flexibility. Lower level languages obviously have more flexibility but development time and learning curves also increase drastically in most cases. Much of this flexibility exists in AHK already though. There's also nothing stopping someone from using a dll file to extend functionality in their AHK programs. This method is used in many other 'real' languages also.

Maybe some people don't consider AHK to be a 'real' language because it's interpreted? So are many other so called 'real' languages... A language capable of scripting and program development seems pretty 'real' to me ;) ...

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
What differentiates AHK from many programming languages is the baggage it carries: compatibility with older versions and AutoIt2. There are many exceptions, special handling of certain parameters. Semantics differ dependent on the number of parameters. You always have to check in the help if an expression is allowed in a particular place. There seem to be no reason that a loop cannot parse literal strings or strings resulted from expressions. Many commands take only a variable name as an input parameter, while expressions would be really handy.

Most of these restrictions or context sensitive syntax allow writing compact codes, others make matters more complicated. Any syntax of other programming languages conflicts with the utmost simplicity of constructs like "a::b", or "::btw::by the way". Keeping these valid with a more uniform syntax would necessitate many exceptions, so we don't gain much. AHK is still in version 1.0.xx, that is, we should see improvements. What is more important: cool features or a uniform syntax? I think we ought to figure out first the important features, and later we (meaning Chris) could change the syntax to create a more traditional programming language (maybe by the way of a translator).

I would try and integrate some of AHK code as a Lua library

The other way around is easy: run LUA with a program edited with AHK from AHK. You can use AHK to create a fancy GUI for user input/output, activate the program by hotkeys, get parameters via the ClipBoard, etc., but the computation, like regular expression search, table manipulation or just fast arithmetic can be done in LUA.
AHKvar = 14
expression = print(math.exp(math.log(math.abs(%AHKvar%))*2))

FileDelete C:\LUA.IN
FileAppend,
(
   c = 1+2*3-%AHKvar%
   print(c)
   %expression%
)
, C:\LUA.IN
RunWait %COMSPEC% /c C:\LUA\bin\lua.exe C:\LUA.IN > C:\LUA.OUT,,HIDE
FileRead result, C:\LUA.OUT
MsgBox %result%


  • Guests
  • Last active:
  • Joined: --
Well, i'm totally new to AHK, but it seems to be a quite handy tool. My first thought of it was "Oh no, not another program with it's own scripting-language...", so i think a great feature would be to use a standard scripting-language like JavaScript to ease the use of AHK by just using AHK classes and functions from an easy to learn and well documented standards scripting-language. I think, this would make it much easier for people to get into AHK and start right away with making their own scripts...

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
I'm not trying to be difficult, but, why not just use JavaScript instead if you are comfortable with it? If you were looking for pure JavaScript scripting, you likely took a wrong turn somewhere ;) .

thomasl
  • Members
  • 92 posts
  • Last active: Sep 28 2006 09:55 AM
  • Joined: 16 Jun 2005
Another of these discussions that will lead nowhere... as long as AHK is coaxed into doing two incompatible things at the same time*, this problem will not go away.

AHK's syntax is so inscrutable (to put it mildly) that I have all but stopped writing stuff in it. I now use an approach similar to what was already proposed: using it as a front end for a serious scripting language. That works but it's a PITA (though less of a PITA than trying to come to grips with the AHK syntax).

There are two things only that AHK does really well and that keep me with the app: the rock solid hotkey/hotstring handling and the GUI commands. The rest is crap (to put it harshly).

*
1. a simple, backwards-compatible tool for quick&dirty jobs
2. a fully-fledged tool for complex automation tasks

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
I understand completely how someone with a strong programming/scripting background would feel that way. Although some improvements to the syntax are planned, it may be a long time before backward compatibility is relinquished, if ever.

On the other hand, some people (even those from a programming background) have said they like the current syntax, such as the lack of need for parentheses around parameter lists and quotes around literal strings. I like it too, ever since I discovered AutoIt v2 some 5 years ago -- though clearly it has its weaknesses.

For those who hate the command-style syntax, commands may be wrapped into functions and included via #Include (such as Titan's collection). This provides a more conventional syntax consisting solely of expressions and function calls.

Finally, some syntax enhancements are planned for the near future that focus on usability (such as the inability to have a space between a function's name and its open-parenthesis) and catching bugs the moment a script launches (such as misspelled variable names).

toralf as guest
  • Guests
  • Last active:
  • Joined: --
I consider AHK a real and serious scripting language.
I love it for the GUI commands and they are the reason I started with AHK. I was looking for a way to automate processes that span over several software products. And I could do it with AHK kind of easy. The kind of easy is due to the difficulty to automate other programs which are kind of blocking. If you stay inside AHK or with command line tools it IS easy. The learning curve is short and low IMO compared to other "real" languages that can be used to create executables.

I'm not a fan of classes and inheritation (OOP), although it has some very powerful features. And I disagree that classes and functions (even when well documented) would make it people much easier to get into AHK. Several would be scared away. I agree with corrupt on this, if the user is used to a OOP-script language, he can use it. AHK has a different target group.

At work we are a bunch of mech. engineers, with only little programming experience. AHK is so simple to read, that all of us can manipulate the code if it is needed. Only one has to write it first (which is mostly me ;) ). Of cause some code seams to be awkward, but if you know a better or more elegant way, I'm sure it will be incorpoarted into AHK. As for the syntax I do not have a problem with it. Ok, I have to look up the commands as well once in a while, but who doesn't with other languages?

When I read this topic, it gets to my mind that some "real" programmers would like to have some AHK features but would like to stick with a "real" language/syntax. As a AHK follower I could ask as well, why the other languages don't incorporate these AHK features? Then the "real" programmers would be happy too, right?

There had been a different topic on when to cut off backward capability and when to redo the syntax. Which might be with AHK 2.0 if I remember right. But this is not even planed yet, since it would require a lot of rewriting of code. But you all could help if you would give Chris a hand to help programming. I can't since I'm not familiar with C++.

I'm happy with AHK as it is. I'm just missing new GUI commands. :)

Ciao
toralf

thomasl
  • Members
  • 92 posts
  • Last active: Sep 28 2006 09:55 AM
  • Joined: 16 Jun 2005

it may be a long time before backward compatibility is relinquished, if ever.

In my view there's only one sensible way to get rid of the dreaded backwards compatibility problem and that would be to split the product. But it seems clear after the many comments I read about this issue that this is not going to happen anytime soon... if ever.

That's okay, I can live with what I have got.

On the other hand, some people (even those from a programming background) have said they like the current syntax

And some other people (even those from a programming background) like being whipped and spanked... so what exactly are you trying to say? That AHK's syntax is not that bad after all?

There's only one way AHK can blossom into a serious scripting language and that is to throw the current syntax away (once and for all and for good) and start over again. Preferably by integrating a small, extensible, proven and already existing scripting language like...

LUA.

toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005

There's only one way AHK can blossom into a serious scripting language and that is to throw the current syntax away (once and for all and for good) and start over again. Preferably by integrating a small, extensible, proven and already existing scripting language like...

LUA.

If you have LUA, what do you need AHK for?

And why do you think AHK is not already blossom or that it isn't a serious scripting language?
Ciao
toralf
 
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.

thomasl
  • Members
  • 92 posts
  • Last active: Sep 28 2006 09:55 AM
  • Joined: 16 Jun 2005

When I read this topic, it gets to my mind that some "real" programmers would like to have some AHK features but would like to stick with a "real" language/syntax. As a AHK follower I could ask as well, why the other languages don't incorporate these AHK features? Then the "real" programmers would be happy too, right?

You've hit the nail squarely on the head. The reason is that AHK is a strange mixture of two very different beasts: a keyboard/mouse/macro package and this part works exceedingly well. And it's (trying to be) a scripting language. This part was, as it were, grafted onto the rest and it had, for various reasons, to be compatible with other products.

"Real" languages (as you called them) simply don't have the keyboard/mouse/macro features of AHK. And they shouldn't as that's an application feature and not a language feature.

As to classes and inheritance, I agree. C++ is a monster and only proves that you can design a language in such a way that even its creator loses track.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

And some other people (even those from a programming background) like being whipped and spanked... so what exactly are you trying to say?

I was only saying that some people like the current syntax -- possibly even the majority of current users, though probably only a minority of new users who are programmers.

A person's preferred syntax and scripting style seem to be highly personal (based on taste), and thus it's hard to please everyone. Even so, there is a near-term plan to support alternate styles such as one-true-brace (in which the open-brace of a function, loop, or if-statement is allowed to be on the same line as the statement itself).

not-logged-in-daonlyfreez
  • Guests
  • Last active:
  • Joined: --

so i think a great feature would be to use a standard scripting-language like JavaScript to ease the use of AHK


Well, if you happen to know JavaScript, maybe... otherwise, I doubt it...

At work we are a bunch of mech. engineers, with only little programming experience. AHK is so simple to read, that all of us can manipulate the code if it is needed. Only one has to write it first (which is mostly me ). Of cause some code seams to be awkward, but if you know a better or more elegant way, I'm sure it will be incorpoarted into AHK. As for the syntax I do not have a problem with it. Ok, I have to look up the commands as well once in a while, but who doesn't with other languages?


Almost the same situation for me. THE big advantage of AHK...

And some other people (even those from a programming background) like being whipped and spanked... so what exactly are you trying to say? That AHK's syntax is not that bad after all?

There's only one way AHK can blossom into a serious scripting language and that is to throw the current syntax away (once and for all and for good) and start over again. Preferably by integrating a small, extensible, proven and already existing scripting language like...

LUA.


What is it with the syntax that get's you so appalled about it?

You probably long for a VBScriptish/Basicish/Javaish kindof 'mature' syntax? With lot's a dots, parentheses, quotes and other 'essentials'? Did you take a look at AutoIt3? The version 3's 'new and improved syntax' might be more to your liking (and is exactly the main reason why I abandoned AutoIt3 and went to AHK).

I skimmed thru the LUA Manual Pages, but I couldn't find much 'better/clearer/more useable' about the syntax at all. What are the advantages to 'such a language'? Would you like to elaborate on the specifics? How should AHK v2's syntax look like in your opinion then?