62 replies to this topic

[Bigfootmech]

By programming language I mean C++, but thats pretty complex and takes a while to learn and you have to pay and bla bla bla so here's my idea:
I'm kind of a noob, but i see if there is like a guide and like a little tweaking or something maybe you could start being able to make games or programmes with autohotkey, I believe this would skyrocket it because you can do so much already and it's so simple!

[NiJo]

Tell me something.
Who can't program by autohotkey's actual helper that is a good programmer, or even a bad programer? Only completly noobs to coding and/or English language would have problems, and those, sorry, but i don't miss them as programers

I think the only thing that could/can be done was to publicite it more. I don't know how much is Chris interested in that... and that job, is also a job for every programmer. I already told my friends who know at least basics of programming, and guess what?!?! More than half, actually the best ones, use it.

Programmes and games have already been made a lot, and are continuouslly being made using this language. at least by me

A good thing that would come in handy was a better editor than notepad, but those already exist. go check the catalogue of script's

[Thalon]

I know some programmers (where proramming in C++, C#, Java, MFC,.. is there job in real live) which are using AHK for easying up there job and also privat at home!

So they know how to do it in other languages, but they don't because AHK is much better for many things in a normal day!
I am using much scripts at work every day and can't count the starts of ahk-programms

I am using it also for little programms with <10k lines of code, bigger software I didn't program up to now

Thalon

[Chris]

I appreciate the detailed comments and I'm glad to hear AutoHotkey has been useful in your organization.

Thanks.

[NiJo]

Yeah, that's a problem...
Because ahk is so easy, after you keep programming in him for half an year or so, yo forget about other languages "language".
I'm still studying at university. Last year we had C, and than nothing. I use/used ahk for my daily needs. This year I have a basis of C again, and I keep writing "msgbox, " instead of "printf( "
It sucks...

One thing i keep programming in C, rather than in ahk, is when I need big Math-Based programs, With 3D and 4D matrixs and cycles for all the purposes. There, i think C is even more easy than ahk...
Of corse that's almost all that C can do :\ and a little bit quicker too.

daonlyfreez: What do you mean by

But I do think that if there were some more 'programming candy' added to the syntax of AutoHotkey, it could develop into a more 'real' programming language...

What programming candys, for example??
Sorry, but I'm not that expert in programming (yet), but I want to learn

Thanks, developing team, and special Chris

[AHKnow]

Hell yeah, I think AutoHotkey should continue to develop as a programming language.

Why?

1. It has automation and macro recording. This makes AutoHotkey extremely useful and something even newbie programmers can find numerous uses for. Right off the bat, you can start making little programs to make usind Windows easier.

With languages like C/C++, Pascal, Visual Basic, C#, etc... this is not the case. You have to study more and deal with more to make the languages "everyday useful". Often those heavyweight languages are more useful for specific purposes.

2. AutoHotkey has "easier" to learn syntax. Chris and crew has managed to simplify many complex commands/syntax that are very hard to use and learn in other programming languages. Loop, GUI, etc... are examples of easy of use commands.

3. It "easier" to type AutoHotkey in something like notepad. AutoIt for example has all those ( and " stuff that gets redundant. Once you have learned a lot of AutoHotkey's syntax, commands, you could actually just use Notepad in many cases. Of course using a good Editor with all the little extras (like help, autocomplete syntax, etc...) is great too, but its nice to know you can just use plain old Notepad too. With AutoIt, C#, etc... you will definitely need an editor with autocomplete/intellisense type functionality.

4. AutoHotkey's plain outright user friendliness, detailed help, and ease of use makes it a great choice to go into this direction.

With that said I think AutoHotkey needs the following in order to become a "big time" language that it really should become.

1. Plug-in

Eventually, all these additional features will keep making the AutoHotkey.exe bigger. The plug-in system would allow user to choose which additional features he wants to include and thus keep the size down too. Also, user could trade these .dlls/plugins among each other.

2. ActiveX/COM/OLE

I know that I've mentioned this before, but AutoHotkey "the programming language" should create its own flavor of ActiveX/COM/OLE or create syntax to use VBScript and JScript more easily.

Yes, you can use JScript and VBScript now, but it is being supported in a round about way. Specific syntax for it would be nice.

I also would like to but in a special mention for JScript and Javascript. This script language works really well with AutoHotkey and Internet Explorer. Also, JScript/Javascript syntax is user friendly as well.

3. LINUX

FBSL (Free Basic Script Language) has a project to port over to Linux, so why not AutoHotkey at some point in the future?

It would be nice to see a project where AutoHotkey "the language" could be used on Linux.

4. Get rid of EXE2AHK

Ah, I'm not going to really get into it. But a "real" programming language that is being used on a pro level should perhaps not have such a tool. If anything, AutoHotkey should have a tool for additional security or enhanced security.

5. Better support for databases.

If AutoHotkey ever gets a plug-in system or ActiveX/COM/OLE, than among the first things would be commands, syntax, etc.... to support SQLite and MS Access (.MDB).

With the above, AutoHotkey would be even more of a user friendly programming language dream.

[jonny]

I've been refraining from commenting so far, since anything I say would be biased against AutoHotkey's intended audience, but I simply have to say something here:

With AutoIt, C#, etc... you will definitely need an editor with autocomplete/intellisense type functionality.

I don't know much about AutoIt, and even less about C# (or as it's called in Linux, Mono), but regular C, in my opinion, has been very well designed in the sense that it is easy to read if you know how. Yes, of course I use syntax highlighting (not intellisense or autocomplete though, bleh), but I could just as well use a simpler editor or read something scribbled on paper. Anyway, that's my 2¢.

[AHKnow]

By the way, I agree with you about regular C being more readable or arguably easier to understand in comparison to C++ or C#. But then that "line of thought" opens up a whole can of worms too. Furthermore, you have to still give C++ is credit, after all its what is used to create AutoHotkey. Though perhaps the very nature of C++ is why "easier and faster" scripting languages are needed.

I think when people get used to a programming language, than after a while they believe its so easy. Also, I think how much a person likes a programming language can also depend on their personality, tasks being done, etc... Thus there are hundreds of different programming languages and people having different opinions about each one.

It also brings me to why I like AutoHotkey. I think that as a computer language gets more advanced, it should be simplifying tasks, easier to use, and make it easier to create programs.

If a "high level" program language is creating a complex mess than why not just use Assembly?

I also find it funny that many of the modern Assembly languages have many of the same "High Level Syntax" that is associated with C, C++, and other high level languages. A lot of what people like in many "high level languages" is just the re-inventing of the wheel of what can be done in low level languages. Why keep re-inventing the wheel? How about make something new, like a jet plane (so we get there faster or easier)... if you know what I mean....

FASM ( http://radasm.visualassembler.com/ ) is one of many IDEs that work with the Assembly language.

I mean if people want to go "low level" than why not REALLY go there. To me, I expect "high level" programming languages to make life easier and that is something AutoHotkey does.

[Sqauran]

AutoHotkey as a programming language?

Not sure about this one but what I do know is that AutoHotkey is a VERY "Unique" program. People who are really into programming tend to go with C/C++ and Assembly and not AutoHotkey. People who already know a lot about programming tend to go with something that is much easier like AutoHotkey/Python ect... since they already know how to program and they just want to get the work done quick.

Yet you still have those who want things to be original and created by them and not others. Because of this attitude and mindset they dont' really explore programs like AutoHotkey and so they missed out what a great program this is.

AutoHotkey is not a programming language but when I start to code it in Notepad++ with code highlighting it's starting to feel like it. But it's still not a programming language and it's not a bad thing by the way...

Heard of Mathematica? This program was designed for Math analysis and studies/research. That's what it was designed for and it's not a programmng language and a lot of professional researchers have used it.

AutoHotkey on the other hand was designed for... Macro/Scripting and automation tasks. I use it mainly for remapping keys and creating shortcut since a lot of softwares I use have different shortcuts and they don't allow me to set it. Instead of turning AutoHotkey into a programming language, the creator should focus on improving its ability to manipulate the Windows OS since this is what AutoHotKey seems to be Good at. Aside from that the creator should advance its ability to mine and process data.

I've been exploring AutoHotkey lately and the more I learn its syntax and seeing what others can do with it the more I'm using it! Now I'm using it to explore Random numbers and Arrays and to process basic data. Reading/creating text files ect...

So basically, AutoHotKey is a language that understands Windows.

"Hey, if you see a Windows that contains the title "SomeTitle" I want you to close it!

While I'm not here I want you to scan my desktop every 5 minutes to see if any strange box appears... if so I want you to do this."

Line of thoughts like that can be translated into AutoHotKey without a problem and this is what makes it a unique program. It can't compete with any other programs because it's "unique" and it has a purpose.

Knowing that it has a purpose I don't care if it's a programming language or not because I will use it regardless.

[savage]

AHK's not meant to be a general purpose programming language. That was never the point and I doubt chris has any intention of making it that way. AHK is turing-complete and has been so for ages, so technically you could use it to do anything already. The question is whether you want to torture it into doing it.

I really believe that the best option to satisfy those who want to do scripting and programming work in ahk and those who just want to do some quick macros and hotkeys is to seperate the engine from the interface - to make what makes ahk ahk into a library and a minimal language similar to what it used to be. Then you could make bindings for the library to whatever language you want - similar to Autoit3X. There are problems with this approach of course. One is the technical problems of making hotkeys work across language boundaries - though this would be a problem for the binding authors - not for chris, and another is the blurry area between "simple" and "serious" programming. By seperating the two domains you could alienate some users. IIRC chris is considering this for a possible AHK 2.0 but since that's not going to be any time soon I'm implementing some things that address my needs.

OTOH, fundamental improvements that ahk could really do with include the following:

- a proper extension library interface - mentioned above as "plugins"
- proper dynamic compilation/execution - this I think is the most important one, more later on this
- different semantics for arrays - something like dotted arrays in rexx - this would allow for the simplicity of ahk's current arrays while allowing for fairly simple implementations of higher-order data structures - lists and dictionaries and the like
- heh.. a bit of a stretch here but.. tail recursion


Why are these important? Because combined they allow for massive extension of the ahk language into more general (or more specific) areas without actually having to bug chris for new features or adding to the current mash of syntax. Let's see why -

1. the library interface would allow others to add features often requested - odbc/activex/ole/etc. This is currently possible with the dll interface and ahk wrappers. I'm thinking of a native interface like this

#using odbc.dll
odbc_connect()

If you're worried about still having standalone binaries I believe it's possible to pack dlls into an exe's resources.
2. Here's the biggy - with dynamic compilation you would be able to preprocess a file and then #include it on the line after. This is currently not possible because #includes are done statically after a file is loaded. Being able to preprocess and include a file without needing a wrapper script means that you can easily create domain specific languages for common ahk tasks. One such task for me is creating keychains ie hitting #x then p to do something. My parser is currently written in ruby and has to be run seperately. Combined with tail recursion this would allow you to easily create a custom ahk dialect with custom looping constructs, special syntax, better data structures, etc, while still producing portable ahk code.
Actually just making #includes happen when they are encountered during execution would make some of this a lot easier.

Of these I think the library interface is the most immediately applicable and probably not a huge stretch to implement (of course I'm not all that familiar with ahk's internals). Next I think would be the array thing. It might be possible now just using variable names but a defined syntax would be nice. Dynamic compilation I gather would be very difficult to do given ahk's current state. And the tail recursion thing is a throwaway we don't need to turn ahk into scheme or something.

Phew. Long winded diatribe terminates now.

[Chris]

- different semantics for arrays - something like dotted arrays in rexx - this would allow for the simplicity of ahk's current arrays while allowing for fairly simple implementations of higher-order data structures - lists and dictionaries and the like

True arrays are tentatively planned, though I was aiming to make them a simple collection of numbers/strings. Something more extensible such as what you describe is outside my experience from a syntax and capabilities point of view. Therefore, more info about advanced arrays would be welcome if anyone thinks that the benefits would be worth the costs in terms of development time, code size, and documentation complexity (for the typical user).

- a proper extension library interface - mentioned above as "plugins"

#using odbc.dll
odbc_connect()

I can see that this would be useful, but the reason it's a low priority is a lack of participation. Since most users of AutoHotkey aren't programmers, it might be months or years before the first plugin is even written. Thus, creating the plugin architecture wouldn't have added much value, especially since many such plugins could be written with DllCall without a signficant loss of performance. For example:

#include odbc.ahk
odbc_connect()

2. Here's the biggy - with dynamic compilation you would be able to preprocess a file and then #include it on the line after.

The ability to dynamically build and execute commands and expressions has been on the to-do list for ages. The problem is that AHK is written to be a semi-compiled language, which means that much of the interpreting is done the moment the script is launched. This allows the runtime performance of a script -- especially loops with thousands of interestions --to really fly because each line has already been pre-interpreted.

Thanks for sharing your ideas, which help shape the future of AutoHotkey.