 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
thomasl
Joined: 16 Jun 2005
Posts: 92
|
 Posted: Tue Jun 28, 2005 2:09 pm Post subject: A more philosophical question... |
 |
|
if you don't mind.
Clearly AHK has grown organically from being a limited utility to a very complex and powerful program. With hindsight (the dreaded hindsight once again  ) a lot of things could (and would) have been done differently, I think.
One could change things, sure, but there is always the millstone of backwards compatibilty around our necks. (I hate broken scripts as much as anyone.)
Would it be feasible, sensible to think about a version 2 (or 3) that would not need to be backwards compatible? I am talking about the long term here, not something to be done in the next few weeks or months.
One could always provide a script or a utility to get old, pre-2.x scripts into the newer format. Some thngs will require manual changes, of course, but in the long run it might be worth it. Or not, I don't know.
Just curious what other users think.  |
|
| Back to top |
|
 |
daonlyfreez
Joined: 16 Mar 2005
Posts: 744
Location: Berlin
|
| Posted: Tue Jun 28, 2005 3:35 pm Post subject: |
|
|
Good question.
I feel AutoHotkey should keep developing into the powerful complete-control language that it already is - that can be used by programming/advanced scripting used people, with a sort of extended SmartGUI Rapid IDE, for novices/quick building.
I think the issue raised certainly askes for an IDE, for the language is already getting to complex for new users.
I've been dreaming of a sort of rip-off of the RealBasic IDE GUI, where one can drag and drop GUI-items, a properties window and a handles/actions window.
Ideally, the IDE should have a natural language syntax on top, and a mixture of GUI elements for easy insertion
More important/essential: a database of working and verified script-snippets that lie behind the extra layer of syntax.
On top, also very important, a 'questionaire', which should ask you what you want to create, then would search the database to see if snippets exist, do suggestions, etcet. The outcome should then be added to the database to make it more 'intelligent'.
Natural language...
Example:
| Code: | ScriptName = Auto-Syntax-Tidy v6
; 2005-06-09
; OS=WinXP, AHK=1.0.35.07, Authors=toralf & hajos
;
; What it does:
; It takes a AHK script and changes the indentation and case of commands according to syntax. |
Now, all I'm interested in - as a newbie - is this portion...
The code that is used to accomplish this, not really yet...
So, the questions of the IDE would be something like:
Write in one sentence what your project should do, write as many valid variation sentences as you can think of:
- Change the indentation and case of commands according to syntax.
- Replace words in document 1 with equals in document 2 and transform tabs and spaces according to rules.
- Clean it up.
Select the steps your project should take. Pick from these words that fit your project's step the most:
trigger, activate, select, choose, open
parse, manipulate, change, edit
control...
1 - Open file 1...
etcet.
If the database is loaded, one could 'force' the user by autocomplete or dropdown selection, to use specific words/wording/sentences.
New and updated snippets created should constantly be added to the database. With an 'intelligent' search, these 'natural language' lines of code can then be transformed in a quick useable script...
I see myself facing 'problems' and challenges all day when working with computers, we all do I guess, and it is just plain waste to have all them efforts of all them people just not used, or recreated all the time.
(Drifting away now): Create a database of scriptsnippets for AppleScript and an equivalent for *nix (I only know a bit of linux) ready to compile/use on Mac 7.x-9x, Mac X.x, and 'All' *nix flavors...
(Floating): "Told the darn thing to make me a program to have my codes cleaned up. Switching to 'Create for OS' setting to do the same for my Mac, and I'll make a copy for James on Debian/KDE"... 
Now this brings me to the original question about backward compatibility. A standardised IDE would allow just that, with the different versions of the compilers for the different script-types, depending on what to use it for.
If the user only wants a simple messagebox kind of thing, the IDE should compile it (if compilation is needed) with AutoIt 2x, for it produces smaller executables.
If the user wants more complex operations, or a GUI: AutoHotkey.
Backwards compatibility of newer versions of AutoHotkey with AutoHotkey 1x and AutoIt 2x would be preferable, but not necessary with the scetched scenario.
What worries me more: I see - inevitably? - the executable of AutoHotkey growing, which brings me to:
- Why not have a basic executable (with intern functions only) for AutoHotkey, and 'extras', like the GUI portions, file handling, registry handling etcet. in small 'add-ons'? I understand that a dll is actually an exe with a different 'header', so, would it be too difficult to have something like:
The compiler 'scrapes together' the portions that are needed, which are: The basic executable and tiny dlls for the extras, maybe third-party dlls, images, text files etcet., then converts them into a single executable which extracts these portions on runtime to use them (possibly cleans up afterwards, if extracted in temporary folder for example), an extended FileInstall...
This way, one could run a script on a machine with AutoHotkey installed without all the AutoHotkey dlls in the script's folder, since they are already included in the main install.
On compilation however, this would have the benefit of creating executables that only have code they need, so they can be way smaller.
If one would be able to convert a script also to a dll one could make a 'user' folder in the AutoHotkey install, with dlls in it that behave as a plugin (only FileInstalled on compilation)
_________________
(sorry, homesite offline atm) |
|
| Back to top |
|
|
thomasl
Joined: 16 Jun 2005
Posts: 92
|
| Posted: Tue Jun 28, 2005 5:27 pm Post subject: |
|
|
| daonlyfreez wrote: | | I see - inevitably? - the executable of AutoHotkey growing |
Yes, that would be one important point that in a redesign could be done differently and better: the extensibility of AHK with plugins, for want of a better word.
Ideally, one would have a very small core language (only the flow-of-control stuff, variables, functions etc.) plus a clever extension mechanism. Coding this baby core would not be too difficult, but designing the extensibility would be. But if done correctly this would open up all sorts of intriguing possibilities. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Wed Jun 29, 2005 12:59 am Post subject: |
|
|
These are some nice ideas for the long term. Certainly I'll try to keep them in mind, as should anyone else who has an interest in contributing to the design and coding of a v2.0 project.
I should say that there are no concrete plans for a v2.0. Even if work were to start on it within the next few months -- which is doubtful unless another primary developer joins the project -- I suspect it would be at least a year before release.
Concerning the plugins concept: I think it is a good idea. There are some other posts that talk about it, and it might happen someday. The main reasons there are no immediate plans for it are that:
1) AutoHotkey is finally nearing maturity in terms of its missions (automation, hotkeys, hotstrings, and GUI). Because of this, the EXE size will probably not grow as quickly as it has in the past. This will be especially true once a standard includes library becomes available, which will allow common functions to be outsourced to #Include files that contain functions, DllCalls, etc.
2) The plugins concept would make it harder to generate self-contained, compiled scripts. Either you would have to bring DLLs with them, or they would have to get merged into the compiled script's EXE somehow.
3) There is a certain light-weight feeling to know that all you need to run any script is AutoHotkey.exe. No installation or extra DLLs need be present.
Thanks for sharing your visions for the future.
Last edited by Chris on Wed Jun 29, 2005 2:18 pm; edited 1 time in total |
|
| Back to top |
|
|
thomasl
Joined: 16 Jun 2005
Posts: 92
|
| Posted: Wed Jun 29, 2005 12:28 pm Post subject: |
|
|
Yeah I wrote that this is going to be a long term post
| Chris wrote: | | 1) AutoHotkey is finally nearing maturity in terms of its missions (automation, hotkeys, hotstrings, and GUI). Because of this, the EXE size will probably not grow as quickly as it has in the past. |
Perhaps there comes a point when AHK 1.x is stable, has all required features (he, he) and everybody is happy with it. Perhaps then one could do a feature freeze and only do bug hunting. And start on thinking about a 2.x that should be as backwards compatible as possible -- but that would never scrap a good idea because it might break an exisiting script. For that we have a stable, feature-rich 1.x.
| Chris wrote: | | 2) The plugins concept would make it harder to generate self-contained, compiled scripts. Either you would have to bring DLLs with them, or they would have to get merged into the compiled scrip't EXE somehow. |
True. A classical case of you can't eat your pud and have it. But I for one would like plugins because then I could do things like RegExes. Other people may feel differently, so any extension mechanism should be completely transparent.
| Chris wrote: | | 3) There is a certain light-weight feeling to know that all you need to run any script is AutoHotkey.exe. No installation or extra DLLs need be present. |
Depending on how the extension mechanism is done in practice, it may be possible to eat your pud and have it . I am thinking along the lines of having a fast, small core language that can be extended by additional libraries. These would be written in the language itself and pre-compiled and then could be "linked" with the core into one EXE. But this begins to get too involved. My main goal was to find out whether I am the only one who thinks that AHK is a great automation tool that could evolve into a fully fledged development system. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Wed Jun 29, 2005 2:35 pm Post subject: |
|
|
| thomasl wrote: | | Perhaps then one could do a feature freeze and only do bug hunting. And start on thinking about a 2.x that should be as backwards compatible as possible -- but that would never scrap a good idea because it might break an exisiting script. |
It's a good idea because it might be less painful in the long run to switch to a v2 sooner rather than continuing to build more features onto the existing base. However, the existing base could be made more friendly by putting into effect a new mode (by having a new file extension or directive). For example, the #Complex directive could disable all old-style IF statements, making them all expressions. It could also make the equals operator (=) do the same thing as expression-assign (:=). Finally, it could turn on new warnings that show error dialogs whenever a variable is used without having been initialized, whenever a variable is assigned a value but that variable is never used, etc. This would make it much easier to find script bugs during development. All of this would be possible without having a separate v2 product (v2 would have high costs in terms of upgrading, distribution, development, etc).
It might help to brainstorm a list of all major deficiencies in the AutoHotkey core syntax and give each a score based on perceived value. It would then be easy to draw a cutoff line somewhere in the list, above which all changes would be put into effect in any .ah2 script or a script containing some new directive that alters behavior.
| Quote: | | I for one would like plugins because then I could do things like RegExes. |
Although the performance would not be as good, I think you could write a RegEx function for inclusion via #Include. The function might support only the basics of RegEx, such as asterisk, dot, and maybe a few other symbols (which probably comprise 80% of RegEx usage by a typical user). Such a RegEx function could eventually be made a standard file to be distributed with the program, includable via: #include <RegEx.ahk>. Alternatively, to get better performance the RegEx functions could be put into a DLL callable via DllCall (perhaps there is such a DLL already out there).
Overall, this is a good discussion because not only does it contain many insightful ideas, it's at a high enough level to be useful at this early stage of planning.
I'd welcome more comments from anyone who has an interest the long-term direction of AutoHotkey.
Last edited by Chris on Wed Jun 29, 2005 3:37 pm; edited 1 time in total |
|
| Back to top |
|
|
toralf
Joined: 31 Jan 2005
Posts: 3842
Location: Bremen, Germany
|
| Posted: Wed Jun 29, 2005 2:52 pm Post subject: |
|
|
| Chris wrote: | | For example, the #Complex directive could disable all old-style IF statements, making them all expressions. I could also make the equals operator (=) do the same thing as expression-assign (:=). |
Does there exist an expression for:
If var contains xxx,yyy
If var in xxx,yyy
If not, I woundn't want the old IF statements to be turned off.
But I agree, that old things should be deleted, e.g. GoTo.
Also some commands could be cleaned up, standardized and homogenized. So that the language would look more as one.
But then everything would change and we all would need to learn this new language.
But since new features tend to be functions then normal commands, there is a break already.
_________________
Ciao
toralf  |
|
| Back to top |
|
|
thomasl
Joined: 16 Jun 2005
Posts: 92
|
| Posted: Wed Jun 29, 2005 3:46 pm Post subject: |
|
|
| Chris wrote: | | Although the performance would not be as good, I think you could write a RegEx function for inclusion via #Include. |
The RegEx stuff was just an example, off the top of my head. There are many other plugin-able things
| Quote: | | The function might support only the basics of RegEx, such as asterisk, dot, and maybe a few other symbols (which probably comprise 80% of RegEx usage by a typical user). |
I am probably untypical.
| Quote: | | Alternatively, to get better performance the RegEx functions could be put into a DLL callable via DllCall (perhaps there is such a DLL already out there). |
That's the route to go. There are a few RegEx packages around; I'll check them out.
As to the rest, I will come back to you with a proposal or at least some more concrete ideas once I see a bit clearer how the AHK syntax is structured. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Wed Jun 29, 2005 3:52 pm Post subject: |
|
|
| toralf wrote: | Does there exist an expression for:
If var contains xxx,yyy
If var in xxx,yyy |
Not yet, so they should probably be made available before adding this new mode. I'm not saying the mode will be added anytime soon -- it depends on interest.
| Quote: | | But I agree, that old things should be deleted, e.g. GoTo. |
Goto has its uses, even in a modern language. One of them is performance: I've seen some some functions that achieve remarkable acceleration with the aid of Goto. One of them is GNU C's strcasestr() [case insensitive substring search], which AutoHotkey now uses internally.
This may be an unpopular view, and perhaps a matter its just a matter of taste. But I think banishing Goto from all modern languages would be pedantic.
| Quote: | But then everything would change and we all would need to learn this new language.
But since new features tend to be functions then normal commands, there is a break already. |
Good points. |
|
| Back to top |
|
|
daonlyfreez
Joined: 16 Mar 2005
Posts: 744
Location: Berlin
|
| Posted: Wed Jun 29, 2005 3:59 pm Post subject: |
|
|
| Quote: | | AutoHotkey is finally nearing maturity in terms of its missions (automation, hotkeys, hotstrings, and GUI). Because of this, the EXE size will probably not grow as quickly as it has in the past. This will be especially true once a standard includes library becomes available, which will allow common functions to be outsourced to #Include files that contain functions, DllCalls, etc. |
You state that AutoHotkey' mission is to provide automation, hotkeys, hotstrings and GUI and that it is reaching it's maturity. I agree mostly, however, one could discuss about at what point it is 'done'.
Example:
There are different levels of 'complexity' in scripting with AutoHotkey already:
1 - the old AutoIt 2x syntax (compatible with AutoIt 2.x)
- one line, comma delimited, goto/gosub, simple loops, basic GUI
2 - the old AutoIt 2.x syntax + added syntax, the same style (but not compatible with AutoIt 2.x).
- hotkeys, hotstrings, more or enhanced commands, elaborate GUI
3 - the 'typical' newer syntax, like the extended if-loops
- curly-braces, complex expressions
4 - the function syntax and it's extention to new syntaxes for built in commands
- functions(), and complex GUI elements
...
5 - ?
Do we need many more? Isn't it already too much? Many additions are simplifying and improving the scripting - which is good - like: functions instead of gosub/goto, but case instead of if/else? What's the advantage, apart from readability? Isn't this 'wasted' resources? I don't know how much it adds to the codebase, but... These are things to consider, I feel. Other additions are already for very specific purposes, like dllcall, postmessage. Does really everybody need it? I do think it's worth thinking about what is essential, and what is not.
I've seen too many good programming/scripting languages/projects develop into a monstrum, unhandable and with so many functionalities and possibilities that the cure is worse then the disease.
I would hate to see AutoHotkey develop in a same sort of direction too.
| Quote: | | once a standard includes library becomes available, which will allow common functions to be outsourced to #Include files that contain functions, DllCalls, etc. |
This is good, and it will allow the 'minimalization' of the final executable. This is one of the levels that is already in existance though.
1 - a simple script
2 - a script that has repetitions in it, loops/gosubs
3 - a script that uses functions for it's repetitions
4 - a script that also uses includes for it's code
As early as in case 2, one could think about 'outsourcing', but includes alone is not wholly satisfactory, for, because the includes contain 'much used resources', however, when compiling, the whole concept of 'sharing' dissapears, for the include is hardcoded into the executable.
If there were a possibility to add a next level, compiling into several small executables/dlls, their contained code could be reused, even after compiling.
Let's say I create a script that I would like to share. I compile it into a stand-alone executable, without specific dependencies, that should run on a 'blank' computer.
All files I need are in the executable, ready to extract when needed. On first run the script check for existance of the AutoHotkey basic executable and 'add-on' files in the AutoHotkey folder. Older versions can be overwritten, new files added. If they are 'digitally signed', as an 'official' add-in, this is sort of an 'auto-update'.
If multiple 'programs' are to be included in the executable, they can already share their shared resources that are included.  (Do I really understand what I just wrote? )
No, this way it's guaranteed the script will run, and the add-ons can be efficiently reused.
Say I'm on Windows 9x on a very old computer, and no internet connection, only a floppydrive.
Someone could give me an AutoHotkey installation file, but, does it still fit on a floppy? One might think this is outdated, but I still think good software never exceeds the size of a normal 1.44 floppy, and should be directly runnable from it, if needed.
How often do I need them new AutoHotkey installation files, with all them updates all the time? What if the friend sends me an application with newer add-ons in it. I have a new application, and some add-ins might get updated, maybe it's even the latest version of the executable, so the 'main' executable can be updated.
Catch my drift?
| Quote: | | There is a certain light-weight feeling to know that all you need to run any script is AutoHotkey.exe. No installation or extra DLLs need be present. |
Absolutely, and this should definitely stay possible, and it would, with 'in the compilation included add-ons' like I tried to explain. To develop, one would need the 'whole' AutoHotkey package, including the add-ons, to run however, only the executable with included needed add-ons, nothing more.
| Quote: | | However, the existing base could be made more friendly by putting into effect a new mode (by having a new file extension or directive). For example, the #Complex directive could disable all old-style IF statements, making them all expressions. I could also make the equals operator (=) do the same thing as expression-assign (:=). Finally, it could turn on new warnings that show error dialogs whenever a variable is used without having been initialized, whenever a variable is assigned a value but that variable is never used, etc. This would make it much easier to find script bugs during development. |
Shouldn't that be called #Debug?
| Quote: | I for one would like plugins because then I could do things like RegExes.
Although the performance would not be as good, I think you could write a RegEx function for inclusion via #Include. The function might support only the basics of RegEx, such as asterisk, dot, and maybe a few other symbols (which probably comprise 80% of RegEx usage by a typical user). Such a RegEx function could eventually be made a standard file to be distributed with the program, includable via: #include <RegEx.ahk>. Alternatively, to get better performance the RegEx functions could be put into a DLL callable via DllCall (perhaps there is such a DLL already out there) |
What if the created RegEx function (or any function) could also be compiled to a DLL by AutoHotkey? That would be the next step...
'New' levels:
1 - script
2 - script with function library
3 - script with function library as include
4 - add-on (dll compiled from include or script with function library, or third-party dll)
5 - executable (exe compiled from script with included resources, if necessary)
_________________
(sorry, homesite offline atm) |
|
| Back to top |
|
|
thomasl
Joined: 16 Jun 2005
Posts: 92
|
| Posted: Wed Jun 29, 2005 4:34 pm Post subject: |
|
|
| Quote: | | There are different levels of 'complexity' in scripting with AutoHotkey already |
Exactly. It is this multitude that prompted my original post. There is a feature in programming languages called orthogonality and AHK is about 1000 lightyears away from being orthogonal. It can't be otherwise because it grew over time and we all know how these things go.
| Quote: | | case instead of if/else? What's the advantage, apart from readability? |
I get your point but if you take this argument to its logical extreme, we would need only two things in a language: if and goto. All the rest is syntactic sugar. One has to strike a balance here and case/switch is something I personally would like to have. And let's face it: what makes the AHK EXE big is not the support code needed for a case/switch statement. These language features do not need a lot of additional code. In fact one could probably build a simple pre-parser that converts case/switch into if/else etc. in less than 25 lines of C.
One could take this pre-parsing idea a big step further: in order to deal with syntactic sugar requests let AHK 2.x have a simple text replacement facility (what they call macros in C, or something similar to the old M4). If done correctly one could write a simple set of macros that accepts case/switch statements and produces if/else statements. The language core stays clean and simple (and efficient); however, people who need a case/switch can have it. There is more to all that than simple macros, of course.
Conclusion: I fully agree with you -- the core should be strictly orthogonal and as small and clean as possible. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Thu Jun 30, 2005 2:03 am Post subject: |
|
|
The goals of having pure syntax a minimally sized core are good ones. Certainly they should be kept in mind if there is ever a v2.0 that completely abandons backward compatibility.
| daonlyfreez wrote: | | ...but case instead of if/else? What's the advantage, apart from readability? Isn't this 'wasted' resources? |
I was of the same mind when the idea was first proposed. I thought "what's so much better about that than using an "else if" ladder?" But since then, I've come around to the point-of-view of others: it's a worthwhile improvement, not only in readability but also in improving the maintainability of code (less repeated variable names and thus fewer opportunities for bugs) as well as performance and efficiency (at least in some cases).
| Quote: | | I've seen too many good programming/scripting languages/projects develop into a monstrum, unhandable and with so many functionalities and possibilities that the cure is worse then the disease. |
I definitely agree with this view. I want keep the program as light-weight and accessible-to-novices as possible. New features are generally added only if they score highly in: 1) Being of high value to a large percentage of users; 2) Being small in code size; 3) Providing new functionality for which there is currently no easy work-around or alternative.
| Quote: | | If there were a possibility to add a next level, compiling into several small executables/dlls, their contained code could be reused, even after compiling. |
That's interesting, but might be too involved and rarely used to justify a new framework.
| Quote: | | What if the friend sends me an application with newer add-ons in it ... maybe it's even the latest version of the executable, so the 'main' executable can be updated. |
Interesting, but an automatic update might be undesirable for some users. I think this is getting into the fringe a little too far because it doesn't seem to happen often enough in the real world to justify a built-in auto-update, component-checking framework.
| Quote: | | What if the created RegEx function (or any function) could also be compiled to a DLL by AutoHotkey? |
Maybe someday, but it's currently beyond my current skill level.
Thanks for sharing your imaginative ideas. By pushing the envelope, you help us all see more clearly what's truly important for the typical script author. |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2391
|
| Posted: Thu Jun 30, 2005 4:31 am Post subject: |
|
|
| daonlyfreez wrote: | | Do we need many more? Isn't it already too much? |
Too much ?? If your toolbox starts getting full would you throw away a few tools? I'd go out and buy a bigger toolbox...
| daonlyfreez wrote: | | I've seen too many good programming/scripting languages/projects develop into a monstrum, unhandable and with so many functionalities and possibilities that the cure is worse then the disease. |
I think it depends how features are implemented and documenmted. I don't see this happening to AutoHotkey. One of the best things AutoHotkey has going for it IMO is ease of use while offering a wide variety of powerful features.
| daonlyfreez wrote: | | Other additions are already for very specific purposes, like dllcall, postmessage. |
Actually, dllcall is very generic and will likely end up preventing adding a lot of unnecessary code to AutoHotkey to support various user requests. |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2391
|
| Posted: Thu Jun 30, 2005 4:45 am Post subject: |
|
|
| thomasl wrote: | | My main goal was to find out whether I am the only one who thinks that AHK is a great automation tool that could evolve into a fully fledged development system. |
You're not the only one |
|
| Back to top |
|
|
thomasl
Joined: 16 Jun 2005
Posts: 92
|
| Posted: Thu Jul 28, 2005 2:25 pm Post subject: |
|
|
For those who like these things (ie the syntax of scripting and programming languages) here's an interesting link:
http://www.geocities.com/tablizer/langopts.htm
A bit longish but has some good ideas. |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
