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
thomasl
  • Members
  • 92 posts
  • Last active: Sep 28 2006 09:55 AM
  • Joined: 16 Jun 2005

A person's preferred syntax and scripting style seem to be highly personal (based on taste)

I disagree. I have in my time written programs in 6502 Asm, BASIC, 8086 Asm, Pascal, Modula-2, C, C++ (ugly), Perl (even uglier but oh so powerful), LUA and a few others. I can tell you I don't care very much about syntactic sugar as getting to grips with these things takes a few hours at most if the rest of the language is well designed.

What I do care about is simplicity, orthogonality and consistency.

thus it's hard to please everyone.

That's always hard :) and that's one of AHK's problems. AHK tries to do too much in one go. Packing more and more into it doesn't solve the basic problem. Quite to the contrary.

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

You probably long for a VBScriptish/Basicish/Javaish kindof 'mature' syntax? With lot's a dots, parentheses, quotes and other 'essentials'?

No. That's what I referred to in another post as syntactic sugar. I already wrote what I want in a language in that post.

I skimmed thru the LUA Manual Pages, but I couldn't find much 'better/clearer/more useable' about the syntax at all.

If you can really see nothing "much 'better/clearer/more useable' about the syntax at all" in LUA than in AHK than perhaps you skimmed thru too quickly? Or perhaps you have no clear understanding about what the SYNTAX of a programming languages constitutes, what it's all about?

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

AHK tries to do too much in one go. Packing more and more into it doesn't solve the basic problem.

There's a pretty strict discipline about what features get added. 9 out of 10 proposals in the Wish List forum are either relegated to a low priority or turned down with a response such as "this could be written as includable files/functions rather than built into the program".

This is done so that features that have the highest benefit/cost ratio are given top priority, while also keeping the application small in code size.

By the way, since this topic has a lot of rapid replies today, anyone who has been following it in realtime might want to scroll back a page to see if you missed anything.

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

If you can really see nothing "much 'better/clearer/more useable' about the syntax at all" in LUA than in AHK than perhaps you skimmed thru too quickly? Or perhaps you have no clear understanding about what the SYNTAX of a programming languages constitutes, what it's all about?


I am no programmer, and couldn't find anything that struck me (as a non-programmer) as being efficient, handy or good about the syntax, and yes, maybe I skimmed too quickly.

Would you mind elaborating a bit on your ideas of a better syntax?

toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005
I know what you mean by "simplicity, orthogonality and consistency" when I see the LUA manual. But if you only take the commands provided in the LUA language, the benefit of LUA is only small IMO.
It has some nice features for
- passing of function parameters
- stack/list/table operations

But LUA is missing some of the important AHK commands (might be wrong since I do not know LUA)Win...
Gui...
Control...
Sound...
Mouse...
Send
HotKey
HotString
FileSelect...
SetTimerI ask my question again: Why don't you ask the LUA project to create a library that gives you these AHK features in LUA directly?
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

But LUA is missing some of the important AHK commands (might be wrong since I do not know LUA)

Both you and daonlyfreez are mixing up features provided by runtime libraries with syntax. The foundation of any serious programming language is a simple, extensible, consistent syntax...

...whereas runtime libraries are a different story altogether. These can and will be built over time by the original language designers, its users etc. If AHK had strong extensibility we would now see all sorts of user-written procedures and libraries to do all sorts of things.

I ask my question again: Why don't you ask the LUA project to create a library that gives you these AHK features in LUA directly?

Perhaps because the LUA project is clearly a platform independent endeavour?

Let's just agree to disagree. This leads to nothing.

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

Let's just agree to disagree. This leads to nothing.


Sure we can do that, but it would be constructive to elaborate on your wants and wishes more (that might lead to something)...

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
toralf is right.
I have looked at a lot of programming languages, more or less deeply (from "just took a quick look at some examples" to "deep knowledge and programming with it") and Lua syntax is nice, easy to learn and elegant, yet powerful.

