I would have to strongly disagree with the assumptions that you are making. Everyone's situation is not the same.swagfag wrote: ↑03 May 2019, 16:07just lol @ labels being flexible. anything but. sure, for ur run-off-the-mill hotkey/hotstring scripts and toy gui scripts they might get the job done, but try doing anything even moderately more sophisticated than that and ur options are waste hours of ur life trying to come up with hacks to mold them to fit ur needs, and waste hours of ur life trying to come up with hacks only to realize what u need is actually impossible and be forced to give up
1) Arguably the majority of scripts that people make are run-off-the-mill hotkey/hotstring scripts and toy gui scripts, where labels are quite easy to use and understand.
2) Labels can be used in very large scripts without a problem, to include they are usually not the cause of the issue a user might be having.
3) The Label concept works quite well with hotkeys #n::, both visually and as a concept of teaching how to execute sections of code.
4) Functions in AutoHotkey are not compiled into DLLs. Therefore their use should arguably be more optional, than deemed mandatory.
5) Imposing and forcing a style of programming is unnecessary rigidness and hurts many of AutoHotkey's users.
You are talking about users with thousands of lines or more of scripts that are working, used at home, their business, or at their jobs. That they must rewrite them to suit someone else's style of how they should write scripts is arguably not for the greater good. It's one thing to clean up some questionable syntax, it's another thing to impose an unasked for different style of programming, where they are pushed to redo months or years worth of scripts.
I was in no way defending the abusive use of Goto, but rather clarifying that Gosub and Return is a different animal.Goto has only one legit use - breaking out of n-nested loops cleanly. if ure using Goto for anything else other than that, do urself a favor, Ctrl + A, Del and start over. ur future-self will love u for this.
Labels, Gosub, and Return can be used together and those scripts can work rather well.
1) The old timers understand that what people are doing in the higher level languages is breaking down to doing similar things in Assembly. So they tend not to sweat it and go on crusades about one style vs another.so what? their being fine with it doesnt mean it should be used, especially not given the availability of more powerful constructs. noone in their right mind uses Goto in lieu of while loops, so why should this apply any differently to other cases(the cases being functions v. labels)discussions among old timer programmers or Assembly programmers, they are perfectly fine with Goto, Gosub, etc... in higher level languages.
2) The other issue also at work here is a matter of choice and preference. That one person believes a certain construct is more powerful, doesn't mean that it's easier to use or that others shouldn't be allowed to prefer something else.
1) This comes down to preferred style and ease of use. The argument is that the choice should not be forced.haha, nice try but no. only as powerful as a parameterless assume-global function.
2) Keep in mind that a Label can contain and call functions, extensions of Classes, and use built-in variables. The Label is marking the start of a subroutine, which can house all kinds of code and variables. Labels can arguably be more comparable to a Class, which is housing groups of variables and functions, not just a single function.
Code: Select all
Gosub MyLabel
MyLabel:
Do Lots of Stuff
ThisFunc()
ThatFunc()
MyFunc()
Return
Code: Select all
MyFunc()
MyFunc()
{
global
}
IT and business is a wide field. People working in sales, marketing, with routers and servers, etc... are not programmers. They aren't baboons or morons, they simply may not have a background in programming and can be pressed for time. They can be looking for a quick fix to make their lives easier, and aren't trying to get that deep initially. These discussions are not me formally training anybody, but informal introductions to something they might find useful, with quick explanations. Then it's up to them to dig into it, however deep that they would like to.idk what kinda people u tried explaining this to, but u have to be a LITERAL baboon to not understand functions. u must have been explaining it wrong
Debatably, this is where the vast majority of AutoHotkey users are coming from. They are dipping their toe into programming, as a quick fix to some annoying or repetitive problem, but are not trying to go all out or work as programmers. They gradually and slowly get deeper over time, often in sporadic moments of their spare time, with things like sports, shopping, clubbing, gossiping, etc... competing for their attention.
Understanding how to break a script up into tasks by using Labels is an easier to understand concept than functions, classes, and dropping OOP on their heads all at once. Particularly when talking to adults with day jobs and other things they like to do. And as I mentioned, once Labels are understood, parameterless functions is a next easy step (then single parameter, etc...). You can see this transition in various threads in the Help forum and old forums.
In many cases people are just using parameterless and single parameter functions or stuffing a bunch of functions into a Class, in place of using Labels, and acting like it's the new "hotness". Demonizing Labels arguably doesn't make any sense, if you are using functions in the same ways to organize code in a script. It's just a different style of writing code, until the next fad comes along.
And with Labels, you are not forced to choose. It's quite easy to use both, call functions (or extend Classes) from Labels. Clearly various people go "all in" with functions, and won't use anything else, but that's not the history of AutoHotkey. This can be very clearly seen in the old AutoHotkey forums, where many were comfortable with using Labels or both functions and Labels. I don't see forcing functions as the only style of programming as a benefit, especially in a language which doesn't compile code into DLLs.
The Goto argument is a red herring. Nobody is defending Goto abuse, and Gosub and Return are different. Though you are making some very valid points, you are also contradicting your own arguments in some obvious and not so obvious ways.its absolutely, invariably more spaghetti. global state, namespace pollution, mutations all over the place, and u cant even know its happening unless u specifically check for it. delicious and a whole lotta fun! u might not think its a problem since u already know whats going on in the script, after all, it was u who wrote it. but give it to some other random person, ask them to make sense of ur goto-carbonara main course and just watch them reach for the closest gun barrel to choke on.
1) All scripts are not made to be given to others.
Even on a professional level, the author of a program may have no intention of sharing their code with others, thus use encryption or obfuscation.
2) Spaghetti code is not the same as using Labels. You can only use functions and write the most spaghetti mess, with no comments or bizarre naming conventions, so that nobody will understand it and it qualifies as a form of obfuscated code.
Labels are a way to organize code, by breaking it up into tasks to be performed, not the other way around.
3) If the code works and the user is satisfied with it, so be it.
It's not like there is an AutoHotkey Code Stormtropper Committee that gives out grades for all scripts written, and failure to meet expectations means punishment
. What is usually important to people is that it works and how easy it was to write it, not how pretty it looks or getting a grade. The vast majority of AutoHotkey programmers are not working on teams with other programmers that are evaluating the quality of their code. And when it comes to sharing code, if they give it out to others and somebody doesn't like how they wrote it, then they are free to rewrite it (unless restricted by copyright).4) Global state and namespace pollution are arguably not valid reasons to eliminate often used and useful features from the AutoHotkey language.
The programmer must manage and track use of variables, regardless of using labels or functions. How the programmer chooses to manage variables in their scripts should be up to them. The use of functions, objects, or OOP concepts doesn't shield the programmer from this responsibility. In many cases, the programmer wants to use global variables or the issue of local vs global is inconsequential for the small scripts or kind of scripts they are writing.
Labels can be used easily, responsibly, and relatively efficiently for the task at hand and type of script a user is making. And they can be used with functions, classes, and objects as desired. Eliminating options and well used existing features that provide ease of use from AHK v1, is reducing the benefit of using the language. If AHK v2 will be so rigid and limited, then it makes itself less attractive and reduces its comparative worth to AHK v1 or in comparison with other program languages that force such kind of limitations and are difficult to use. AHK's flexibility and ease of use should be seen as a benefit, not something to arbitrarily eliminate.
Not everyone agrees on what is the best coding practices. You also have to account for style and preferences, which is different from what is arguably the best coding practices. And a script full of functions and no comments, might not be as self explanatory to others as you think....OOOOR u could just use a function instead - no comment needed, parameters are immediately visible, return values are immediately visible, and if u adhere to best practice coding standards which u should btw, ie no global, u can be SURE of it, without even looking.
I disagree. For example, shielding a noob's so delicate eyes from the dreaded %%, doesn't mean he won't have to use it in a .bat or .cmd file on his Windows computer or in his script. That you learn one way, expression syntax, doesn't mean your brain can't learn other ways. Forcing a particular style on a user in AutoHotkey is not going to help them if they go learn a different programming language. Object Pascal does things differently. So does Java, C++, C#, Swift, Assembly, Visual Basic, etc... So being so inflexible and rigid is not going to be helpful, when the person has to go outside of their comfort zone.no, no no no no, absolutely not. many ways to do similar(but not quite identical) things are absolutely detrimental to AHK's usability. take Traditional v. Expression syntax for example. u have a noob start off with traditional, he learns it fairly quickly, lets say. now time comes, turns out he needs to do something which traditional doesnt support, say, double-deref a variable or whatever. what happens next? great, now hes gotta spend time learning expression syntax. thats time wasting learning the parts already covered by traditional syntax and he'll be more prone to fukups in the long run, since he'll be more used to traditional syntax, and its likely his grasp of expression syntax will stay poorer for longer. Now, imagine a world where traditional syntax was pruned and all u had was expressions. He'd spend more time upfront(arguably tbh) learning expression syntax, but then he'd be set for life, he'd be able to do anything and everything with expression syntax alone. he would have to keep track of two things at the same time. u know, there's a reason why some languages(python comes to mind) strive toward coming up with the most idiomatic ways to write code. u dont praise cpp for its ease of use: "just look how flexible it is, 20 or so ways of initializing stuff!! amazing!"
And it works in the reverse too. That a person learned C# or comes from an OOP style, doesn't mean it's for the greater good to impose those standards, preferences, or styles of programming on a different language, with a different audience, that serves a different purpose.
I can't speak for jeeswg, but you are unintentionally making the case for why various people are reluctant or are not enthusiastic about v2. If a person has a large v1 production script (or many of them), they are probably not feeling good about possibly losing developmental support in the future. The thought of having to convert a working v1 script over to v2 for minor benefits or just for a style preference could be upsetting.@jeeswg
frankly, ur converter script idea to me seems like a pipe dream, and im not saying this to demotivate u, diminish ur accomplishments or discredit the work uve put in. i simply doubt the extent to which it will be of any use. presumably, it will be able to only somewhat translate v1 syntax to v2 syntax, 1:1. but will it be able to transform GUIs? will it be able to turn labels into lambdas, use nested functions etc, ie the things that make v2 v2? even if u were to somehow copypaste port v1's parser from source, expanding upon it to factor in conversions of this nature, seems like a super massive undertaking.
besides, theres no way in hell im running a converter script alone on a production script. id have to write or rewrite the tests for v2 first and then id have to still manually touch things up(cuz lets be real, no chance its gonna do a full 100% accurate conversion), at which point u have to wonder - why even bother with the conversion script? after its done, at best, ud have a v2 script written in v1 style, at worst, a non functional mess. Who is this tool even aimed at? Noobs? Unless its gonna do 100% accurate conversions, theyre gonna be stuck with a non working script, which theyll have to still learn and figure out how to fix themselves. Pros? Yeah, its probably gonna save them some time, maybe, but then again they could instead rewrite manually to better take advantage of v2's newer features.
A v1 to v2 converter script is their only ace in the hole, to help convert their scripts over, so they can continue to get bug fixes and see continual development. True, a converter script won't be 100%, but it's arguably better than starting from 0 with a 10,000 line v1 script. And if they have many scripts, that's a tremendous amount of time they need to invest switching over, so would likely want any help that they could get.
And, it's possible v2 might cause another fork. It's clearly possible to update v1 with backported functions from v2, and keep it backwards compatible. Many people might only feel an upgrade to v2 is necessary, because it's the version that's continually developed and given bug fixes, more than anything else. If someone was willing to maintain and bug fix v1, it could probably continue with a following.