People going constantly offtopic and other problems

[iseahound]

The only thing stopping AHK from accepting a Functional Programming paradigm is this continued insistence on boundFuncs, particularly the special syntax needed: %boundfunc%()

[nnnik]

One of many things stopping AHK from doing anything like that is the fact that AHK has nothing to do with Functional Programming and that it doesn't fit the language.

[iseahound]

We should be able to test breaking changes, without an emphasis on everything being bug-free. Many advances in computer languages have been linked to the adoption of implicit de-referencing. A pointer to a value requires an explicit dereference to retrieve the value. A reference to a value, also called a variable, has implicit de-referencing. I'm in favor of minimizing pointer-like behavior, to smooth out the syntax, and to make the language easier to use. (That means the current BoundFunc is like a primitive pointer.) The current changes make the language more complex, and while I see the value in differentiating different parts of the object, I hope that the final outcome of v2 is simpler than v1.

[iseahound]

I'm not happy with some of the changes, like the way static means something different in v2, but I'm willing to see where it goes. It would be appreciated to see AHK adopt some of the newer features found in other languages as part of the modernization effort. I'm not able to contribute directly to v2, but I'm able to test things if you wish.

[SOTE]

@Helgef
I agree with what you say about AutoHotkey 1.1 it does have odd quirks but this is due to its birth from AutoIt and later development. Recently certain features have been flagged as 'depreciated' in 1.1 simply because they don’t translate easily to version 2. They still work fine in version 1.1 and will continue to do so in subsequent version 1.1 updates, so there is a certain dishonesty in the documentation.

Version 2 was going to be the fix for the 1.1 quirks but seems to be developing into an out of control monster. Every new version breaks compatibility with previous versions and goes deeper and deeper into the OOP paradigm - fine for experienced programmers brought up with OOP but not so good for others. What you’re proposing seems to be to continue the alpha-type breaking-changes development into the released product.

It is really depressing to think that the developers appear to have no vision as to where the continuing development of version 2 is heading, so that they need to have an 'out' so that they can remove features that they once thought were a good idea.

Cheers

I agree about falling into the OOP trap. Brian Will's videos on the topic explains the issues and demonstrates it in code.
https://youtu.be/QM1iUe6IofM (Object-Oriented Programming is Bad)
https://youtu.be/IRTfhkiAqPw (Object-Oriented Programming is Embarrassing: 4 Short Examples)

OOP has it's place, but it should arguably be more optional than primary or mandatory. Especially when you are talking about an automation based scripting language that should be making things easier to do, rather than more complex.

Another possibly source of confusion could be coming from class based programming languages vs prototype based languages. Prototype based languages (AutoHotkey, JavaScript, Lua...) seem to bother certain types of programmers in how they are structured or the way things are done. As things are not done the same in the languages they are coming from, this might make AutoHotkey a bit upsetting to them.

I never thought AHK v1 to be as "bad", as some make it out to be. For the majority and casuals, AHK v1 is wonderful. Though I do understand that more professional or more "classically trained" programmers have their issues with it. But isn't the target audience and purposes different? Sure AHK v1 needs to be cleaned up a bit, so hoping that whatever becomes of AHK v2 that it will be found as useful and so cherished as AHK v1.

