62 replies to this topic

[PhiLho]

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 ^^

Yes. That's the problem with powerhouse languages...
I learnt Java last year, and once the basics are mastered (more or less), the biggest difficulty isn't to program features, but to avoid to program unnecessarily features already existing in the API! Not to mention the features found in 3rd party libraries!

It is a bit like you write an AHK program to read an .ini file and parse the content, to find later there is already much more efficient function to do this.

One problem is that for Java and probably most of the other languages (including AHK), the API documentation is made to document the existing functions, but make hard to find a general feature (how do I write "1 car" or "2 cars"?) and even make hard to see a global figure (how does this class is used/relate to other classes?)
Indeed, there are tutorials, but for huge APIs, it takes lifetime (or almost) to read them all!

Here, simplicity and specialization, like in AHK, is an advantage.
And indeed, for a freeware product, AHK doc. is excellent, and support is 1st class! :-)

[JSLover]

I also prefer "X = A * (B - 2)" to "X=A*(B-2)", the eye has more space to breath... ;-)

...with complex math, it's easier for my eyes to see all of it in one place & figure out the math, than to r e a d c r a p a l l s p a c e d o u t...now don't that take a couple reads to put together?

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

...obfuscated code, is one of the 'reasons' for a semi-colon...the 'no reason' cases are when one statement is on the line, like...

int i=1;

...in that case I don't see a need for a semi-colon...but I also don't like the need for a var type...in JavaScript (unlike C), you can just do...

i=1
i='yo momma'
i=2

...no semi-colon, no var type...a variable is just that, vary-able, able to vary between a number or a string (or anything else)...I still don't know how to make a simple string var in C...

char thisdontalwaysworkright[128]='this makes things crash depending on how you use it later';
LPSTR idontthink='this ever works';

Some people have asked for it, perhaps because they feel it improves readability.

...it don't. It don't look like a function call with spaces.

So as long as it isn't too hard and doesn't hurt runtime performance, it seems best to support it.

...I guess, I'm all for flexibility, but please don't bend too far over for it. There are better things to bend over for...like...

The difficulty of implementing this seems much harder than one-true-brace.

...I didn't really mean the full-JS style in AHK, a half-way point would be good...

Current...

if thiskindasucks
	that=yup
else that=nope

New 1 (a)...

if thiskindarocks that=yup
else that=nope