Consistency isn't the strong point of AutoIt 2, thus, alas, of AutoHotkey. I won't bash the syntax, as Chris made a good job of keeping compatibility but carefully adding features making it usable as a programming language, without the awful hacks I saw in AutoIt2. Note that compatibility which was a strong prerequiste and the main reason for the split from AutoIt, so it is highly unikely to split again the code to make a AutoIt3-like syntax...

I started to look if I can do a good SciTE lexer for AHK, but either it will be superficial, or it will be a lot of work, because syntax vary from one command to the next, some words are used only in one parameter position of one command, knowing if you have a string or a variable require to know the command name and the parameter index, etc. This go against the design principle of those lexers, which aim to independence of keywords and lexers, with a few exceptions (like REM in Basic).

Wanting to choose between AutoIt3 and AutoHotkey, I was tempted by AI3 for its "nicer" syntax, but I finally chose AHK for its functionnalities and its dynamism: open source, quick updates, availability of its creator.

Back to toralf, as I said, he is right: Lua is missing stuff like GUI or window operations. Should I have more free time, I would attempt to take the AHK source, remove unneeded stuff like parser or string handling or IO, and call the internals of AHK with the Lua syntax. That would make a powerful Windows scripting language. This is easy with Lua because it is designed to facilitate integration of foreign libraries. But still it would need quite some work.

Note that it wouldn't "replace" the current AHK: obviously a lot of people like the current syntax and wouldn't touch a more classical language with a 10ft pole... It would just extend my favorite language and give me more power with a syntax I am more comfortable with.

Note also that would not "improve" Lua and it would never be officially adopted as it aims at more portability and genericity than being a Windows scripting language. That would be just yet another application of Lua.

One difficulty with such project is to keep in sync with current version of the main program. Having an official DLL exposing the interesting features of AHK would be nice and make the task easier, but Chris isn't interested in the making and has other cats to skin...

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Interesing comments. Others have also proposed that the AHK core functionality be made a separate module for easier integration with other languages. Although it probably won't happen soon (unless someone else does it), I'm starting to like the idea more.

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
If you go back a page, you will see my post about running a LUA script from AHK. With just a handful of AHK commands around, you can write in LUA. It takes less than a second extra time than doing everything, what you can, inside LUA, but if you need GUI, Hotkeys, etc. it is there in the AHK part.

At first, I was also excited about LUA. I modified and recompiled the source, because I need integer arithmetic instead of the standard double precision floating point, and ran a few scripts. After a while I realized, that it is still an interpreted language, that is, slow. Also, I don't have control how tables are handled internally. I want to know if hash tables, priority queues, balanced trees are the right data structures, but for a comparison I have to do low level programming. Then why bother? Use C. The program runs fast, modern compilers are lightning fast, so LUA is (for me) only for prototyping. But prototyping can be done in AHK, too. So I stopped using LUA.

Sure, there are things I would like to be changed or added to AHK, but my needs are so special, they were probably never make to the upper half of Chris' ToDo list. But AHK is damn good the way it is.

Decarlo110
  • Members
  • 303 posts
  • Last active: Feb 12 2006 02:15 AM
  • Joined: 15 Dec 2004
Syntax hardly trumps usefulness.

Of course, one could confer upon it that imaginary degree of importance, but the true measure of a programming language is its usefulness, speed, and level of control offered. As long as a syntax is purposeful and not tedious, it is fine and hardly a point to frown on, for any language. What syntax does do, apart from enable programmers to understand each others' code, is expose people's ability/inability to adapt to necessary arbitrary conventions. Some languages have inefficient, anti-intuitive, unnecessarily verbose jargon/naming conventions. This is not so with AutoHotkey, and that is intentional, and a good thing. Now with syntax, Ahk is intended to be compatible with its predecessor, and that is fine and good. If you wish to abandon compatibility for whatever reason, just keep making a new language from some existing one and add to the plethora already existing. I do not care for such trends. You could also do what MS did, making VC 6,7,8 incompatible. That's perfectly fine if you think that kind of thing is efficient (it is not).

