Is there any non-100%-interpreted scripting language alternative to AutoHotKey?

[jeeswg]

- @nnnik: I'm still to be convinced other programming languages are necessary/preferable in this case, but I've allowed for the possibility, mentioning C++ above.
- Very often a script in AutoHotkey can be changed from super slow to super fast by using a few tricks. So, if a specific problem is stated, there may already be a solution. E.g. I've found parsing the lines from a 100 MB text file to be fast.
- Does anyone have any genuine examples of problems, where AutoHotkey was actually too slow?

[nnnik]

I stated a problem - AHK is too slow for generating a small 2d realtime game with collisions and then applying a genetic algorythm to it.

[jeeswg]

Gaming is one of the most demanding areas of programming. Anything else? It would definitely make this thread more interesting if we could have multiple concrete examples. Thanks.

[nnnik]

The 2d game in question could have been handled by hardware from 20 years ago.
The game in question cosists of nothing but simple collisions and can be handled by many languages - AHK was not among them.
You claim that simple tricks will make everything work - but when I stated a rather simple problem you immediately take a step back.

The game is just a dot that has to get from the goal area to the target area without touching any obstacles or borders.
The game part is easy to do and it's actually pretty fun to play around with it. Or are you telling me that essentially AHK is not capable of doing this much?

[SOTE]

- @nnnik: I'm still to be convinced other programming languages are necessary/preferable in this case, but I've allowed for the possibility, mentioning C++ above.
- Very often a script in AutoHotkey can be changed from super slow to super fast by using a few tricks. So, if a specific problem is stated, there may already be a solution. E.g. I've found parsing the lines from a 100 MB text file to be fast.
- Does anyone have any genuine examples of problems, where AutoHotkey was actually too slow?

jeeswg, I agree with you. Also, it's not like it has to be one or the other. Use the tool that you feel is most appropriate and that you are comfortable with. That is a calculation that can be quite different for each person. AutoHotkey is a fine utility, automation, and general purpose scripting language, that can be used for various purposes. A person can use both AutoHotkey and Pascal (or Java, or C++, etc...), doesn't have to only be AutoHotkey or only the other language.

The 2d game in question could have been handled by hardware from 20 years ago.
The game in question cosists of nothing but simple collisions and can be handled by many languages - AHK was not among them.
You claim that simple tricks will make everything work - but when I stated a rather simple problem you immediately take a step back.
The game is just a dot that has to get from the goal area to the target area without touching any obstacles or borders.
The game part is easy to do and it's actually pretty fun to play around with it. Or are you telling me that essentially AHK is not capable of doing this much?

nnnik, we know that you are a very knowledgeable programmer. But no person is infallible. Sometimes we overlook things, even the obvious. Sometimes we are just more comfortable with one tool or one way of doing something versus the other. Sometimes a different approach or way of doing something can be done, where one person sees it, but not the other. Maybe there was another way to code the game... Just saying...

I think that various people might be interested in the specific code example or the algorithm used in which AutoHotkey failed, but the other programming language succeeded in. This can be a good teaching moment. We are willing students, eager to learn new points of view. And if nothing else, we can see the strength and weaknesses of various programming languages. Something they all have.

[nnnik]

It's essentially this:
https://github.com/Code-Bullet/WorldsHardestGameAI
But in Java and without the coins or a specific level layout/path points.
I don't have the source code anymore and the latest version is essentially not finished and the code is in a broken state.
i never uploaded to github either but lost motivation playing around with it . Mainly because I have already seen the limits of this specific AI system.
I'd have to create a new game with a new AI system to make the whole thing work but yeah there are more interesting things and more important things to do.
See:
https://code-bullet.github.io/WorldsHardestGameAI/WHG/
https://www.youtube.com/watch?v=Yo2SepcNyw4&t=1s

[User]

SOTE and jeeswg: It seems to me like you are trying to convince people of staying with this language longer than they need it. He says he needs a faster language and that just might be the case.

For the first time, I must agree with you!

@SOTE and @jeeswg, 1 question for you 2: Would you really recommend AHK for heavy "data processing" and "String manipulation" tasks?

I'm really surprise that guys like you 2, with good programming knowledge, is trying to prove that AHK is not a slow language!

Hell, I even once saw "Jonathan Bennett (AutoIt developer)" admitting that AutoIt is a slow language! He gave an example where an "Hex Editor Tool" developed in AutoIt would take 10 minutes to open a 5mb file contrasting with another "Hex Editor tool" written in a "compiled language" that takes 10 seconds only to open a 60mb file!

