AutoHotkey Community

Lately I find that AutoHotKey has gotten more difficult to use. This may of course be because of the growing number of functions, but I fear it is because Chris is becoming too good a programmer.

He is loosing sight of the average user.

A more complex syntax speeds up the programming for the experienced user, keeps the scripts shorter and more efficient. But the debugging of paranthesis, function parameters and datatypes is why I quit C++ years ago, and even AutoIt.

A simpler syntax is slower to write, makes for longer scripts and may be more difficult to read. But the debugging makes all the difference.

Now with functions making its way into AutoHotkey, Chris need to keep a cool head not to break the simplicity of AutoHotkey. Maybe we need a symposium on parameters?

Skrommel

That's a bit light on specifics, so I'd appreciate a few examples of things that have gotten harder. For example, I know that some of the syntax checking had to be sacrificed to open the door for functions and expressions, which makes it harder to find bugs in a script. I hope to address this in a future version with a show-warnings mode that will alert you to common bugs such as misspelled variable names.

If this is true, it would have to be fairly limited because I still keep a pretty rigorous scoring system by which new features are prioritized. To score high, a new feature has to be either very easy & small in code size or has to benefit a large percentage of users.

Another thing I try to keep in mind is that advanced users tend to visit the forum more often, and they also post far more often. Thus, they become a vocal minority of sorts. I don't think this is a bad thing at all; it's just that I try to keep in mind that 80% or more of AutoHotkey users probably never step foot in the forum and instead are casual script writers who just want to automate a few things and/or have a few convenient hotkeys and hotstrings.

I try to downplay complex expressions and functions in the documentation. I'm sure you know that there is no need for anyone to use expressions or functions if they don't want to. So I'm guessing you mean that new features such as DllCall and ListView tend to be functions, and are thus harder to use. However, in these cases the decision to use functions was not made lightly. The costs and benefits were carefully weighed and functions seemed to be more appropriate and usable for these particular features.

Parameters?

Thanks for your comments. I think I don't get enough constructive criticism about the program, so I hope everyone else will feel free to speak their minds if anything strikes them as deficient or they think AutoHotkey is going in the wrong direction.

What I fear most is that AutoHotkey will go through the same changes AutoIt did. From being a learn-as-you-go language it turned into something that involved knowing what include files to add in the header.

And AutoHotkey shows the same signs: From a carved-in-stone syntax with Command,Option,Option there now are several other syntax variants, like If-Else with paranthesis, || and &&. There's SetEnv turned into = and :=, and Gui brought all kinds of variable prefixes.

OK, OK, not everything can be done easily within this rigid framework, and it's amazing after all that the Win32 API is presented so simply in AutoHotKey, but I'd choose longers scripts and more commands over quirky syntax any day. The Gui command could probably be split into several smaller commands.

Now, the latest addition is functions, with local and global variables, parameter passing, multiple return values using structs, and soon exchanging scripts is a thing of the past.

One of these days Chris will run his head into a nifty feature, throw his hands in the air and follow the rest of the genious programmers into bloat heaven.

Skrommel

Can you give an example of how these new features make scripts less portable?

I'm very anti-bloat. One example of this is that I still use Metapad -- which is not far up from Notepad -- for all my script editing.

I agree that these things are somewhat ugly. It was the only way I could think to do it that would retain backward compatibility while allowing expressions such as:

NetPrice := Price * (1 - Discount/100)
(which would require many hard-to-follow steps if done in the old syntax)

Hmm... I don't know, don't the older commands still work? I mean, you can still code the way you used to, right?

Oh, sorry, could anyone tell me about this "multiple return values using structs"? I can't seem to find it in the docs..

No software can be all things to all people. The best we can hope for is keeping backwards compatibility while adding new features. (Adding no new features is not an option: any static system dies. Sooner or later.)

I think when it comes to backwards compatibility Chris has done (and is doing) an excellent job. And nobody is forced to use any of the new features, I think.

However, the writing on the wall is clear: there are users who want more and there are users who want less.

Let's have a stable, mature 1.x and then think about a feature freeze and a possible 2.x whose syntax might be 1) cleaner (and therefore easier) and 2) extensible in a way 1.x will never be.

When the address of a structure is passed to a function, the function is free to change any number of members (fields) within the structure. When the function ends, the script can see these changes in the structure, and so in that sense multiple return values are supported.

But you don't need a structure to get multiple return values. Passing argument types such as Str or IntP via DllCall allows the target function to return more than one value by means of altering the contents of the incoming arguments. Similarly, you can get multiple return values from a script-function via ByRef parameters.

Although this might happen someday, it's a big step and not something I'm ready to commit to yet. For one thing, it would be a lot of work; but more importantly, putting a feature freeze on 1.x would be a big disappointment to a lot of users.

Not to all, obviously