New 1 (...

if thiskindarocks=1 that=yup
else that=nope

...slightly obfuse, but you should be able to find the condition...

New 2 (a)...

if (thiskindarocks) that=yup
else that=nope

New 2 (...

if (thiskindarocks=1) that=yup
else that=nope

...condition in parens, not obfuse...also I'm not worried if I can scrunch the else on the same line (as in JS) I just want simple assignments or returns or breaks to work...

New 3...

if (byebye) return
if (stoploop) break
if (ilikecheese) ireallydo++
if (ilikecheese) ireallydo=Yes
if (ilikecheese) ireallydo:="Yes"

...it might be nice (tho completely existing script breaking) for semi-colon to be treated as in JS...as a 'newline' (loosely speaking of course)...I prefer // for a comment (but I haven't yet used #CommentChar in my scripts to change it tho)...but I also see it's now floor divide, so it's kinda out for a comment char, perhaps ;; (double semi-colon) could be treated as the comment char & 1 semi be the "multiple commands on one line" char (or the other way to save precious existing scripts). How about #MultiCmdOnLineChar (or a better name)...basically in pre-processing, you could replace the "multi line char" with a real newline & not have to think about it further?

Speaking of "I prefer // for a comment"...why doesn't this work...

/*if goawayfornow=1
	break*/

...you have to do...

/*
if goawayfornow=1
	break
*/

...I really don't like all these line breaks, some lines only have 2 chars to em, wasting vert space in the editor.

Although I think that would hurt runtime performance

...how would it do that? Allowing...

wow:="cool"
this:='too'

...would hurt runtime performance? You could pre-process singles into doubles?

[Chris]

if thiskindarocks=1 that=yup
else that=nope

This would break existing scripts unless a new directive were added. Even if it weren't for that drawback, I don't think the single-line style is common enough to be given a high priority (though it's still on the to-do list).

How about #MultiCmdOnLineChar (or a better name)...basically in pre-processing, you could replace the "multi line char" with a real newline & not have to think about it further?

Interesting, but my expectation is that it would be too rarely used by the typical user to justify the added code size.

Speaking of "I prefer // for a comment"...why doesn't this work...

/*if goawayfornow=1
	break*/

It's a documented limitation that exists because supporting */ would be ambiguous at the end of most commands. I think it would also break existing scripts.

Allowing...

wow:="cool"
this:='too'

...would hurt runtime performance? You could pre-process singles into doubles?

They could be preprocessed, but that would also change the way ListLines displays the lines. In addition, I think preprocessing would defeat any chance of supporting literal double quotes inside single quotes (and vice versa) the way PHP and perhaps other languages work -- unless even more advanced preprocessing were done to escape any literal quotes inside the string. Although these are minor annoyances, they add up. Even so, I've added your idea to my notes (as I said earlier, supporting single quotes is already on the to-do list for reconsideration).

Thanks

[JSLover]

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

...I just noticed in the Announcements forum you replied to someone asking about new features & pointed them to this post. 1) is about one-true-brace (wikipedia)...I replied already (here) saying I wanted this, but I just thought about something...can you support this too...

if (ilikecheese) {	; one-true-brace (or K&R/Kernel Style)
	ireallydo=1
} else {				 ; close previous brace on same line as else?
	noidont=1
}

...also do you have a reply on the "New 3" versions I posted above?

[Chris]

} else { ; close previous brace on same line as else?

Thanks, I'll look into it.

...also do you have a reply on the "New 3" versions I posted above?
if (stoploop) break

So rather than allowing only an open-brace to the right of an if() statement, it should allow any command or expression? It seems like a good enhancement; I'll try to add it if it isn't overly complicated.

Thanks.

[corrupt]

if (ilikecheese) {	; one-true-brace (or K&R/Kernel Style)
	ireallydo=1
} else {				 ; close previous brace on same line as else?
	noidont=1
}

That looks like it could get really nasty to troubleshoot a bug if you had a few if statements nested together using that layout...
What's wrong with:

if (ilikecheese)
{   
   ireallydo=1 
} 
else
{             
   noidont=1 
}

? A lot easier to read isn't it? A Then option might be nice to have though for simplifying code and making logic easier to follow.

If this=iseasiertofollow Then please=addtosyntax

[PhiLho]

I also prefer "X = A * (B - 2)" to "X=A*(B-2)", the eye has more space to breath... ;-)

...with complex math, it's easier for my eyes to see all of it in one place & figure out the math, than to r e a d c r a p a l l s p a c e d o u t...now don't that take a couple reads to put together?

I believe that math and English are different cases, but I won't argument over that, this is clearly a case of personnal taste.

I also don't like the need for a var type...in JavaScript (unlike C), you can just do...

i=1
i='yo momma'
i=2

...no semi-colon, no var type...a variable is just that, vary-able, able to vary between a number or a string (or anything else)...

For small scripts, this is OK and some time even convenient.
There are several problems tied to absence of declaration.
For example, typos:

myWontThisLongVariableNameLookGood = 10
[1487 lines below]
for (i = 0; i < myWonThisLongVariableNameLookGood; i++)

With imperative declaration, the compiler detects a problem, without, it will just skip the loop (or throw an error) as the variable is null.
The variable name is caricatural, but it is easy to make typo even with shorter names.

Also strong typing avoids confusions, can save space (was critical when you got 64KB computers) and allow optimizations (was critical when you got 1MHz CPUs...), introduce more rigor (less sloppy) in the coding, etc.
Note: the size & speed points are more or less a thing of the past for most desktop computers (unless you are doing video processing...) but are still important in embedded targets (your mobile phone, your VCR recorder, your GPS navigator...).

I am used to both styles of language: C/C++/Java/Basic vs. JavaScript/Lua/PHP/whatever.
I like the freedom and quick coding of the later, and the rigor (exactness/stricness, not rigidity :-) ) of the former, depending on the size of the project.

I have to confess that I really dislike a lot of the syntax in C++[...]If AutoHotkey moves "closer" to any programming/scripting language than I think that language should be Javascript/JScript. Javascript is easier to understand, use, and its everywhere.