Maybe this might seem odd, but I never understand the focus to make such a break from AHK v1, when there was/is IronAHK laying around (https://github.com/Paris/IronAHK). I mean if various developers want so badly to break from how things are done in AHK v1, it seems they could have implemented many of those changes in IronAHK, and probably the majority of users would have cheered them on. They would be bringing users a cross-platform version of AutoHotkey for Windows, Macs, Linux, and smartphones.

I think some of the resistance to AHK v2, is people aren't sure how much better it will be compared to AHK v1, and some seem to want AHK v2 to be way more radical than just cleaning up odd syntax in AHK v1. AHK v2 will also be occupying the same spaces as AHK v1, on Windows, which kind of creates 2 sides against itself vibe.

As for breaking changes, there is something to be said for reliability and stability. Sure change or radical change can be good, but being cautious and being conservative has it's place too.

[Helgef]

As for breaking changes, there is something to be said for reliability and stability. Sure change or radical change can be good, but being cautious and being conservative has it's place too.

Thanks for finally attending to the actual topic of this thread. I am not suggesting a reckless approach to making breaking changes, all changes should be carefully considered.

Cheers.

[nnnik]

I mean sometimes it doesnt matter how recklessly we throw the garbage out of the window

[jeeswg]

@Helgef: You mentioned 'BIF parameter ordering'.
The massive inconvenience of checking/reordering old instances of a function, far outweigh any convenience gains of reordered parameters.
Realistically, BIF parameter reordering would necessitate a new function name, and if this wasn't done, I'd create a new function myself so that I'd have certainty that I'd updated the old code.

Further points:

Spoiler

---

@just me: Re. the likelihood of future x.b.x.x updates. There is reason for optimism, as more commands are removed from these 2 locations:

enum_act
AutoHotkey_L/defines.h at alpha · Lexikos/AutoHotkey_L · GitHub
https://github.com/Lexikos/AutoHotkey_L/blob/alpha/source/defines.h

Action g_act[]
AutoHotkey_L/globaldata.cpp at alpha · Lexikos/AutoHotkey_L · GitHub
https://github.com/Lexikos/AutoHotkey_L/blob/alpha/source/globaldata.cpp

---

@TAC109 (and @SOTE): I'm slightly surprised by the somewhat gloomy outlook.
I think that AHK v1.1 and v2.0 have maintained the simplicity of AHK v1.0, and added important new features. (And I don't feel that there's been scope creep.)

In general, I think the important things are:
- Adding a handful of two-way compatible ways of doing things, e.g. add if (var is type) to AHK v1.
- Code that is relatively easy to auto-convert, e.g. allow this in AHK v2: vText := ControlGetText(, "ahk_id " hCtl), alongside vText := ControlGetText(hCtl).

I think that all of the devs have a clear vision.
If there's an 'out' I want, it's for things like SubStr (-1 for last character, not 0) or StrPut UTF-16 (return byte count, not char count). With a bit of users raising the alarm, perhaps such things could have been changed in the 1-year window, rather than in x.b.x.x or a.x.x.x.
Anyhow, even for those examples, you could have a 'v2 mode' A_ variable to make the functionality more AHK v2-like in AHK v1.

Although I think that going too deep into OOP is a danger, I think we're avoiding it.
However, possibly, for the sake of new users, I would avoid using fat-arrow functions in documentation examples.

---

@nnnik:

One of many things stopping AHK from doing anything like that is the fact that AHK has nothing to do with Functional Programming and that it doesn't fit the language.

AFAICS the consensus is that many languages already support a lot of functional programming paradigms, even without trying to.
And that with a few tweaks here or there, a language can become quite effective for FP.
Here's an interesting video:
Why Isn't Functional Programming the Norm? – Richard Feldman - YouTube
https://www.youtube.com/watch?v=QyJZzq0v7Z4

Cheers.

[SOTE]

---

@TAC109 (and @SOTE): I'm slightly surprised by the somewhat gloomy outlook.
I think that AHK v1.1 and v2.0 have maintained the simplicity of AHK v1.0, and added important new features. (And I don't feel that there's been scope creep.)

In general, I think the important things are:
- Adding a handful of two-way compatible ways of doing things, e.g. add if (var is type) to AHK v1.
- Code that is relatively easy to auto-convert, e.g. allow this in AHK v2: vText := ControlGetText(, "ahk_id " hCtl), alongside vText := ControlGetText(hCtl).

I think that all of the devs have a clear vision.
If there's an 'out' I want, it's for things like SubStr (-1 for last character, not 0) or StrPut UTF-16 (return byte count, not char count). With a bit of users raising the alarm, perhaps such things could have been changed in the 1-year window, rather than in x.b.x.x or a.x.x.x.
Anyhow, even for those examples, you could have a 'v2 mode' A_ variable to make the functionality more AHK v2-like in AHK v1.

I must say, that I do like what I perceive as your view about upgrading from AHK v1 to AHK v2. That is a slow quasi merge of the 2 versions, so that the jump between them is small. When AHK v2 becomes the official version, if AHK v1 is pretty much as similar to it as possible and somewhat easy to convert scripts from the latest version to the other, I think the number of holdouts and complaints will be fewer. It can also prevent any major fracturing of the user base or backlash forking to a different version.

Though in the mix of this, I do find myself sad that IronAHK was never picked up by any developers. When you check it on GitHub, it does appear there were a few other developers contributing and particularly code for Linux and Mac OSes. Clearly there is user demand for a cross-platform version of AutoHotkey, and C# seems the most likely language to do it in (plus there is already existing code). Though if any C++ programmers feels a cross-platform version could be done in their preferred language, would be interested in reading their thoughts about it.

I mention this, as there is a kind of AHK v2 versus AHK v1 vibe. 2 versions that are relatively similar to each other, battling over the same user base on the same OS. But clearly there is far more room for radical thought and changes in the C# and cross-platform space. The concept of throw all this "garbage out" and let's do it "this way", would have little to no resistance from users that don't have any scripts (beyond test scripts) or any investment in the "old ways" or any old version of the software when it comes to a C# or cross-platform version of AutoHotkey, like IronAHK.

Although I think that going too deep into OOP is a danger, I think we're avoiding it.
However, possibly, for the sake of new users, I would avoid using fat-arrow functions in documentation examples...

AFAICS the consensus is that many languages already support a lot of functional programming paradigms, even without trying to.
And that with a few tweaks here or there, a language can become quite effective for FP.

Why Isn't Functional Programming the Norm? – Richard Feldman - YouTube
https://www.youtube.com/watch?v=QyJZzq0v7Z4

Good video, by the way. Though it does bring up the question of if some aspects of the functional programming paradigm can be taken a bit too far as well, since it's not more widely adapted. But, I do agree that many languages have borrowed many useful features of functional programming, and that's arguably a good thing.

I think AutoHotkey can take some inspiration from what is being done in JavaScript in that regards. Additionally, because it's likely that advanced AutoHotkey users would have some interaction with JavaScript and that it's also a C family language.

[nnnik]

Im honestly not sure how to deal with this as a staff member. The usual suspects have come around and completely bombed this topic with offtopic discussions.
Its at a point where it has become a problem to the productivity of this community.
On the other hand we haven't banned anybody for talking nonsense and I don't feel like that should be a thing here.
Still the facts stand. Im not quite sure how to salvage this topic or the situation.

Perhaps it is time that we add a dunce role which would limit users to making posts in the Ask for Help section. That way they might end up having more of an idea what this topic and language is about.

[jeeswg]

A link to the original thread:
v2 breaking changes policy - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=69922

nnnik, while others could have been more ontopic, your posts have been the worst:

Spoiler

Helgef:
Offtopic, summarised the present policy but offered no changes.

a more suitable frequency of changes to b is perhaps every one to three years

Offtopic, AHK v2 is taking time to develop, this has nothing to do with a breaking changes policy.

nnnik:

a certain aspect of the currently provided API is garbage

Immature/controversial/inappropriate remarks, especially from a mod/admin.
And other offtopic statements.

just me:
Offtopic, this is not about the release policy:

the possibility of a major release after v2?

guest3456:
Offtopic, talking about scope creep.

Helgef:

V2.0 could be released earlier if we allow some decisions to be made later

Not relevant. The list of planned AHK v2 first release features is already minimal.

jeeswg:
Concrete suggestions, a 1-year window for changes.
Concrete suggestions, an n-year window for changing v2.0.

Helgef:

We should be on 1.5 now

Either silly or needs expansion.

Why should anything be set in stone?

A statement unconnected to anything previously, could derail the thread.

nnnik:

A lot of scripts that work in

This post is a bit of a time-waster.

nnnik:

Functional Programming and that it doesn't fit the language

Redundant/offtopic comment about functional programming.
And potentially misleading.

nnnik:

I mean sometimes it doesnt matter how recklessly we throw the garbage out of the window

Again with the spam posting.

nnnik:

Im honestly not sure how to deal with this as a staff member. The usual suspects have come around and completely bombed this topic with offtopic discussions.
Its at a point where it has become a problem to the productivity of this community.
On the other hand we haven't banned anybody for talking nonsense and I don't feel like that should be a thing here.
Still the facts stand. Im not quite sure how to salvage this topic or the situation.

Perhaps it is time that we add a dunce role which would limit users to making posts in the Ask for Help section. That way they might end up having more of an idea what this topic and language is about.

Completely ridiculous post, completely offtopic, more offtopic than anything so far, and reeks of 'I'm an admin, you're not, let me abuse my powers'.

[SOTE]

Im honestly not sure how to deal with this as a staff member. The usual suspects have come around and completely bombed this topic with offtopic discussions.
Its at a point where it has become a problem to the productivity of this community.
On the other hand we haven't banned anybody for talking nonsense and I don't feel like that should be a thing here.
Still the facts stand. Im not quite sure how to salvage this topic or the situation.

Perhaps it is time that we add a dunce role which would limit users to making posts in the Ask for Help section. That way they might end up having more of an idea what this topic and language is about.

Quite vicious, unnecessary, and insulting. I didn't realize we do that around here. I guess only you are allowed to stray offtopic, and to the extent that you like.

Well then, I'll show myself out.

[nnnik]

jeeswg I domt think that you would be part of the dunces in this situation. But I still don't agree with your assessment here either. I don't agree that guests post is completely offtopic since he suggests that we just stop further development of AHK v2.0 and just ship it.
I also dont agree with your assessments of Helgefs or my posts. You seem to prefer a specific style of posting and find everything else disagreeable. I won't blame you for it though.

Im not denying that I went offtopic, but it always was in response to something offtopic. I still havent made my mind and would love to hear opinions about this.
This was an interesting proposition it might shape the future of the language.

Instead we are discussing other things that do not help the language but are part of some personal agenda.

Also a friendly reminder that the administration of topics is not offtopic.

[nnnik]

Also Im not doing this out of personal interest. I dont dislike fighting over the usual topics and not finding a conclusion - but this topic has received quite a few reports about being completely broken. Yet its a very important topic where many people need to speak their mind to guve the devs an idea what the consensus among the community is.

[gregster]

To all:
I don't think that introducing additional personal animus into this or any discussion will do us any good.
Sometimes, it helps to just take a step back and read again, before hitting 'Submit' (and then - just sometimes - don't hit 'Submit').

I would also consider administrating topics in which one is involved on a personal level far from ideal, especially if there are underlying, long-running personal conflicts.

[nnnik]

I agree but apparently most of the other admins avoid topics like this.
And Im very tired of tip toeing around.

[gregster]

I just think that calming the discussion, especially the personal aspects of it, would be important, without suppressing an open discussion. I would call it moderating (like in "moderate").
If that's tip-toeing, then you can call me a ballet fan.

[nnnik]

Calming the discussion doesn't make it stay on topic. This forum may very well not be a proper place anymore to discuss things then.

[gregster]

Come on, that's too much drama. No need for over-exaggerating.
I don't have the impression that we are getting back on the right track here, if we are going this route.

Let's just cut out the personal attacks and blame game.

[nnnik]

Its not over excegeration. Helgef told me via pm that he will take a break from the forums for a bit.
If one of the few people developing the language doesnt feel like this forum is a place for them to stay then what are we doing here?