Anyway, what I mean (and there I agree to some extent with skrommel) is that if you continue to add features within the current framework, the thing will become unwieldy. (I think it is unwieldy already: that we have two syntaxes for assignment (to pick an example) is a concession towards backwards compatibilty which I appreciate -- but it's a pain in the neck nevertheless.)

Sure, one can always add just one more little thing, one more feature without breaking the whole... it is so tempting... but we could well end up having a bloated monster on our hands.

This is problem, and I agree that having a v2 would be one possible solution. However, I think there are some other possibilties, such as having a new file extension or a directive at the top of the script that tells the program that equals (=) should always be the same as := and that all IF-statements are expressions (which would avoid the need for parentheses).

Since AutoHotkey is nearing maturity in terms of its missions -- which are automation, hotkeys/hotstrings, and to a lesser extent GUI and remapping -- I don't think the code size will increase nearly as quickly as it has in the past.

I previously posted more detail about plans and possibilities in the following topic: A more philosophical question...

I know... 'cause I started that topic

As to your comment about AHK nearing maturity in terms of its missions -- if this is the case (and I think it may well be) why not have a feature freeze at that point? This is what I meant in the above post.

Whether we need a 2.x or whether we can somehow get 1.x to do the job I don't know (and don't care). What I do know (and where I care) is that the current co-existence of "old" and "new" style elements is confusing and error prone -- more than one debugging session ended with the realisation that I had, once again, forgotten that blasted : in an assignment. (Memories of the good old days when I used to code in Pascal...)

How you call the baby in the end is not really important -- as long as there is a baby in the first place!

I see I'm not worrying alone!

Where AutoHotkey is heading is of course up to Chris, but I feel a bit reassured by what he is saying about standing by the newcomers.

I was a fan of AutoIt up until v3, and Chris probably feels the same, too, since he has chosen to keep developing the v2.

I can live with a code cleanup and consolidation, but a new version should stick to the same formula. We all want more functionality, but keeping it simple is essential: We can't get the job done with a simpler language, and I don't have the time to learn a more complex one!

There's not many languages out there that strike the right balance between funtionality and ease of use - in fact there's only one!

Skrommel

Thanks for your comments. Concerning the difficulty in remembering to use := instead of =, there has been an item on the to-do list ever since := was introduced to have a new directive that would make = be the same as := and make all IF-statements into expressions. The latter is somewhat difficult because although it would avoid the need for parentheses around IF-statements, it would defeat the ability to use "if var is <type>" and "if var in <matchlist>". So I've been deferring that until replacements for these are devised (probably not hard, so it's just a question of the priority of this task relative to others).

One of the huge plusses for me with ahk is the relative lack of punctuation marks compared to other coding languages. My only coding background is a bit BASIC, batch files, HTML, CSS, and Javascript. I even found Javascript to be syntax-unfriendly. I love CSS, but it drives me nuts trying to find the missing parentesis or quotation mark that breaks my creative work.

I understand that the more advanced functionality the script authors want, that the syntax may have to be more complex. That doesn't bother me too much so long as syntax is kept simple for the basics.

I'd like to see the contination of features being added. If some of them are too advanced for me at this point (like DLLCall) that's fine because at least it's there if I can ever figure out how to use it, and it doesn't complicate the relatively simple command set that I'm using to get the job done now.

One of the other plusses of ahk for me is that there are synonyms for some things. A good example being able to usee the words AND, NOT, OR, etc. rather than trying to remember all the symbols. I like to be able to spell things out in a way that makes it clearer in my head when I read the script.

The commands I like the most are those which get straight to the point. UrlDownLoadToFile, for example. The same thing can be done with other commands and macros, but with a lot more typing and potential errors. I'm very error-prone and like to keep things simple and to the point so I don't get confused. Simple commands with simple syntax that eliminates the need for complex workarounds is, imo, a very good thing.

AHK has turned me into a kid in a candy store. AHK has put a screeching halt to all the hours I'd search the 'net in vain for certain software utilities I've always wanted. Clipboard expanders, for example. I never found one that worked quite the way I wanted it to, and AHK allowed me to come up with one that's just what the doctor ordered; nothing more and nothing less. I'm amazed at what I can do with AHK even as a novice, and that's because of the minimal learning curve compared to other coding languages.

_________________
“yields falsehood when preceded by its quotation” yields falsehood when preceded by its quotation.

Great comments. Thanks for your vote of confidence.

In a sense what Dragonscloud says about high level commands that come straight to the point runs counter to what skrommel wrote.

Which only shows that no two users are alike. Instead of trying to strike a balance the best approach may be to have a clever but simple extensibility scheme and build ever more complex stuff on top of that -- in such a way that AHK could actually be said to be written in itself (at least for a very significant part).

(I hasten to add that most users would never need to touch that kind of thing: this level would be the province of Chris and a few other maniacs )