Well, JS syntax is very close of C/C++ syntax, just a bit more relaxed.
A true JS interpreter would increase dramatically the size of AHK. That's one advantage of Lua, it only add around 100KB to a program which embed it.

[Thalon]

To avoid problems of typing I normally use an Autocompletion for longer programms (like it is included in PSPad).

I do not have any problems with the syntax of AHK.
What me took a long time at the beginning is something like this:

if A = 10
{  A = 8
    B = 5
}

The variable "A" will never get the value 8. I was used with this style from c-programming.
Also I did wonder about my strange errors after inserting this comment:

/*I_am_a_variable = 5
I_am_a_second_variable = 6
*/
I_am_code = 7

There are sometimes a bit strange errors when script should be run and there are errors like this in it. The first time it took me more than half an hour to find this problem

But I am now used with this little problems and do real programming with AHK 8)

The possibilities are great!

Thalon

[JSLover]

That looks like it could get really nasty to troubleshoot a bug if you had a few if statements nested together using that layout...

...that's my problem...bring on the trouble! Seriously, it's more comfortable that way, I know what I'm coding & it doesn't "get nasty" to me. However, this is nasty to me...

What's wrong with:

if (ilikecheese)
{   
   ireallydo=1 
} 
else
{             
   noidont=1 
}

?

...too many unnecessary line breaks...

A lot easier to read isn't it?

...no, it's too much line breaking, too much unused space...it seems space helps you all read better, but it just makes me look harder to pull the things on the opposite side of the space together. The only good space is proper indentation.

A Then option might be nice to have though for simplifying code and making logic easier to follow.

If this=iseasiertofollow Then please=addtosyntax

...I don't want Then...too much like Basic...(or more accurately, I don't want to be forced to use Then...I want syntax that works without it...it can be added if it helps someone tho)...I like ! != && || over not <> and or...I like the symbols for that, they read more normally to me...& <> is just silly...greater than AND less then??? You are programming, not speaking...which is better...

if the variable pet is equal to the string dog then
	run the function throw up about this syntax
otherwise
	run the function pet the cat

...or...

if pet=dog
	throwupaboutthissyntax()
else
	petthecat()

...or better yet...

if (pet="dog") throwupaboutthissyntax()
else petthecat()

What's wrong with...

If (this=iseasiertofollow) please=addtosyntax

...see no need for silly Then. It's like the C++ semi-colons...99% unnecessary...except Then is 100% unnecessary...obviously after the condition on the if, then do something...the language don't need that word there...about the semi-colons...you should only need them to separate multiple commands on one line, but they are picky & want them everywhere...unnecessary...obviously if the line ends & you have enough info to do something, do it, if a function call (or something) ends unfinished (spread over lines), keep reading until it's finished...don't look for a semi-colon.

[corrupt]

Although it may seem a bit unnecessary, I think adding Then to an If statement drastically improves readability (and I imagine would be easier to parse...). It's probably only a matter of taste but I was thinking that something like: If this=true Then do(this) ; would seem a bit more logical to a non-programmer...

[Chris]

Although I like the idea, I discovered while working on one-true-brace that adding things other than '{' to the end of an if-statement is difficult. This is due to the way expressions are parsed.

Adding support for "Then" would also make "Then" a quasi-keyword like "And" and "Or", which might break existing scripts (hard to tell for certain without a careful study).

Another drawback is that it might make it harder someday to support having an IF's action at the end of it's line rather than intented beneath it. For example:

if WinExist("Untitled - Notepad") WinActivate

The presence of an optional "then" keyword above might make it more difficult unambiguously resolve such commands.

Even so, I'll put this on the to-do list for reconsideration because I've come to value readability even more than I used to.

Thanks.

[Thalon]

I hope you consider "Then" only as option and not as new form for if-statement!?

I do not like a "Then" in if-statements and do not see anything positive at them! They are just for scaring programmers

Thalon

[Chris]

if (stoploop) break

It turns out that supporting "any command" on the same line as an if-statement would take longer to implement that it was worth (expression parsing makes it difficult to do). In addition, the benefit seems low because scripts that use that style are generally thought to be less readable.