AutoHotkey Community

Not really, perhaps I was playing too much devil's advocate... I am not fond of AHK' syntax, a bit rigid, with ambiguities and thorn between old AutoIt 2 syntax and requirements for something more modern and flexible.
Chris is doing a great job improving it by steps, trying to keep a balance.
I believe he choose to keep this syntax, for compability (perhaps a lesser requirement now) and by taste. And I recall a topic where several people expressed their likeness for this simple syntax: no quotes around strings, no line terminator other than newline, no parenthesis around arguments of commands.
That's this choice that I defend, partly against my own taste...
That, and the specificity of the language: if we implement all suggestions, we will get a bastard language, without personality, running behind AutoIt 3, trying to mimic C, JavaScript, PHP or whatever come to mind...
And the parser will grow, the program too, the bugs will come, etc.
But perhaps I am too pessimistic...
I trust Chris to maintain a vision of the language, to maintain a balance between pleasing programmers and newbies seduced by the simplicity of the language: somehow, the rigidity of the language is reassuring, having choice is confusing.
In a sense, should Chris has chosen to be even more rigid, like requiring braces after a Loop or a If, even for a single line, we wouldn't see errors like omitting the braces and expecting several lines to be in the loop...
Again, I am thorn between my taste and the respect of the choices of the design of the language.
Somehow, it meets my preferences: I avoid to put several instructions per line, unless they are short constant assigments. I avoid to put an instruction on the same line as the If, unless it is a simple Return. And so on.
Note it is difficult to make a perfect language for newbies, even more if they have notions of programming.
We often see creative syntax, wondering why it doesn't work:
a = b + c ; classical...
a = %b% + %c%
s := "b" * 12 ; Legal in Perl!
and so on.

What do you think Chris? Should AutoHotkey language evolve to become Basic-like or C-like on the long run? Should it remain mostly the way it is, with a bit more flexibility?
Another solution might be what was suggested elsewhere: to separate cleany the language itself from the functionnalities (like WinWait), allowing other languages to call AutoHotkey's functions and commands if put in a DLL.

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

