Forums Feature Suggestions -un of /set for /var

Your example user scenario doesn't really fly. A user looking up /help /var will be in the wrong place anyway (why was /var their first choice anyway? that seems arbitrary). If we're going to talk about user confusion in the help file there's plenty to discuss. The -g switch on /var is an after-thought in the documentation, it's a tiny phrase in a note at the end of the section titled Local Variables. It doesn't even get a full sentence. I'd be surprised if the user even found that /var could be used for global vars in the first place without paying very close attention (and ignoring the title's own heading saying those variables will be local, which would contradict the amount of attention he is supposedly paying).

So when he gets to (which he won't, he'd get stuck way earlier, most likely, but let's pretend):



The answer is simply: "/var is documented under 'Local Variables' and is for local variables, /set is for global variables." -- I don't think anybody will be confused by this answer. If they actually catch the doc on -g and ask why /var can set global variables, you tell them "/var -g was feature creep and shouldn't have been added." Simple enough to me.

And come on, those feature examples are easy to justify for the most part. Your assumption that they are simply "options for simplicity" is actually dead wrong. Most of the features you named have little to do with simplicity and a lot to do with reducing error-proneness or improving performance of the language, which is a common and valid justification for a feature:



While loops are a much more reliable way to loop. While loops were added because users were commonly having a difficult time with the error-proneness of goto loops, specifically in forgetting the goto statement, or, in nested cases, goto'ing the wrong label. While loops take one command out of the picture, give users indenting and make it easier to read / debug. It's also more reliable because users coming from other languages will be much more accustomed to this syntax than an archaic goto, again reducing error-proneness. There was a significant measurable success rate improvement in this addition, at least I certainly recall one when I was helping in #mIRC during the times before and after it was added.



Really? You're questioning "else"? There is a significant reliability advantage to NOT having to rewrite your if condition in the negative form. It's also much more efficient and performant to not have to re-execute this. Arguably, "elseif" need not exist, but it existed long before most other features, so it would be hard to call this one "feature creep". I think the fact that just about every other language has else is reason to follow along and implement this as well. There is good precedent for usefulness when 99.9% of languages have a feature.



Performance. mIRC is slow. If mIRC's file handling commands were as fast as /filter, you're right, we wouldn't need it at all. But mIRC is not that fast, and /filter is absolutely mandatory for a reasonably fast script, in countless cases. There is certainly a convenience element to /filter as well, but there is a much greater benefit to removing an entire loop structure than replacing "set %a | set %b" with "var %a, %b" -- there is also a small reduction of error-proneness in being able to remove a loop structure, as loops tend to cause many problems with new scripters, but this is certainly not the primary motivation for /filter IMO.

Finally, one you're right about:



I would argue that /close -@ should not have been added. Not only is it a horrible switch name (in fact, the only non-alphanum switch in all of mIRC, even /filter uses -w), it's unnecessary. But this is actually a great example of why we don't want to repeat the past, and actually helps to prove my point. We don't need more situations like /close -@... we should be striving for fewer of them. I bet the argument for /close -@ was the exact same argument as this one: "why not, /close can close other windows, -@ makes sense". This is precisely why I disagree with that logic.

In any case, as I had already stated, existence of bad examples in mIRC is no excuse to make mIRC messier. No, mIRC is not perfect. And no, that's not an excuse to make it worse.