I myself would never recommend Autohotkey or AutoIt or any other interpreted language for tasks other than Windows OS and Games automation!

[swagfag]

shieeeeeeeeeeeeeeeeeet

quick! better go tell all these data scientists to stop using python then. same goes for webdevs and js

[User]

shieeeeeeeeeeeeeeeeeet

quick! better go tell all these data scientists to stop using python then. same goes for webdevs and js

Hehe, you funny! Lol!

[jeeswg]

- @nnnik: Re. games, I have been considering an attempt at a basic 2D game. Concerns include: redrawing the screen, handling multiple moving / shooting objects, and collisions between non-rectangles.
- In general, games are demanding, maybe AutoHotkey can handle all of this speedily, I haven't tested yet. However, generally the non-game tasks I do: require one thing to be done at a time, don't require multithreading, don't have speed problems.

- @User: I find AutoHotkey great for handling strings. None of the strings I've used have been so big that speed has been a problem. And machine code functions can be created to handle binary data if needed. I have no problem with writing C++ exes to handle strings/data, but I haven't needed to, so I am curious re. any genuine use cases for not using AutoHotkey. (I'm still to hear any other than games.)

[User]

- @User: I find AutoHotkey great for handling strings. None of the strings I've used have been so big that speed has been a problem. And machine code functions can be created to handle binary data if needed. I have no problem with writing C++ exes to handle strings/data, but I haven't needed to, so I am curious re. any genuine use cases for not using AutoHotkey. (I'm still to hear any other than games.)

@jeeswg, you haven't needed to but others already have! (search google)

It is already a common sense that AHK is a slow language, that's why many resorts to machine code, that basically requires writing functions in c\c++!

If people are resorting to machine codes to write fast c\c++ functions to be used in AHK, it's because AHK is a slow language!

If I can't write fast native AHK functions without resorting to c\c++ machine codes, yes, it's because AHK is a slow language!

Yes, AHK alone = slow language, AHK + C\C++ machine code = may be a faster language!

[jeeswg]

- @User: Google what exactly? 'AutoHotkey script definitely cannot be made fast'?
- AHK = fast enough language. Exceptions welcome.
- If people can provide me with good examples, that's interesting. Either I can explore some interesting code or data storage optimisations, explore some machine code, or explore general techniques for parsing or pre-parsing data in C++. But I need *examples*.

[SOTE]

- @User: Google what exactly? 'AutoHotkey script definitely cannot be made fast'?
- AHK = fast enough language. Exceptions welcome.
- If people can provide me with good examples, that's interesting. Either I can explore some interesting code or data storage optimisations, explore some machine code, or explore general techniques for parsing or pre-parsing data in C++. But I need *examples*.

Agree. Without examples, we can't say or see what the situation truly is. We are being given conjecture or feelings, versus cold hard facts.

If you search through the forums, there have been many instances where people have tried or have been using some other language, exe, or dll and thought it would be faster than AutoHotkey. Then it actually turned out it was not faster, or even the AutoHotkey implementation was faster.

Example- https://autohotkey.com/board/topic/66139-ahk-l-calculating-md5sha-checksum-from-file/
([AHK_L] Calculating MD5,SHA checksum from file )

Also, even if you show the other language as being faster. If you are talking fractions of a second or something non-critical, then that can possibly go into "it doesn't make a difference" folder, and the person could just be nitpicking. To include, the program in the other language was faster for just that particular task, but not relevantly faster for many other tasks or even slower on some other tasks. With the differences also possibly being a matter of coding style or algorithm chosen.

[Edited:]

Answer about games given in different post below.

[nnnik]

I already gave an example which neither of you gave a reply to.
Any Application that I use should be fast. When I have to wait for any application I'm always on the verge of uninstalling it.
AHK is slow - anything else you say is false information and a lie.
The techniques you mentioned are essentially avoiding coding in AHK while seemingly coding in AHK.
You 2 are really starting to twist the truth here - it might become a problem so I will discuss this matter with the other staff.

[SOTE]

- @nnnik: Re. games, I have been considering an attempt at a basic 2D game. Concerns include: redrawing the screen, handling multiple moving / shooting objects, and collisions between non-rectangles.
- In general, games are demanding, maybe AutoHotkey can handle all of this speedily, I haven't tested yet. However, generally the non-game tasks I do: require one thing to be done at a time, don't require multithreading, don't have speed problems.

When it comes to gaming, there have been a number of AHK users that have ventured down that path. The impressive thing about this, is that game making was not the original intention of AutoHotkey, yet people have figured out how to make some quite impressive ones.

https://www.autohotkey.com/boards/viewtopic.php?f=19&t=36744
[Game] List of all AHK Games

These AHK users have figured out redrawing screens, moving/shooting objects, and collisions. You have to factor in the context and the background of some of these people to, where they can be non-programmers with no formal training and have learned on their own, using a utility language not specifically designed for the purpose of making games. So the potential of using AutoHotkey for creating games, can be greater than yet explored.

Hellbent/Civborn, who appears to be self-taught, has even come out with a number of videos on how to create games in Autohotkey.
https://youtu.be/tuCVkflQ1ek
(AutoHotkey Game Creation Tutorial 1:)

So then it's not like you can't create games in AutoHotkey, and there are various ways to go about programming it. This would arguably come down more to the individual person and their goals. I can say, that taking a peek at game creation in Object Pascal and some of the code generated there, that the AHK users have appeared to have done well for themselves. AutoHotkey can be fine, for the type of game the individual wants to make, and we need to be specific about any coding issues. And if that issue has more to do with the programmer or style of programming, versus the language.

I already gave an example which neither of you gave a reply to.

It appears you are asking us to evaluate all of the coding in the game, versus showing specific code or copying and pasting some examples on here that was used, where AutoHotkey was deficient. For all we know, the game could have been completely rewritten in AutoHotkey, using a different coding style, to generate a similar look and positive result. It could be possible that you wanted to achieve a specific result or use a specific method, where someone rewriting the game could have gone about the process in a different way.

[nnnik]

No I challenge you to reproduce the genetic algorythm using any coding style and achieve a player count of 2000 after 3 hours of lazy coding without optimizing any bit.
In my opinion you can take as much time as you want though as long as you measure the time and make no optimizations.
AHK is a fast enough language isn't it?

[SOTE]

No I challenge you to reproduce the genetic algorythm using any coding style and achieve a player count of 2000 after 3 hours of lazy coding without optimizing any bit.
In my opinion you can take as much time as you want though as long as you measure the time and make no optimizations.
AHK is a fast enough language isn't it?

Ah, why can't you post the specific code that you believe was superior, right here on the forum? Versus having people hunt it down all over the place, guess, or rewrite the game. I think many of us would like you to teach us and show examples of AutoHotkey's deficiency.

And, I'm not sure what your particular case proves. As mentioned, clearly games can be made with AutoHotkey. So this goes back to what your particular goals are. I'm not against anybody using what they feel is the best tool for the job (you can use both AutoHotkey and another language), but we should arguably be careful in trying to say that everybody else must agree with a particular opinion.

[nnnik]

I already gave you a code with Code Bullets javascript implementation.
The code of my own implementation is currently going through some major restructuring.
Then I dropped it because I got bored of it and had better things to do.
I also didnb't use git or any other backup method - so my code currentrly is unavailable.
As finals are approaching I won't do anything about this.

[nnnik]

If you can do something with the executeables - here there are:
https://github.com/nnnik/Genetic_Dots/tree/releases
AI_1 is the first version
AI_2 is the next version with a different instruction set
AI3 is the current vrsion and doesn't do anything at the moment

[SOTE]

nnnik, you are the teacher, and we are your students. You are the local expert on Java, none of us have ever claimed this. What would be expected is that you post Java and AutoHotkey code side by side (or one example under the other), showing in those code examples on this thread using the forum "code display", where Java is superior and AutoHotkey is deficient. This is a great opportunity to teach others.

I'm also quite interested to see if other programmers think rewriting the game differently is not possible, because AutoHotkey is so deficient and too slow, or that mixing C/C++ machine code functions would just be impossible to have any impact.

For clarification, the counter-argument is that AutoHotkey will be more than "fast enough" and adequate for most purposes. Especially for non-programmers and beginners. Clearly, people have programmed games with AutoHotkey already. https://www.autohotkey.com/boards/viewtopic.php?p=205298#p205298 (ping pong), https://www.autohotkey.com/boards/viewtopic.php?f=6&t=50139 (bulldozer). In special cases or with various individuals that feel AutoHotkey is not enough, they can freely do as they please. I was recommending other programming languages that they can try (like Object Pascal), not trying to stop anybody from using other languages. However and at the end of the day, this is an individual decision, based on the person, situation, and their goals.