...Basic & Pascal aren't languages...they're crap...JavaScript & C (with all it's annoyances) are languages...Java (no Script) is NOT a language, it's crap...I still don't know "what C++ is" yet...some people like it, some people say "pure C" is better...I haven't figured it out yet...AHK should adopt all the good things JavaScript has to offer...when I was trying to code in C...I kept wanting a JavaScript-C language...cuz I still can't create a (string) variable in C...in JavaScript it's simple...


...but in C if you try to create (string) vars in certain ways, the program crashes...confusing...in any case now I want an AHK-JS language...


...NO!...forget that...Basic isn't a language...it's a POS language you write in when you don't know other languages...yes I did code in it when I was like 5 (or whatever) but now that I see real languages...I don't "like" Basic...


...in what way?...requiring line terminators?...NO!...


...exactly...like it is, but remove the old dumb commands, like IfEqual...adding the ability of putting commands on the same line as if, since that aspect of the old commands is the only good thing about them...I like being able to put some things on the same line as an if...


...I'm not against the idea, but WHY...AHK is just a wrapper on the Windows API...which is a wrapper on ASM...which is a wrapper on (or is?) Machine language...how many wrappers do you need?...why wouldn't New Language X just write their functions on Windows API instead of AHK API?...cuz Chris did all the work to sort out the Windows API?...ok...then Chris should work on an AHK OS & replace Microsoft's Confusing API...

_________________
AutoHotkey-Hotstring.ahk - Helping the world spell "AutoHotkey" correctly! (btw, it's a lowercase k!)

I always appreciate your measured and subtle opinions, well expressed and solidly argued...
I believe majkinetor will appreciate your view on Pascal...

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Although there are clearly C influences on the style and syntax, it's not my intent that the language be C-like in terms of difficulty (such as string manipulation). Originally, I had no intention of making AutoHotkey into a complete language per se; but due to demand, it has gotten quite close to that. So now, we might as well take it all the way and give it true arrays other often-requested features.

However, I think one of the highest priorities right now is to work on v2 so that the burden of backward compatibility can finally be lifted. In the short run, v2 will be a nuisance due to the requirement to learn the changes and convert scripts. But in the long run, it should pay off with easier scripting, fewer script bugs, and simpler documentation.

I'm not too interested in that right now because the number of users who would benefit seems quite low compared to the development time involved. I think the limited time I have available should be spent on things that matter the most to current users -- at least until other developers join the staff.

Thanks.

I agree with .AHK Dont modify this i like it how it is

wow did i spark a debate ... May I add even if you allow people to use "" and () and {} in different ways... at least write the manual to try to stick to one coding style and maybe put 1 section about what different styles of coding are allowed with AHK?

I guess the biggest problem I had starting out AHK is that the manual is inconsistant (for a newbie)...

Thanks for the comments.

I agree with almost all sugested things. I don't agree about PhilHos "bastard" language as if some change makes me program easier, I don't care where it came from.


And JsLover, saying that Pascal is crap is serious error in your thinking. After all, you are just JsLover...

About your "; after EVERY command is crap" I think it is crap per se. That is what we call consistent rules. VB in its previous syntax was very fond of special programming rules and that is why it was disastater. They completely changed its syntax in .NET version.

AHK suffers from same desease - it has bunch of special considerations.
If one thing should be done in v2, it should be removing ALL double things, or double ALL things (ie, func vs command), and stick to that from that point. V2 is good place to add multiple commands on the same line (not just 2 lines, like in if (..) cmd but more like in if (..) { cmd1 .. cmdn }) Although I tend to like command syntax it has serious limitation about not being able to redirect its oputut, thus you cant use them in expressions. This is very very big limitation if I am concerned.

There are too many good features suggested by advanced users here I think that AHK would grow to reall language if some of those are added. I personaly don't care at all about compatibility with pre v2.0 versions of AHK. If new syntax can be made, that can fix most of issues and wishes reported so far it should be done. After all, v2 comes once in the lifetime and language stay for eternity after that. The benefits of well designed v2 are tremendeous even with total loss of compatiblity.

I suggested that compatibility problem can be solved for some time if every new script requires /v2 directive. AHK can be distributed in package containing both v2 and the last 1.x in single exe and then interpreter can decide witch to use depending on presence of /v2 directive. After a year or so, 1.x can be removed completely. This will make AHK exe double size, but again, this is only temporary until everybody becomne fond on v2 and old syntax is forgotten.

About original post from PressingOnAlways I agree totaly. Not only n00bs have problems with the syntax, I have them all the time. While thinking about actual code to do, I tend to overlook things like := vs =, quotes or no quotes, single space after command and ; or no space, etc... I made huge number of such mistakes in each bigger script I wrote. The other most common error here is misstyped variable name (sometimes you can't even find this error, depending on typo)


As this observation is made by total AHK newbee, I would consider it as very important as this man here is often refered "typical user". Maybe this can lighten some paths for you Chris, that you were not able to see in the previous debates we had (you are strongly opiniated regardless the fact that you want to hear and comment everything purposed about AHK future)

This would be perfect indeed .

_________________

This kind of feedback will help design v2. Thanks.

However, I don't think supporting multiple statements on a single line deserves a high priority compared to other changes and features. In my opinion, concatenated code is generally less readable and shouldn't be encouraged, nor given a high priority in terms of development time.

As I said earlier, many of the documentation issues will be resolved in v2 because there will probably be only one assignment operator and one type of if-statement. Because of this, it seems best to work on v2 before doing a major overhaul of the documentation.

Thanks.

Atleast: It would be nicer if multiple variables could be initialised in the same line.
Just my humble opinion.

Regards,

_________________
URLGet - Internet Explorer based Downloader
StartEx - Portable Shortcut Link

I just want to point out the existence of REXX.





Maybe it could end all the discussions about how the format should be. Just an idea... (and with much respect for all the time used to develop the current format).

The truth is that being myself a programmer, I find it a bit confusing that the format is different to most popular programming languages. But I'm no one to say how it should be. AHK is very useful and I will just use any syntax it needs.

Doing POKEs and SYS' in a Commodore Vic-20 was more difficult anyways ;)

Yes, this is tentatively planned.

REXX is interesting and I appreciate such a readable, intuitive syntax. I realize that readability can make a big difference in the productivity and satisfaction of scripting.

On the other hand, it seems a bit radical to abandon the current syntax in favor of Rexx -- so much so that it's hard to even seriously consider it. However, if someone wants to research it more and study the feasibility, I'd be interested in your findings.

Nice to know it.. Thanks

_________________
URLGet - Internet Explorer based Downloader
StartEx - Portable Shortcut Link

That's an argument I see often (for Lua language too...), and find curious. I mean, there is little in common between Pascal (and dialects), C (and variants), Basic (mostly the Visual one), Perl, Python, to name but a few "popular" languages... Indeed, JavaScript and PHP are more or less C-like, but have their peculiarities.
Don't try to mold an original language in a so called "popular syntax" (which is often a C-like syntax, actually).
Well, you don't try: "But I'm no one to say how it should be. AHK is very useful and I will just use any syntax it needs.", wise saying.

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Well, such feature if planned will be great in v2 as an major change.

Also, I don't share your generalised veiew of readability. Some things are more readable that way, some are not, like anything else in this life. Its good to heave possibility. Also it depends on how are you thinking and about your other abilities so I hope you understand that your opinion about readability is highly subjective and you can't find any "real" reason not implement this. Its just principle of yours, and those can't be right or wrong, its just the way you do things.

For Instance:



is more readable then


This way you have ability to group things together on the same line that should be grouped by its meaning.

_________________