Perhaps what would be best is if syntax itself becomes modular... that would be another breakthrough triumph of AutoHotkey. It requires much code re-design, however.
SetSyntax syntax_filePathName
Modularity and dynamic commands would make AutoHotkey unbeatable. Modularity will eventually occur, as i predicted in AHK after 10 years

Now as for whether AutoHotkey is a "real" programming language... It can be used to program, so the answer is yes. Whether it is a formal or informal language is a rather moot debate. Also the poll question

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

reveals that those who are overly strict with syntax, for some reason relax their language standards when answering a poll question. The answer to the poll question is in the affirmative, since Ahk is already being used as a programming language. This just goes to show that people can themselves be as inconsistent as supposedly some language they are criticizing. Furthermore, consider any human language. Should it be said that it is not a language since it could be used for poetry? or that understanding can still be achieved without capitalization... or that understanding can still be achieved without perfect spelling. This simply demonstrates that consistency standards for syntax, grammar, etc. can be taken to an extreme, and denigrating a language on this one point alone, lacks proper perspective.

EDIT: As Chris has already pointed out, if you don't like the command-style syntax, it can be replaced by using Functions. The barrier in this particular case is inverse to the creativity of the programmer. Functions can be used to reduce many lines of code to just a few, or even one line, apart from the auto-execute settings.
1) The Open Source Definition http://www.opensourc...ition_plain.php

2) Intuitive. Logical. Versatile. Adaptable. <>

JSLover
  • Members
  • 920 posts
  • Last active: Nov 02 2012 09:54 PM
  • Joined: 20 Dec 2004

...(such as the inability to have a space between a function's name and its open-parenthesis)...

...I (personally) see no reason to allow a space there??? I also don't need spaces around = in most cases...

NiceAndNeat(wow)
{
	msgbox, % wow
}
EasyToRead=1
WhyWouldYouWantTo (wow)		; space THERE?
{
	msgbox, % wow
}
SpacesHereTooWhy = 0

Also, I LOVE the lack of a picky language...C requires semi-colons for no reason...JavaScript allows them but don't require them, no language should require any filler chars, the language should be written for ease of use, not all this strict crap...& I don't want AutoHotkey to become picky either. I would like to see more advanced syntax, such as multiple commands on one line, but there is no reason for a language to be strict...like the stupid XHTML with its closing a
tag...
...no! the
tag don't need closed picky b---turds!

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).

...yippie!...the only thing I haven't liked about AHK, the lack of support for that (& other stuff/commands on one line). I really want JavaScript-style if-else support (on the same line)...

AHK...
if thiskindasucks
	that=yup
