Re: A response?

I tried to stay civil and such, but it was pushing my buttons more than a bit

Could it be that this fuckwit "Alexander" is trying to troll you ?
(Do you know who he is ? Is he a genuine Vim developer ? ... or just some dickhead who decided to provide a half-smart reply to your question ?)

I mean ... what sort of justification is "not very trendy these days" ?
Do we need to inject the phrase "really sick" into our documentation at every opportunity ?

I'd be inclined to ask him (quite earnestly) how we might make improvements to perl in the area of trendiness, and see what unfolds.
If he *is* trolling, then you sort of play into his hands by displaying your hostility to his ridiculous assertion. (And, let's face it, you haven't done a very good job of hiding your hostility in your proposed reply ... for which I don't blame you at all.)

Unfortunately , if he's not trolling, then I think choroba has pretty much nailed it ... and you might as well give it to him with as many barrels as you have at your disposal :-)

Cheers,
Rob

Comment on Re: A response?

Replies are listed 'Best First'.
Re^2: A response? by perl-diddler (Chaplain) on Mar 12, 2014 at 17:06 UTC
They are someone who is providing a pre-compiled version of vim in 64- and 32-bit form that runs natively on Windows. The version on Windows at one point had better font abilities (though still not great) than the X11 version -- though this point hasn't been true for about 3-5 years now. The windows version has ALWAYS been better than most linux-distro versions in working with the "presence or absence" of perl -- and later, ruby & python. What I mean by that for over a decade, vim has automatically configured it's abilities based on the presence or absence of various "DLL"'s. I think, besides perl, the other was the 'iconv' library that allowed it to work with "ascii", later with 8-bit locale's, and later-still, with UTF-8. If those libraries were not present on your machine -- vim simply turned off those features in the running program and told you that to support those features, you had to put the appropriate DLL's on your machine. This is contrasted to the linux-distro versions (am most familiar with the suse variety), that only know about 'hard-linking' and provided as many as 4-6 different versions in each release, based on what you wanted rather than than on what was present at run-time. This means that on linux, by default, in order to install the version that has built-in perl scripting ability, you also need to install python, ruby, and any other language vim supports run-time scripting of, because it is statically linked to the shared-objects at build-time, rather than using dynamic linking to the shared-objects at 'run-time'. While linux inherited this ability from unix, it has made little use of it. Most of the distro versions rely on static checks at install time via 'rpm' or similar. -- at least not as distributed by distro's who generally rely on static checks at install time via 'rpm' or similar, These methods were mostly indistinguishable to the end-user until recently, when the perl-ABI has been changing yearly, when perl moved to making major changes between "minor" version changes (i.e. V<Maj>.<Min>.<Rel>). As such, perl has been seen as too unstable since 5.8 as major versions are not compatible w/each other (due to perl '6' being reserved since ages ago...). I have a feeling that this is part of perl's lack of trendiness -- perl is still at version 5 that was released 20 years ago (despite numerous changes in the 'Minor' releases...). It's a crappy version system, but it's one reason Firefox moved from going from sane versioning 3.0->3.1 ... 3.6.0, 3.6.1, 3.6.2 ... 3.6.28, before they fell to the "version perception game" -- where non-computer people only look at the major version number. FWIW -- and AFAIK, he isn't a vim developer, but someone known and trusted in the community to provide pre-compiled binaries, which are harder to generate on windows due to the most used tools not being freely available (or the freely available versions having things like "optimization" stripped out).	[reply]

Replies are listed 'Best First'.

Re^2: A response?
by perl-diddler (Chaplain) on Mar 12, 2014 at 17:06 UTC

The version on Windows at one point had better font abilities (though still not great) than the X11 version -- though this point hasn't been true for about 3-5 years now.

The windows version has ALWAYS been better than most linux-distro versions in working with the "presence or absence" of perl -- and later, ruby & python. What I mean by that for over a decade, vim has automatically configured it's abilities based on the presence or absence of various "DLL"'s. I think, besides perl, the other was the 'iconv' library that allowed it to work with "ascii", later with 8-bit locale's, and later-still, with UTF-8. If those libraries were not present on your machine -- vim simply turned off those features in the running program and told you that to support those features, you had to put the appropriate DLL's on your machine.

This is contrasted to the linux-distro versions (am most familiar with the suse variety), that only know about 'hard-linking' and provided as many as 4-6 different versions in each release, based on what you wanted rather than than on what was present at run-time.

This means that on linux, by default, in order to install the version that has built-in perl scripting ability, you also need to install python, ruby, and any other language vim supports run-time scripting of, because it is statically linked to the shared-objects at build-time, rather than using dynamic linking to the shared-objects at 'run-time'.

While linux inherited this ability from unix, it has made little use of it. Most of the distro versions rely on static checks at install time via 'rpm' or similar. -- at least not as distributed by distro's who generally rely on static checks at install time via 'rpm' or similar,

These methods were mostly indistinguishable to the end-user until recently, when the perl-ABI has been changing yearly, when perl moved to making major changes between "minor" version changes (i.e. V<Maj>.<Min>.<Rel>). As such, perl has been seen as too unstable since 5.8 as major versions are not compatible w/each other (due to perl '6' being reserved since ages ago...). I have a feeling that this is part of perl's lack of trendiness -- perl is still at version 5 that was released 20 years ago (despite numerous changes in the 'Minor' releases...). It's a crappy version system, but it's one reason Firefox moved from going from sane versioning 3.0->3.1 ... 3.6.0, 3.6.1, 3.6.2 ... 3.6.28, before they fell to the "version perception game" -- where non-computer people only look at the major version number.

FWIW -- and AFAIK, he isn't a vim developer, but someone known and trusted in the community to provide pre-compiled binaries, which are harder to generate on windows due to the most used tools not being freely available (or the freely available versions having things like "optimization" stripped out).

[reply]