jeeswg wrote: ↑
08 May 2019, 02:44
- People like that the AHK v1 GUI syntax is relatively simple and succinct, that much is true.
Agreed. AHK v1 GUIs were the very reason why I choose the language for scripting and automating tasks that I had. Remember this was years ago. I didn't need any complex IDEs to create GUIs or to get eye burn from any convoluted syntax, when I needed to slap a simple GUI on top of a script or command line program.
And reading/listening to comments from AutoHotkey old timers and strong supporters like Jack Dunning (who has a AHK v1 VS AHK v2 GUI comparison on his blog) or Joe Glines, they don't seem particularly enthusiastic about AHK v2 yet. They can of course speak for themselves as to their reasons, but I suspect it's because AHK v1 is enough for what they want to do (if it ain't broke don't fix it) or they don't see enough benefit yet in switching over. Remixing the syntax to suit a particular style of programming, while also eliminating often used features, is not necessarily a benefit in itself.
- AHK v1 used g-labels (like the Sort command used an F label), this isn't so bad, but I did not like the use of A_ variables that came with it. Using the OnEvent method is a solution, and gives you more granular control over events.
- In my GUI functions library, where everything is done via hWnds, and no objects are used, I'll probably have a GuiOnEvent function that uses window/control hWnds.
I just don't see A_GuiEvent and A_EventInfo, which can do a lot of what GuiOnEvent is doing, or the "A_Variables" as any type of enemy (as I didn't see g-labels or Labels as such). This is what I mean by "remixing", which is a bit different from cleaning up the syntax. We are talking major revisions of the language and fixing what arguably isn't broken. It's of course the prerogative of the developers, but do think if changes are for the users
, that their input and what's in their best interest should count. I don't see how taking a simple to understand and use language and making it more difficult to understand and use is for the greater good. I'm no way against change. It's just that when doing so, I would think the benefit of such a change needs to be overwhelming, as oppose to very minor.
- I don't use labels/gosub/goto, but they should be kept, they are useful for some tasks, and for translating to/from other programming languages.
- I'm actually happy for AHK functions to call functions only, and not use labels.
- If I'd created AutoHotkey from scratch, I probably wouldn't even have thought that a function would use a label as a callback function, it seems pretty unusual. Does it exist elsewhere?
A bit contradictory, because labels, gosub, goto, and return work together. If we become primarily a function orientated language, then the other useful constructs end up getting tossed out. We become more C++ Lite, then the easy AutoHotkey scripting language that it was. But what attracted people to using AutoHotkey in the first place (to include it's cousins of WinBatch and AutoIt)? This is why I believe if you make AutoHotkey difficult or more restrictive, then the debate enters in why not use C++, Object Pascal, or Java. It's not like they don't have SendKeys, script variants of the programming language, or can't use the AutoHotkey.dll.
In AHK v1, we can put functions into labels and labels into functions. The users choice isn't forced, they have both functions and labels to play with. And part of that point is that AutoHotkey offers functionality that other programming languages don't
, not that we are under the same restrictions as other languages. People arguably use AutoHotkey because it's not
like most other OOP-ish programming languages, and want something different.
- Hotkey labels are useful for quick code examples/smaller scripts.
- Interestingly, I'm thinking of removing hotkey labels in my main (massive) script.
I find this a bit contradictory as well. You are acknowledging the usefulness of Hotkey labels, but then are contemplating removing them. I think the Hotkey labels are fantastic. It's the point of AutoHotkey
, it goes to the very core of the usefulness of this scripting language. Otherwise, we could suffer through PowerShell or go hard core C++.
- I agree with Uncle Bob that functions should be small. I also agree that high-level functions should only contain high-level code, and that medium-level/low-level code should be moved out to separate functions.
- However, some 'functions', what I might call 'large-scale subroutine functions', are different, and it's fine if they're long. (I.e. functions that are not going to be used by other functions.
Large-scale subroutine functions... Is that like another way to say Classes, and then the avalanche of OOP concepts? Or, are we talking about these awkward humongous parameterless functions that are basically a Label, just we don't want to call it that? How is it that Labels and simple syntax became the "bad guy"? Don't get me wrong, I have nothing against functions, I just don't get this forced choice we have come to. A world where we can have only functions or labels. And I'm just not seeing how this is making life easier for non-programmers that were hoping to use AutoHotkey to do some simple automation task, that could be done easily with g-labels, labels, or hotkey labels.