else that=nope		; nice having else allow this
JS...
if (thiskindasucks) that='yup'; else that='nope'
...support for single quotes (if they don't work?) would be good, but also not requiring quotes in all places is GREAT. On the other hand, requiring line breaks in too many places does suck...
Useful forum links: New content since: Last visitPast weekPast 2 weeks (links will show YOUR posts, not mine)

OMFG, the AutoHotkey forum is IP.board now (yuck!)...I may not be able to continue coming here (& I love AutoHotkey)...I liked phpBB, but not this...ugh...

Note...
I may not reply to any topics (specifically ones I was previously involved in), mostly cuz I can't find the ones I replied to, to continue helping, but also just cuz I can't stand the new forum...phpBB was soo perfect. This is 100% the opposite of "perfect".

I also semi-plan to start my own, phpBB-based AutoHotkey forum (or take over the old one, if he'll let me)
PM me if you're interested in a new phpBB-based forum (I need to know if anyone would use it)
How (or why) did they create the Neil Armstrong memorial site (neilarmstronginfo.com) BEFORE he died?

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

Others have also proposed that the AHK core functionality be made a separate module for easier integration with other languages.

That's by seeing these posts that I wrote you weren't so hot on making this. I remember you wrote to take a look at AutoIt's DLL...
Ideally, either AutoHotkey itself would rely on this DLL for its core functionnalities (not a good idea, I prefer standalone exe), or you refactor your code (if not already done) to cleanly separate these functions in a given set of independant source files, so DLL making is trivial and DLL versions closely follow AHK versions... That's the interest of the process.

...(such as the inability to have a space between a function's name and its open-parenthesis)...

...I (personally) see no reason to allow a space there??? I also don't need spaces around = in most cases...

I agree here, too much flexibility just allow for sloppy coding... :-)
I dislike styles like Foo (bar) or Foo( bar ) or even Foo ( bar ). That's even inconsistent with traditional typographic rules...
OTOH, if "EasyToRead=1" is more or less OK, I find "SpacesHereTooWhy = 0" easier to read... Obviously a question of taste. I also prefer "X = A * (B - 2)" to "X=A*(B-2)", the eye has more space to breath... ;-)

C requires semi-colons for no reason...

I disagree, it allows to write nice obfuscated code... :lol:

...like the stupid XHTML with its closing a
tag...
...

That's inherent to XML, and it is easier to write a parser for XHTML than for HTML (where you have to write a lot of rules like:

ends when meeting

,
    , etc.).
    And you don't need to write XHTML, you can stick to HTML 2.0 after all.

    if thiskindasucks
    that=yup
    else that=nope ; nice having else allow this

    Eurk, I am not sure this would be such an improvement... At least for readability. Except perhaps for the simpliest case.
    Sometime I allow myself to put a "return" instruction on the same line than the if, but most of the time, I even discipline myself to always put braces around even single instructions...

    If you go back a page, you will see my post about running a LUA script from AHK.

    Well, I rather want to run AHK (functions) from Lua, that's a different beast. I already experimented calling Lua from AutoIt2 years ago, it was useful because it hasn't expressions.
    Note that I mention Lua because I like this language, but should I come from a different background, I would have mentionned JavaScript, Ch or Cint (for the C lovers), Rebol or Scheme, etc.

    After a while I realized, that it is still an interpreted language, that is, slow.

    Indeed. Notice that AHK is interpreted too, probably even in self-running exes. In most cases, speed is more than enough, and on the plus side, there is the ease of changing the code: I just tested BBCodeWriter, found a bug, and added three lines to correct it. Just a double click on the main.ahk, and I can already test it.
    Note that Lua is generally seen as being very fast in the interpreted language category.

    Note: some people still ask if AHK is a "real" programming language. I believe it is, and code like the above BBCodeWriter or your Base64 coder/decoder really enforce this view.
    Of course, it may use some advanced features like regular expressions (it doesn't have it, doesn't it?), associative arrays (well, I have seen creative uses of dynamic variable name creation, so it may be possible to emulate), etc. But one can live without them, and the capability to call external programs (or DLLs) and to manipulate the result greatly adds to its flexibility.
    I wouldn't use it for ambitious programs like a database export or a full blown source code editor, but it fits perfectly its main task to ease our life as a macro language (and more), and that's why we love it...


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

WhyWouldYouWantTo (wow) ; space THERE?

Some people have asked for it, perhaps because they feel it improves readability. So as long as it isn't too hard and doesn't hurt runtime performance, it seems best to support it.

I really want JavaScript-style if-else support (on the same line)...
if (thiskindasucks) that='yup'; else that='nope'

Eurk, I am not sure this would be such an improvement... At least for readability.

The difficulty of implementing this seems much harder than one-true-brace. And since its added value seems somewhat low, I'll put it on the list as a lower priority.

support for single quotes [to enclose literal strings]

Although I think that would hurt runtime performance, I'll add it to the list to reconsider later.

Thanks.

Thalon
  • Members
  • 641 posts
  • Last active: Jan 02 2017 12:17 PM
  • Joined: 12 Jul 2005
I am using AHK to develop some (more or less bigger) programs (Automating different programms in one GUI (see also, see also); Quick access to data (at the moment some hundred kB) (see also); Changing Keys and recording Makros; ....) and it works fine :)

It doesn't occure so often that I have to check the systax of a command in AHK-help and I like the short syntax very well :)

I do little programming in C# and Python but I didn't get quick into these, because documentation is big, but the necessary things I do not find ^^

Thalon